* [GIT PULL] notification: including fanotify
@ 2010-02-26 21:14 Eric Paris
2010-02-27 21:29 ` Linus Torvalds
0 siblings, 1 reply; 7+ messages in thread
From: Eric Paris @ 2010-02-26 21:14 UTC (permalink / raw)
To: torvalds; +Cc: viro, hch, linux-kernel
This tree has the part of the notification changes which have existed
for better than a year in linux-next. They finish the inotify->fsnotify
transition and rip out the old inotify in-kernel interface. It
implements fanotify as a notifier only. fanotify being the basis for an
interface which a number of the major AV companies have privately (and
some publicly) agreed to pursue instead of loading closed source drivers
which attack the syscall table and bastardize our kernel internals.
This patch series does not allow fanotify to make access decisions, only
to notify. I know that both hch and viro have told me over the last 2
years they will review, but review has not come. The only person I know
to have reviewed this series was Andreas Gruenbacher. If there are
objections to fanotify please let me know before the window closes so I
can build a tree with only non-fanotify fixes and changes.
-Eric
The following changes since commit 6ebdc661b608671e9ca572af8bb42d58108cc008:
Linus Torvalds (1):
Merge branch 'next-devicetree' of git://git.secretlab.ca/git/linux-2.6
are available in the git repository at:
git://git.infradead.org/users/eparis/notify.git for-linus
Al Viro (2):
Lose the new_name argument of fsnotify_move()
Lose the first argument of audit_inode_child()
Alexey Dobriyan (1):
dnotify: move dir_notify_enable declaration
Andreas Gruenbacher (15):
fsnotify: kill FSNOTIFY_EVENT_FILE
fsnotify: take inode->i_lock inside fsnotify_find_mark_entry()
fanotify: create_fd cleanup
fanotify: Add pids to events
fsnotify/vfsmount: add fsnotify fields to struct vfsmount
fsnotify: Infrastructure for per-mount watches
fanotify: remove fanotify_update_mark
fanotify: do not call fanotify_update_object_mask in fanotify_remove_mark
fanotify: do not call fanotify_update_object_mask in fanotify_add_mark
fanotify: do not return pointer from fanotify_add_*_mark
fanotify: remove fanotify_add_mark
fanotify: rename FAN_MARK_ON_VFSMOUNT to FAN_MARK_MOUNT
fanotify: split fanotify_remove_mark
fanotify: remove fanotify.h declarations
fanotify: remove outgoing function checks in fanotify.h
Dave Young (1):
sysctl extern cleanup: inotify
Eric Paris (76):
inotify: simplify the inotify idr handling
Audit: clean up the audit_watch split
audit: convert audit watches to use fsnotify instead of inotify
audit: redo audit watch locking and refcnt in light of fsnotify
audit: do not get and put just to free a watch
fsnotify: duplicate fsnotify_mark_entry data between 2 marks
fsnotify: allow addition of duplicate fsnotify marks
audit: reimplement audit_trees using fsnotify rather than inotify
Audit: audit watches depend on fsnotify
Audit: split audit watch Kconfig
Audit: audit watch init should not be before fsnotify init
fsnotify: use fsnotify_create_event to allocate the q_overflow event
inotify: use container_of instead of casting
fsnotify: kzalloc fsnotify groups
fsnotify: use kmem_cache_zalloc to simplify event initialization
inotify: do not reuse watch descriptors
inotify: remove inotify in kernel interface
inotify: do not spam console without limit
fsnotify: provide the data type to should_send_event
fsnotify: include data in should_send calls
fsnotify: pass a file instead of an inode to open, read, and write
fsnotify: send struct file when sending events to parents when possible
fsnotify: per group notification queue merge types
fsnotify: clone existing events
fsnotify: replace an event on a list
fsnotify: lock annotation for event replacement
fsnotify: remove group_num altogether
fsnotify: fsnotify_obtain_group kzalloc cleanup
fsnotify: fsnotify_obtain_group should be fsnotify_alloc_group
Audit: only set group mask when something is being watched
fsnotify: drop mask argument from fsnotify_alloc_group
fsnotify: rename fsnotify_groups to fsnotify_inode_groups
fsnotify: initialize the group->num_marks in a better place
fsnotify: add groups to fsnotify_inode_groups when registering inode watch
fsnotify: mount point listeners list and global mask
fsnotify: include vfsmount in should_send_event when appropriate
fsnotify: put inode specific fields in an fsnotify_mark in a union
fsnotify: add vfsmount specific fields to the fsnotify_mark_entry union
fsnotify: add flags to fsnotify_mark_entries
fsnotify: rename fsnotify_mark_entry to just fsnotify_mark
fsnotify: rename fsnotify_find_mark_entry to fsnotify_find_mark
fsnotify: rename mark_entry to just mark
inotify: rename mark_entry to just mark
dnotify: rename mark_entry to mark
vfs: introduce FMODE_NONOTIFY
fanotify: fscking all notification system
fanotify:drop notification if they exist in the outgoing queue
fanotify: merge notification events with different masks
fanotify: do not clone on merge unless needed
fanotify: fanotify_init syscall declaration
fanotify: fanotify_init syscall implementation
fanotify: sys_fanotify_mark declartion
fanotify: fanotify_mark syscall implementation
fanotify: send events using read
fsnotify: split generic and inode specific mark code
fsnotify: clear marks to 0 in fsnotify_init_mark
fsnotify: vfsmount marks generic functions
fanotify: should_send_event needs to handle vfsmounts
fanotify: infrastructure to add an remove marks on vfsmounts
fanotify: hooks the fanotify_mark syscall to the vfsmount code
fsnotify: allow marks to not pin inodes in core
fsnotify: ignored_mask - excluding notification
fanotify: ignored_mask to ignore events
fanotify: allow users to set an ignored_mask
fsnotify: clear ignored mask on modify
fsnotify: allow ignored_mask to survive modification
fanotify: allow ignored_masks to survive modify
fanotify: clear all fanotify marks
fsnotify: add group priorities
fsnotify: intoduce a notification merge argument
fanotify: use merge argument to determine actual event added to queue
fsnotify: new fsnotify hooks and events types for access decisions
fanotify: permissions and blocking
fanotify: userspace interface for permission responses
fanotify: do not return 0 in a void function
fsnotify: use unsigned char * for dentry->d_name.name
Heiko Carstens (1):
fanotify: CONFIG_HAVE_SYSCALL_WRAPPERS for sys_fanotify_mark
Paul Mundt (1):
fanotify: select ANON_INODES.
Signed-off-by: Wu Fengguang (1):
fanotify: FMODE_NONOTIFY and __O_SYNC in sparc conflict
Documentation/feature-removal-schedule.txt | 8 -
arch/x86/ia32/ia32entry.S | 2 +
arch/x86/ia32/sys_ia32.c | 9 +
arch/x86/include/asm/sys_ia32.h | 3 +
arch/x86/include/asm/unistd_32.h | 4 +-
arch/x86/include/asm/unistd_64.h | 4 +
arch/x86/kernel/syscall_table_32.S | 2 +
fs/compat.c | 5 +-
fs/debugfs/inode.c | 2 +-
fs/exec.c | 4 +-
fs/inode.c | 8 +-
fs/namei.c | 10 +-
fs/namespace.c | 5 +
fs/nfsd/vfs.c | 4 +-
fs/notify/Kconfig | 1 +
fs/notify/Makefile | 6 +-
fs/notify/dnotify/dnotify.c | 198 +++----
fs/notify/fanotify/Kconfig | 26 +
fs/notify/fanotify/Makefile | 1 +
fs/notify/fanotify/fanotify.c | 255 ++++++++
fs/notify/fanotify/fanotify_user.c | 776 +++++++++++++++++++++++
fs/notify/fsnotify.c | 141 ++++-
fs/notify/fsnotify.h | 33 +-
fs/notify/group.c | 178 +++---
fs/notify/inode_mark.c | 309 +++-------
fs/notify/inotify/Kconfig | 15 -
fs/notify/inotify/Makefile | 1 -
fs/notify/inotify/inotify.c | 933 ----------------------------
fs/notify/inotify/inotify.h | 7 +-
fs/notify/inotify/inotify_fsnotify.c | 114 +++-
fs/notify/inotify/inotify_user.c | 305 ++++++----
fs/notify/mark.c | 325 ++++++++++
fs/notify/notification.c | 180 +++---
fs/notify/vfsmount_mark.c | 176 ++++++
fs/open.c | 3 +-
fs/read_write.c | 8 +-
include/asm-generic/fcntl.h | 8 +
include/linux/Kbuild | 1 +
include/linux/audit.h | 11 +-
include/linux/dnotify.h | 1 +
include/linux/fanotify.h | 105 ++++
include/linux/fs.h | 16 +-
include/linux/fsnotify.h | 171 +++---
include/linux/fsnotify_backend.h | 169 ++++--
include/linux/inotify.h | 175 +-----
include/linux/mount.h | 6 +-
include/linux/security.h | 1 +
include/linux/syscalls.h | 5 +
init/Kconfig | 10 +-
kernel/Makefile | 5 +-
kernel/audit.c | 1 -
kernel/audit.h | 26 +-
kernel/audit_tree.c | 232 ++++---
kernel/audit_watch.c | 295 +++++----
kernel/auditfilter.c | 39 +-
kernel/auditsc.c | 17 +-
kernel/sys_ni.c | 4 +
kernel/sysctl.c | 7 +-
security/security.c | 16 +-
59 files changed, 3113 insertions(+), 2269 deletions(-)
create mode 100644 fs/notify/fanotify/Kconfig
create mode 100644 fs/notify/fanotify/Makefile
create mode 100644 fs/notify/fanotify/fanotify.c
create mode 100644 fs/notify/fanotify/fanotify_user.c
delete mode 100644 fs/notify/inotify/inotify.c
create mode 100644 fs/notify/mark.c
create mode 100644 fs/notify/vfsmount_mark.c
create mode 100644 include/linux/fanotify.h
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] notification: including fanotify
2010-02-26 21:14 [GIT PULL] notification: including fanotify Eric Paris
@ 2010-02-27 21:29 ` Linus Torvalds
2010-02-27 21:33 ` Linus Torvalds
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Linus Torvalds @ 2010-02-27 21:29 UTC (permalink / raw)
To: Eric Paris; +Cc: viro, hch, linux-kernel
On Fri, 26 Feb 2010, Eric Paris wrote:
>
> This tree has the part of the notification changes which have existed
> for better than a year in linux-next. They finish the inotify->fsnotify
> transition and rip out the old inotify in-kernel interface. It
> implements fanotify as a notifier only.
I was going to pull this, but
(a) that "notifier only" part seems to be incorrect. It has at least the
Kconfig part of the "let's also allow fanotify to do security
checks.
(b) the compile has obviously never been tested with any modern gcc
version. I get tons of warnings after the pull, like
In file included from fs/notify/fsnotify.h:6,
from fs/notify/fsnotify.c:28:
include/linux/fsnotify.h: In function ‘fsnotify_oldname_init’:
include/linux/fsnotify.h:313: warning: pointer targets in passing argument 1 of ‘kstrdup’ differ in signedness
include/linux/string.h:118: note: expected ‘const char *’ but argument is of type ‘const unsigned char *’
include/linux/fsnotify.h:313: warning: pointer targets in return differ in signedness
In file included from fs/notify/fsnotify.h:6,
from fs/notify/group.c:28:
which is totally unacceptable. I'm not going to merge code that adds
warnings like these. You can argue whether the warning is really
something gcc should warn about or not, but it really doesn't matter.
Adding lots of noisy warnings is unacceptable, and I'm upset that you
even pushed something to me with apparently _zero_ testing (or a total
disregard for a clean compile).
Grr.
Linus
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] notification: including fanotify
2010-02-27 21:29 ` Linus Torvalds
@ 2010-02-27 21:33 ` Linus Torvalds
2010-02-27 23:29 ` Stephen Rothwell
2010-02-27 22:51 ` Al Viro
2010-02-27 23:49 ` Eric Paris
2 siblings, 1 reply; 7+ messages in thread
From: Linus Torvalds @ 2010-02-27 21:33 UTC (permalink / raw)
To: Eric Paris; +Cc: viro, hch, linux-kernel
On Sat, 27 Feb 2010, Linus Torvalds wrote:
>
> (b) the compile has obviously never been tested with any modern gcc
> version. I get tons of warnings after the pull, like
In fact, this seems to be due to a commit that explicitly says:
I do not add -Wpointer-sign to the fsnotify
code as there are still issues with kstrdup and strlen which would pop
out needless warnings.
but then the patch actually has
--- a/fs/notify/Makefile
+++ b/fs/notify/Makefile
@@ -1,3 +1,5 @@
+EXTRA_CFLAGS += -Wpointer-sign
+
WTF? Which part of this was tested AT ALL? Clearly there was not even a
compile test going on.
Linus
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] notification: including fanotify
2010-02-27 21:29 ` Linus Torvalds
2010-02-27 21:33 ` Linus Torvalds
@ 2010-02-27 22:51 ` Al Viro
2010-02-27 23:49 ` Eric Paris
2 siblings, 0 replies; 7+ messages in thread
From: Al Viro @ 2010-02-27 22:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Paris, hch, linux-kernel
On Sat, Feb 27, 2010 at 01:29:41PM -0800, Linus Torvalds wrote:
> > This tree has the part of the notification changes which have existed
> > for better than a year in linux-next. They finish the inotify->fsnotify
> > transition and rip out the old inotify in-kernel interface. It
> > implements fanotify as a notifier only.
>
> I was going to pull this, but
>
> (a) that "notifier only" part seems to be incorrect. It has at least the
> Kconfig part of the "let's also allow fanotify to do security
> checks.
>
> (b) the compile has obviously never been tested with any modern gcc
> version. I get tons of warnings after the pull, like
>
> In file included from fs/notify/fsnotify.h:6,
> from fs/notify/fsnotify.c:28:
> include/linux/fsnotify.h: In function ???fsnotify_oldname_init???:
> include/linux/fsnotify.h:313: warning: pointer targets in passing argument 1 of ???kstrdup??? differ in signedness
> include/linux/string.h:118: note: expected ???const char *??? but argument is of type ???const unsigned char *???
> include/linux/fsnotify.h:313: warning: pointer targets in return differ in signedness
> In file included from fs/notify/fsnotify.h:6,
> from fs/notify/group.c:28:
>
> which is totally unacceptable. I'm not going to merge code that adds
> warnings like these. You can argue whether the warning is really
> something gcc should warn about or not, but it really doesn't matter.
>
> Adding lots of noisy warnings is unacceptable, and I'm upset that you
> even pushed something to me with apparently _zero_ testing (or a total
> disregard for a clean compile).
Guys, could you hold that odd until Tuesday or so? I'm halfway through the
autofs4 review (and there are real gems there - code that had been dead
for a decade, right in the way of any analysis of lifetime rules, potential
deadlocks, etc.) and once I'm through with that, I'll push the first part
of VFS tree, give the autofs pile to Ian and post the fanotify review.
It's nearly finished, just need to get from under the pile of other stuff ;-/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] notification: including fanotify
2010-02-27 21:33 ` Linus Torvalds
@ 2010-02-27 23:29 ` Stephen Rothwell
2010-02-27 23:38 ` Linus Torvalds
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2010-02-27 23:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Paris, viro, hch, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]
Hi Linus,
On Sat, 27 Feb 2010 13:33:21 -0800 (PST) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Sat, 27 Feb 2010, Linus Torvalds wrote:
> >
> > (b) the compile has obviously never been tested with any modern gcc
> > version. I get tons of warnings after the pull, like
>
> In fact, this seems to be due to a commit that explicitly says:
>
> I do not add -Wpointer-sign to the fsnotify
> code as there are still issues with kstrdup and strlen which would pop
> out needless warnings.
>
> but then the patch actually has
>
> --- a/fs/notify/Makefile
> +++ b/fs/notify/Makefile
> @@ -1,3 +1,5 @@
> +EXTRA_CFLAGS += -Wpointer-sign
> +
>
> WTF? Which part of this was tested AT ALL? Clearly there was not even a
> compile test going on.
You also forgot to mention that this whole tree has been rebased since
(my) Friday and the version of the above commit in linux-next does not
have that hunk.
As that commit does say, these warnings first came to light when the xfs
tree added that flag to its build. It was removed again after a couple of
days because it generates quite a few warnings (as you have seen). It
appears that thee needs to be more cleanup before it is enabled again.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] notification: including fanotify
2010-02-27 23:29 ` Stephen Rothwell
@ 2010-02-27 23:38 ` Linus Torvalds
0 siblings, 0 replies; 7+ messages in thread
From: Linus Torvalds @ 2010-02-27 23:38 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Eric Paris, viro, hch, linux-kernel
On Sun, 28 Feb 2010, Stephen Rothwell wrote:
>
> You also forgot to mention that this whole tree has been rebased since
> (my) Friday and the version of the above commit in linux-next does not
> have that hunk.
Yeah. This is why I hate people who rebase too much.
I don't mind rebases per se, but when they happen within the last few
days, it just tells me that "that tree got no testing".
So guys: feel free to rebase. But when you do, wait a week afterwards.
Don't "rebase and ask Linus to pull". That's just _wrong_. It means that
the tree you asked me to pull has gotten zero testing.
And sometimes that lack of testing is more obvious than other times. In
this case, it was pretty damn obvious.
Linus
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] notification: including fanotify
2010-02-27 21:29 ` Linus Torvalds
2010-02-27 21:33 ` Linus Torvalds
2010-02-27 22:51 ` Al Viro
@ 2010-02-27 23:49 ` Eric Paris
2 siblings, 0 replies; 7+ messages in thread
From: Eric Paris @ 2010-02-27 23:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: viro, hch, linux-kernel
On Sat, 2010-02-27 at 13:29 -0800, Linus Torvalds wrote:
>
> On Fri, 26 Feb 2010, Eric Paris wrote:
> >
> > This tree has the part of the notification changes which have existed
> > for better than a year in linux-next. They finish the inotify->fsnotify
> > transition and rip out the old inotify in-kernel interface. It
> > implements fanotify as a notifier only.
>
> I was going to pull this, but
>
> (a) that "notifier only" part seems to be incorrect. It has at least the
> Kconfig part of the "let's also allow fanotify to do security
> checks.
Honestly I just forgot the permissions code was in -next (and has been
since before 2.6.32 opened now that I think about it). I remembered to
drop that stuff for my 2.6.32 pull request (which came in WAY to late
for you to care about) but forgot I needed to pull it back out this
time. It will be dropped (even though I think it's good to go, limiting
what I'm trying to get Al/hch to look at is my only hope)
> (b) the compile has obviously never been tested with any modern gcc
> version. I get tons of warnings after the pull, like
>
> In file included from fs/notify/fsnotify.h:6,
> from fs/notify/fsnotify.c:28:
> include/linux/fsnotify.h: In function ‘fsnotify_oldname_init’:
> include/linux/fsnotify.h:313: warning: pointer targets in passing argument 1 of ‘kstrdup’ differ in signedness
> include/linux/string.h:118: note: expected ‘const char *’ but argument is of type ‘const unsigned char *’
> include/linux/fsnotify.h:313: warning: pointer targets in return differ in signedness
> In file included from fs/notify/fsnotify.h:6,
> from fs/notify/group.c:28:
>
> which is totally unacceptable. I'm not going to merge code that adds
> warnings like these. You can argue whether the warning is really
> something gcc should warn about or not, but it really doesn't matter.
>
> Adding lots of noisy warnings is unacceptable, and I'm upset that you
> even pushed something to me with apparently _zero_ testing (or a total
> disregard for a clean compile).
No question this was my stupidity. When I was rebasing my stuff on top
of your tree to make sure it would merge nicely before I ask for a pull
this patch had conflicts. While resolving the conflict I added the -W
to the Makefile to make sure that I didn't screw up the point of the
patch. I knew the warnings were going to pop out and I just ignored
them. I guess I managed to save the Makefile by accident. Obviously
I'm going to fix that patch to what it's been in -next (where sfr has
been handling the conflict)
/me sets the clock for one week for next pull request.
-Eric
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-02-27 23:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-26 21:14 [GIT PULL] notification: including fanotify Eric Paris
2010-02-27 21:29 ` Linus Torvalds
2010-02-27 21:33 ` Linus Torvalds
2010-02-27 23:29 ` Stephen Rothwell
2010-02-27 23:38 ` Linus Torvalds
2010-02-27 22:51 ` Al Viro
2010-02-27 23:49 ` Eric Paris
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox