|author||Mikhail Efremov <firstname.lastname@example.org>||2014-09-24 22:14:33 +0400|
|committer||Al Viro <email@example.com>||2014-09-27 15:59:39 -0400|
vfs: Don't exchange "short" filenames unconditionally.
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 <firstname.lastname@example.org> Cc: Linus Torvalds <email@example.com> Cc: Alexander Viro <firstname.lastname@example.org> Cc: email@example.com Cc: firstname.lastname@example.org Fixes: da1ce0670c14 "vfs: add cross-rename" Signed-off-by: Mikhail Efremov <email@example.com> Signed-off-by: Al Viro <firstname.lastname@example.org>
Diffstat (limited to 'mm/shmem.c')
0 files changed, 0 insertions, 0 deletions