linux.git/fs, branch v3.17-rc7

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2014-09-28T00:05:14+00:00

Pull vfs fixes from Al Viro:
 "Assorted fixes + unifying __d_move() and __d_materialise_dentry() +
  minimal regression fix for d_path() of victims of overwriting rename()
  ported on top of that"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  vfs: Don't exchange "short" filenames unconditionally.
  fold swapping ->d_name.hash into switch_names()
  fold unlocking the children into dentry_unlock_parents_for_move()
  kill __d_materialise_dentry()
  __d_materialise_dentry(): flip the order of arguments
  __d_move(): fold manipulations with ->d_child/->d_subdirs
  don't open-code d_rehash() in d_materialise_unique()
  pull rehashing and unlocking the target dentry into __d_materialise_dentry()
  ufs: deal with nfsd/iget races
  fuse: honour max_read and max_write in direct_io mode
  shmem: fix nlink for rename overwrite directory

vfs: Don't exchange "short" filenames unconditionally.

2014-09-27T19:59:39+00:00

Only exchange source and destination filenames
if flags contain RENAME_EXCHANGE.
In case if executable file was running and replaced by
other file /proc/PID/exe should still show correct file name,
not the old name of the file by which it was replaced.

The scenario when this bug manifests itself was like this:
* ALT Linux uses rpm and start-stop-daemon;
* during a package upgrade rpm creates a temporary file
  for an executable to rename it upon successful unpacking;
* start-stop-daemon is run subsequently and it obtains
  the (nonexistant) temporary filename via /proc/PID/exe
  thus failing to identify the running process.

Note that "long" filenames (> DNAiME_INLINE_LEN) are still
exchanged without RENAME_EXCHANGE and this behaviour exists
long enough (should be fixed too apparently).
So this patch is just an interim workaround that restores
behavior for "short" names as it was before changes
introduced by commit da1ce0670c14 ("vfs: add cross-rename").

See https://lkml.org/lkml/2014/9/7/6 for details.

AV: the comments about being more careful with ->d_name.hash
than with ->d_name.name are from back in 2.3.40s; they
became obsolete by 2.3.60s, when we started to unhash the
target instead of swapping hash chain positions followed
by d_delete() as we used to do when dcache was first
introduced.

Acked-by: Miklos Szeredi 
Cc: Linus Torvalds 
Cc: Alexander Viro 
Cc: linux-fsdevel@vger.kernel.org
Cc: stable@vger.kernel.org
Fixes: da1ce0670c14 "vfs: add cross-rename"
Signed-off-by: Mikhail Efremov 
Signed-off-by: Al Viro

fold swapping ->d_name.hash into switch_names()

2014-09-27T19:59:11+00:00

and do it along with ->d_name.len there

Signed-off-by: Linus Torvalds 
Signed-off-by: Al Viro

fold unlocking the children into dentry_unlock_parents_for_move()

2014-09-27T03:11:15+00:00

... renaming it into dentry_unlock_for_move() and making it more
symmetric with dentry_lock_for_move().

Signed-off-by: Al Viro

kill __d_materialise_dentry()

2014-09-27T03:06:14+00:00

it folds into __d_move() now

Signed-off-by: Al Viro

__d_materialise_dentry(): flip the order of arguments

2014-09-27T02:54:02+00:00

... thus making it much closer to (now unreachable, BTW) IS_ROOT(dentry)
case in __d_move().  A bit more and it'll fold in.

Signed-off-by: Al Viro

__d_move(): fold manipulations with ->d_child/->d_subdirs

2014-09-27T01:34:01+00:00

list_del() + list_add() is a slightly pessimised list_move()
list_del() + INIT_LIST_HEAD() is a slightly pessimised list_del_init()

Interleaving those makes the resulting code even worse.  And harder to follow...

Signed-off-by: Al Viro

don't open-code d_rehash() in d_materialise_unique()

2014-09-27T01:26:50+00:00

... and get rid of duplicate BUG_ON() there

Signed-off-by: Al Viro

pull rehashing and unlocking the target dentry into __d_materialise_dentry()

2014-09-27T01:25:35+00:00

Signed-off-by: Al Viro

ufs: deal with nfsd/iget races

2014-09-27T01:17:52+00:00

Signed-off-by: Al Viro