vfs pile 3
Al Viro
maintainer Stuff from Jeff Layton, mostly. Sanitizing interplay between
audit and namei, removing a lot of insanity from audit_inode() mess and getting things ready for his ESTALE patchset. Please, pull from the usual place -git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Eric Paris (1):
audit: make audit_compare_dname_path use parent_len helper
Jeff Layton (19):
audit: remove unnecessary NULL ptr checks from do_path_lookup
audit: pass in dentry to audit_copy_inode wherever possible
audit: no need to walk list in audit_inode if name is NULL
audit: reverse arguments to audit_inode_child
audit: add a new "type" field to audit_names struct
audit: set the name_len in audit_inode for parent lookups
audit: remove dirlen argument to audit_compare_dname_path
audit: optimize audit_compare_dname_path
audit: overhaul __audit_inode_child to accomodate retrying
vfs: allocate page instead of names_cache buffer in mount_block_root
acct: constify the name arg to acct_on
vfs: unexport getname and putname symbols
vfs: define struct filename and have getname() return it
audit: allow audit code to satisfy getname requests from its names_list
vfs: turn do_path_lookup into wrapper around struct filename variant
vfs: make path_openat take a struct filename pointer
audit: make audit_inode take struct filename
vfs: embed struct filename inside of names_cache allocation if possible
procfs: don't need a PATH_MAX allocation to hold a string representation of an int
Diffstat:
arch/alpha/kernel/osf_sys.c | 16 +- arch/arm64/kernel/sys.c | 4 +- arch/arm64/kernel/sys_compat.c | 6 +- arch/avr32/kernel/process.c | 4 +- arch/blackfin/kernel/process.c | 4 +- arch/cris/arch-v10/kernel/process.c | 4 +- arch/cris/arch-v32/kernel/process.c | 4 +- arch/h8300/kernel/process.c | 4 +- arch/hexagon/kernel/syscall.c | 4 +- arch/ia64/kernel/process.c | 4 +- arch/m32r/kernel/process.c | 4 +- arch/microblaze/kernel/sys_microblaze.c | 4 +- arch/mips/kernel/linux32.c | 4 +- arch/mips/kernel/syscall.c | 4 +- arch/openrisc/kernel/process.c | 4 +- arch/parisc/hpux/fs.c | 4 +- arch/parisc/kernel/process.c | 4 +- arch/parisc/kernel/sys_parisc32.c | 4 +- arch/score/kernel/sys_score.c | 4 +- arch/sh/kernel/process_32.c | 4 +- arch/sh/kernel/process_64.c | 4 +- arch/sparc/kernel/process_32.c | 4 +- arch/sparc/kernel/process_64.c | 4 +- arch/sparc/kernel/sys_sparc32.c | 4 +- arch/tile/kernel/process.c | 8 +- arch/unicore32/kernel/sys.c | 4 +- arch/xtensa/kernel/process.c | 4 +- fs/btrfs/ioctl.c | 2 +- fs/compat.c | 12 +- fs/exec.c | 14 +- fs/filesystems.c | 4 +- fs/internal.h | 4 +- fs/namei.c | 213 ++++++++++++++++++++---------- fs/namespace.c | 4 +- fs/open.c | 29 ++++- fs/proc/base.c | 5 +- fs/quota/quota.c | 4 +- fs/xattr.c | 8 +- include/linux/audit.h | 69 +++++++--- include/linux/fs.h | 21 +++- include/linux/fsnotify.h | 8 +- init/do_mounts.c | 7 +- ipc/mqueue.c | 17 ++- kernel/acct.c | 6 +- kernel/audit.h | 7 +- kernel/audit_watch.c | 3 +- kernel/auditfilter.c | 65 ++++++---- kernel/auditsc.c | 217 +++++++++++++++++++++---------- mm/swapfile.c | 11 +- 49 files changed, 544 insertions(+), 312 deletions(-)
Il 13/10/2012 02:20, Al Viro ha scritto:
Quoted 6 lines
Stuff from Jeff Layton, mostly. Sanitizing interplay between
audit and namei, removing a lot of insanity fromaudit_inode()mess and getting things ready for his ESTALE patchset. Please, pull from the usual place -git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.gitfor-linus
Al,
do you see any problem to apply the patch series "drop vmtruncate"? Do you think it's better to push it for 3.8?
Thanks,
Marco
Al Viro
maintainerQuoted 11 lines · Marco Stornelli
Il 13/10/2012 02:20, Al Viro ha scritto:
Quoted 6 lines
Stuff from Jeff Layton, mostly. Sanitizing interplay between
audit and namei, removing a lot of insanity fromaudit_inode()mess and getting things ready for his ESTALE patchset. Please, pull from the usual place -git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.gitfor-linusAl,
do you see any problem to apply the patch series "drop vmtruncate"?
It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is...
Il 13/10/2012 09:51, Al Viro ha scritto:
Quoted 9 lines · Marco Stornelli
Quoted 8 lines
Il 13/10/2012 02:20, Al Viro ha scritto:
Quoted 6 lines
Stuff from Jeff Layton, mostly. Sanitizing interplay between
audit and namei, removing a lot of insanity fromaudit_inode()mess and getting things ready for his ESTALE patchset. Please, pull from the usual place -git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.gitfor-linus
Quoted 7 lines
Quoted 3 lines
Al,
do you see any problem to apply the patch series "drop vmtruncate"?
It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is...
The goal of the patch was to remove a deprecated function trying to improve the code, removing the inode operation and doing a general cleanup. It's pointless for me to have "dead"/"old" code, however thanks for you comment.
Marco
Quoted 2 lines · Al Viro
It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is...
I'd really like to see ->truncate and vmtruncate done, so from that side I'm absolutely in favour of this series. What I'm a bit concerned about is that it just does the trivial 1:1 conversion and not actually converts the sequence of operations to the proper form, which was one of the two big reasons of moving away from ->truncate to start with.
I'd love to see the full conversion, but without adequate test coverage for all the fringe filesystems that might be a bit too much to expect from Marco.
I think just doing the easy conversions he did, and putting a TODO comment explaining how it should be taken further at each of the sites would be valueable on its own.
Al Viro
maintainerQuoted 10 lines · Christoph Hellwig
Quoted 2 lines · Al Viro
It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is...
I'd really like to see ->truncate and vmtruncate done, so from that side I'm absolutely in favour of this series. What I'm a bit concerned about is that it just does the trivial 1:1 conversion and not actually converts the sequence of operations to the proper form, which was one of the two big reasons of moving away from ->truncate to start with.
Quoted 7 lines
I'd love to see the full conversion, but without adequate test coverage for all the fringe filesystems that might be a bit too much to expect from Marco.
I think just doing the easy conversions he did, and putting a TODO comment explaining how it should be taken further at each of the sites would be valueable on its own.
You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago. kernel_thread() unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/
I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying ->truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why vmtruncate() was a bad idea, leaving the functionality exactly as it used to be...
Quoted 10 lines · Al Viro
You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago.
kernel_thread()unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying ->truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why
vmtruncate()was a bad idea, leaving the functionality exactly as it used to be...
As mentioned I agree with the concern in principle. Let's start by taking Marco's patches for filesystems that use vmtruncate but don't actually implement ->truncate. There's a few I remember offhand, e.g. procfs and ufs right now. Then we can do the actual work required ones piece by piece.
Al Viro
maintainerQuoted 12 lines · Christoph Hellwig
Quoted 10 lines · Al Viro
You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago.
kernel_thread()unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying ->truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why
vmtruncate()was a bad idea, leaving the functionality exactly as it used to be...
Quoted 5 lines
As mentioned I agree with the concern in principle. Let's start by taking Marco's patches for filesystems that use vmtruncate but don't actually implement ->truncate. There's a few I remember offhand, e.g. procfs and ufs right now. Then we can do the actual work required ones piece by piece.
Umm... That would be what, procfs? Frankly, I'm not sure that ATTR_SIZE for procfs actually should not be silently ignored. ->i_size there is completely synthetic - it's not as if truncation would actually change the contents.
And ufs situation is quite different - there vmtruncate() is used only on the ->write_begin() side. ->setattr() is already vmtruncate-free. What's needed there is an analog of e.g. ext2_write_failed().
Il 13/10/2012 19:07, Al Viro ha scritto:
Quoted 19 lines · Christoph Hellwig
Quoted 12 lines · Al Viro
Quoted 10 lines
You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago.
kernel_thread()unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying ->truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why
vmtruncate()was a bad idea, leaving the functionality exactly as it used to be...Quoted 5 lines
As mentioned I agree with the concern in principle. Let's start by taking Marco's patches for filesystems that use vmtruncate but don't actually implement ->truncate. There's a few I remember offhand, e.g. procfs and ufs right now. Then we can do the actual work required ones piece by piece.
Quoted 8 lines
Umm... That would be what, procfs? Frankly, I'm not sure that
ATTR_SIZEfor procfs actually should not be silently ignored. ->i_size there is completely synthetic - it's not as if truncation would actually change the contents.And ufs situation is quite different - there
vmtruncate()is used only on the ->write_begin() side. ->setattr() is already vmtruncate-free. What's needed there is an analog of e.g.ext2_write_failed().
I'm open to change the series and give any help. My original idea was to do a cleanup patch and after that give to each fs maintainer the possibility to do ad-hoc fix. Each fs maintainer has got a deep knowledge of its fs so it was a safe approach from testing point of view and so on. However if you tell me that in this case another approach is better is ok for me. I'll fix the patches according to the comments of Christoph.
Regards,
Marco