Skip to contentSkip to conversation

vfs fixes

GIT PULL Al Viro 2 participants 3 messages Mar 10, 2012 VFS

lore
Share & tools
lore

Al Viro

author maintainer
#0 lore raw

A bunch of assorted fixes; Jan's freezing stuff still _not_
in there and neither is mm fun ;-/ Please, pull from usual place - git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog:
Jan Kara (2):
udf: Fix deadlock in udf_release_file()
vfs: Fix missed wakeup in I_NEW handling

Miklos Szeredi (2):
vfs: fix double put after complete_walk()
vfs: fix return value from do_last()

Tyler Hicks (1):
vfs: Correctly set the dir i_mutex lockdep class

Diffstat:

 fs/inode.c                |   25 +++++++++++++++++++++++--
 fs/namei.c                |    4 ++--
 fs/udf/file.c             |    2 --
 include/linux/writeback.h |    5 -----
 4 files changed, 25 insertions(+), 11 deletions(-)
#1 lore raw
Quoted 3 lines · Al Viro

Jan Kara (2):
     vfs: Fix missed wakeup in I_NEW handling

Christ. This one is too ugly to live.

I'm not pulling crap like this. It's f*^&ing stupid to take a lock, calculate a bitqueue, and just generally be an absolute ass-hat about things for waiting for a bit that is already set 99.999% of the time.

May I suggest just reverting that commit 250df6ed instead. It added all these insane things for no good reason. The comment said they are going away, but if they are just multiplying in ways like this, I really think the damn thing needs to be reverted. Any change that causes code like this is by definition not a good change.

Linus

author maintainer
#2 lore raw
Quoted 11 lines · Linus Torvalds
Quoted 3 lines · Al Viro

Jan Kara (2):
? ? ?vfs: Fix missed wakeup in I_NEW handling

Christ. This one is too ugly to live.

I'm not pulling crap like this. It's f*^&ing stupid to take a lock, calculate a bitqueue, and just generally be an absolute ass-hat about things for waiting for a bit that is already set 99.999% of the time.

Quoted 5 lines

May I suggest just reverting that commit 250df6ed instead. It added all these insane things for no good reason. The comment said they are going away, but if they are just multiplying in ways like this, I really think the damn thing needs to be reverted. Any change that causes code like this is by definition not a good change.

You mean the part that removed smp_mb() on cleaning I_NEW? OK by me - definitely saner than what this variant is doing. AFAICS, evict() does _not_ need it - only unlock_new_inode(); in case of evict() the change of ->i_state is separated from that wake_up_bit() by spin_unlock followed by spin_lock and that ought to provide the barrier...

Done and pushed to the same branch;

Shortlog:
Al Viro (1):
restore smp_mb() in unlock_new_inode()

Jan Kara (1):
udf: Fix deadlock in udf_release_file()

Miklos Szeredi (2):
vfs: fix double put after complete_walk()
vfs: fix return value from do_last()

Tyler Hicks (1):
vfs: Correctly set the dir i_mutex lockdep class

Diffstat:

 fs/inode.c    |    4 ++--
 fs/namei.c    |    4 ++--
 fs/udf/file.c |    2 --
 3 files changed, 4 insertions(+), 6 deletions(-)