Revision tags: v3.0, v3.0-rc7, v3.0-rc6, v3.0-rc5, v3.0-rc4, v3.0-rc3, v3.0-rc2, v3.0-rc1, v2.6.39, v2.6.39-rc7, v2.6.39-rc6, v2.6.39-rc5, v2.6.39-rc4, v2.6.39-rc3, v2.6.39-rc2, v2.6.39-rc1, v2.6.38, v2.6.38-rc8, v2.6.38-rc7, v2.6.38-rc6, v2.6.38-rc5, v2.6.38-rc4, v2.6.38-rc3, v2.6.38-rc2, v2.6.38-rc1, v2.6.37, v2.6.37-rc8, v2.6.37-rc7, v2.6.37-rc6, v2.6.37-rc5, v2.6.37-rc4, v2.6.37-rc3, v2.6.37-rc2, v2.6.37-rc1, v2.6.36, v2.6.36-rc8, v2.6.36-rc7, v2.6.36-rc6, v2.6.36-rc5, v2.6.36-rc4, v2.6.36-rc3, v2.6.36-rc2, v2.6.36-rc1 |
|
#
2069601b |
| 12-Aug-2010 |
Linus Torvalds <torvalds@linux-foundation.org> |
Revert "fsnotify: store struct file not struct path"
This reverts commit 3bcf3860a4ff9bbc522820b4b765e65e4deceb3e (and the accompanying commit c1e5c954020e "vfs/fsnotify: fsnotify_close can delay th
Revert "fsnotify: store struct file not struct path"
This reverts commit 3bcf3860a4ff9bbc522820b4b765e65e4deceb3e (and the accompanying commit c1e5c954020e "vfs/fsnotify: fsnotify_close can delay the final work in fput" that was a horribly ugly hack to make it work at all).
The 'struct file' approach not only causes that disgusting hack, it somehow breaks pulseaudio, probably due to some other subtlety with f_count handling.
Fix up various conflicts due to later fsnotify work.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v2.6.35 |
|
#
c1e5c954 |
| 28-Jul-2010 |
Eric Paris <eparis@redhat.com> |
vfs/fsnotify: fsnotify_close can delay the final work in fput
fanotify almost works like so:
user context calls fsnotify_* function with a struct file. fsnotify takes a reference on the struct p
vfs/fsnotify: fsnotify_close can delay the final work in fput
fanotify almost works like so:
user context calls fsnotify_* function with a struct file. fsnotify takes a reference on the struct path user context goes about it's buissiness
at some later point in time the fsnotify listener gets the struct path fanotify listener calls dentry_open() to create a file which userspace can deal with listener drops the reference on the struct path at some later point the listener calls close() on it's new file
With the switch from struct path to struct file this presents a problem for fput() and fsnotify_close(). fsnotify_close() is called when the filp has already reached 0 and __fput() wants to do it's cleanup.
The solution presented here is a bit odd. If an event is created from a struct file we take a reference on the file. We check however if the f_count was already 0 and if so we take an EXTRA reference EVEN THOUGH IT WAS ZERO. In __fput() (where we know the f_count hit 0 once) we check if the f_count is non-zero and if so we drop that 'extra' ref and return without destroying the file.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
3bcf3860 |
| 28-Jul-2010 |
Eric Paris <eparis@redhat.com> |
fsnotify: store struct file not struct path
Al explains that calling dentry_open() with a mnt/dentry pair is only garunteed to be safe if they are already used in an open struct file. To make sure
fsnotify: store struct file not struct path
Al explains that calling dentry_open() with a mnt/dentry pair is only garunteed to be safe if they are already used in an open struct file. To make sure this is the case don't store and use a struct path in fsnotify, always use a struct file.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
f70ab54c |
| 28-Jul-2010 |
Eric Paris <eparis@redhat.com> |
fsnotify: fsnotify_add_notify_event should return an event
Rather than the horrific void ** argument and such just to pass the fanotify_merge event back to the caller of fsnotify_add_notify_event()
fsnotify: fsnotify_add_notify_event should return an event
Rather than the horrific void ** argument and such just to pass the fanotify_merge event back to the caller of fsnotify_add_notify_event() have those things return an event if it was different than the event suggusted to be added.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
5ba08e2e |
| 28-Jul-2010 |
Eric Paris <eparis@redhat.com> |
fsnotify: add pr_debug throughout
It can be hard to debug fsnotify since there are so few printks. Use pr_debug to allow for dynamic debugging.
Signed-off-by: Eric Paris <eparis@redhat.com>
|
Revision tags: v2.6.35-rc6, v2.6.35-rc5, v2.6.35-rc4, v2.6.35-rc3, v2.6.35-rc2, v2.6.35-rc1, v2.6.34, v2.6.34-rc7, v2.6.34-rc6, v2.6.34-rc5, v2.6.34-rc4, v2.6.34-rc3, v2.6.34-rc2, v2.6.34-rc1, v2.6.33, v2.6.33-rc8 |
|
#
59b0df21 |
| 08-Feb-2010 |
Eric Paris <eparis@redhat.com> |
fsnotify: use unsigned char * for dentry->d_name.name
fsnotify was using char * when it passed around the d_name.name string internally but it is actually an unsigned char *. This patch switches fs
fsnotify: use unsigned char * for dentry->d_name.name
fsnotify was using char * when it passed around the d_name.name string internally but it is actually an unsigned char *. This patch switches fsnotify to use unsigned and should silence some pointer signess warnings which have popped out of xfs. 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.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
Revision tags: v2.6.33-rc7, v2.6.33-rc6, v2.6.33-rc5, v2.6.33-rc4, v2.6.33-rc3, v2.6.33-rc2 |
|
#
6e5f77b3 |
| 17-Dec-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: intoduce a notification merge argument
Each group can define their own notification (and secondary_q) merge function. Inotify does tail drop, fanotify does matching and drop which can act
fsnotify: intoduce a notification merge argument
Each group can define their own notification (and secondary_q) merge function. Inotify does tail drop, fanotify does matching and drop which can actually allocate a completely new event. But for fanotify to properly deal with permissions events it needs to know the new event which was ultimately added to the notification queue. This patch just implements a void ** argument which is passed to the merge function. fanotify can use this field to pass the new event back to higher layers.
Signed-off-by: Eric Paris <eparis@redhat.com> for fanotify to properly deal with permissions events
show more ...
|
#
32c32632 |
| 17-Dec-2009 |
Andreas Gruenbacher <agruen@suse.de> |
fanotify: Add pids to events
Pass the process identifiers of the triggering processes to fanotify listeners: this information is useful for event filtering and logging.
Signed-off-by: Andreas Gruen
fanotify: Add pids to events
Pass the process identifiers of the triggering processes to fanotify listeners: this information is useful for event filtering and logging.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
72acc854 |
| 17-Dec-2009 |
Andreas Gruenbacher <agruen@suse.de> |
fsnotify: kill FSNOTIFY_EVENT_FILE
Some fsnotify operations send a struct file. This is more information than we technically need. We instead send a struct path in all cases instead of sometimes a
fsnotify: kill FSNOTIFY_EVENT_FILE
Some fsnotify operations send a struct file. This is more information than we technically need. We instead send a struct path in all cases instead of sometimes a path and sometimes a file.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
cac69dad |
| 17-Dec-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: lock annotation for event replacement
fsnotify_replace_event need to lock both the old and the new event. This causes lockdep to get all pissed off since it dosn't know this is safe. It's
fsnotify: lock annotation for event replacement
fsnotify_replace_event need to lock both the old and the new event. This causes lockdep to get all pissed off since it dosn't know this is safe. It's safe in this case since the new event is impossible to be reached from other places in the kernel.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
1201a536 |
| 17-Dec-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: replace an event on a list
fanotify would like to clone events already on its notification list, make changes to the new event, and then replace the old event on the list with the new even
fsnotify: replace an event on a list
fanotify would like to clone events already on its notification list, make changes to the new event, and then replace the old event on the list with the new event. This patch implements the replace functionality of that process.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
b4e4e140 |
| 17-Dec-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: clone existing events
fsnotify_clone_event will take an event, clone it, and return the cloned event to the caller. Since events may be in use by multiple fsnotify groups simultaneously c
fsnotify: clone existing events
fsnotify_clone_event will take an event, clone it, and return the cloned event to the caller. Since events may be in use by multiple fsnotify groups simultaneously certain event entries (such as the mask) cannot be changed after the event was created. Since fanotify would like to merge events happening on the same file it needs a new clean event to work with so it can change any fields it wishes.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
74766bbf |
| 17-Dec-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: per group notification queue merge types
inotify only wishes to merge a new event with the last event on the notification fifo. fanotify is willing to merge any events including by means
fsnotify: per group notification queue merge types
inotify only wishes to merge a new event with the last event on the notification fifo. fanotify is willing to merge any events including by means of bitwise OR masks of multiple events together. This patch moves the inotify event merging logic out of the generic fsnotify notification.c and into the inotify code. This allows each use of fsnotify to provide their own merge functionality.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
Revision tags: v2.6.33-rc1 |
|
#
6f3a539e |
| 17-Dec-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: use kmem_cache_zalloc to simplify event initialization
fsnotify event initialization is done entry by entry with almost everything set to either 0 or NULL. Use kmem_cache_zalloc and only
fsnotify: use kmem_cache_zalloc to simplify event initialization
fsnotify event initialization is done entry by entry with almost everything set to either 0 or NULL. Use kmem_cache_zalloc and only initialize things that need non-zero initialization. Also means we don't have to change initialization entries based on the config options.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
b4277d3d |
| 17-Dec-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: use fsnotify_create_event to allocate the q_overflow event
Currently fsnotify defines a static fsnotify event which is sent when a group overflows its allotted queue length. This patch ju
fsnotify: use fsnotify_create_event to allocate the q_overflow event
Currently fsnotify defines a static fsnotify event which is sent when a group overflows its allotted queue length. This patch just allocates that event from the event cache rather than defining it statically. There is no known reason that the current implementation is wrong, but this makes sure the event is initialized and created like any other.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
Revision tags: v2.6.32, v2.6.32-rc8, v2.6.32-rc7, v2.6.32-rc6, v2.6.32-rc5 |
|
#
3de0ef4f |
| 14-Oct-2009 |
Wei Yongjun <yjwei@cn.fujitsu.com> |
inotify: fix coalesce duplicate events into a single event in special case
If we do rename a dir entry, like this:
rename("/tmp/ino7UrgoJ.rename1", "/tmp/ino7UrgoJ.rename2") rename("/tmp/ino7Ur
inotify: fix coalesce duplicate events into a single event in special case
If we do rename a dir entry, like this:
rename("/tmp/ino7UrgoJ.rename1", "/tmp/ino7UrgoJ.rename2") rename("/tmp/ino7UrgoJ.rename2", "/tmp/ino7UrgoJ")
The duplicate events should be coalesced into a single event. But those two events do not be coalesced into a single event, due to some bad check in event_compare(). It can not match the two NULL inodes as the same event.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
Revision tags: v2.6.32-rc4, v2.6.32-rc3, v2.6.32-rc1, v2.6.32-rc2, v2.6.31, v2.6.31-rc9, v2.6.31-rc8, v2.6.31-rc7 |
|
#
cd94c8bb |
| 16-Aug-2009 |
Eric Paris <eparis@redhat.com> |
inotify: tail drop inotify q_overflow events
In f44aebcc the tail drop logic of events with no file backing (q_overflow and in_ignored) was reversed so IN_IGNORED events would never be tail dropped.
inotify: tail drop inotify q_overflow events
In f44aebcc the tail drop logic of events with no file backing (q_overflow and in_ignored) was reversed so IN_IGNORED events would never be tail dropped. This now means that Q_OVERFLOW events are NOT tail dropped. The fix is to not tail drop IN_IGNORED, but to tail drop Q_OVERFLOW.
Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
eef3a116 |
| 16-Aug-2009 |
Eric Paris <eparis@redhat.com> |
notify: unused event private race
inotify decides if private data it passed to get added to an event was used by checking list_empty(). But it's possible that the event may have been dequeued and t
notify: unused event private race
inotify decides if private data it passed to get added to an event was used by checking list_empty(). But it's possible that the event may have been dequeued and the private event removed so it would look empty.
The fix is to use the return code from fsnotify_add_notify_event rather than looking at the list.
Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v2.6.31-rc6, v2.6.31-rc5, v2.6.31-rc4 |
|
#
f44aebcc |
| 15-Jul-2009 |
Eric Paris <eparis@redhat.com> |
inotify: use GFP_NOFS under potential memory pressure
inotify can have a watchs removed under filesystem reclaim.
================================= [ INFO: inconsistent lock state ] 2.6.31-rc2 #16
inotify: use GFP_NOFS under potential memory pressure
inotify can have a watchs removed under filesystem reclaim.
================================= [ INFO: inconsistent lock state ] 2.6.31-rc2 #16 --------------------------------- inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage. khubd/217 [HC0[0]:SC0[0]:HE1:SE1] takes: (iprune_mutex){+.+.?.}, at: [<c10ba899>] invalidate_inodes+0x20/0xe3 {IN-RECLAIM_FS-W} state was registered at: [<c10536ab>] __lock_acquire+0x2c9/0xac4 [<c1053f45>] lock_acquire+0x9f/0xc2 [<c1308872>] __mutex_lock_common+0x2d/0x323 [<c1308c00>] mutex_lock_nested+0x2e/0x36 [<c10ba6ff>] shrink_icache_memory+0x38/0x1b2 [<c108bfb6>] shrink_slab+0xe2/0x13c [<c108c3e1>] kswapd+0x3d1/0x55d [<c10449b5>] kthread+0x66/0x6b [<c1003fdf>] kernel_thread_helper+0x7/0x10 [<ffffffff>] 0xffffffff
Two things are needed to fix this. First we need a method to tell fsnotify_create_event() to use GFP_NOFS and second we need to stop using one global IN_IGNORED event and allocate them one at a time. This solves current issues with multiple IN_IGNORED on a queue having tail drop problems and simplifies the allocations since we don't have to worry about two tasks opperating on the IGNORED event concurrently.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
Revision tags: v2.6.31-rc3 |
|
#
c05594b6 |
| 13-Jul-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: fix inotify tail drop check with path entries
fsnotify drops new events when they are the same as the tail event on the queue to be sent to userspace. The problem is that if the event com
fsnotify: fix inotify tail drop check with path entries
fsnotify drops new events when they are the same as the tail event on the queue to be sent to userspace. The problem is that if the event comes with a path we forget to break out of the switch statement and fall into the code path which matches on events that do not have any type of file backed information (things like IN_UNMOUNT and IN_Q_OVERFLOW). The problem is that this code thinks all such events should be dropped. Fix is to add a break.
Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
#
4a148ba9 |
| 13-Jul-2009 |
Eric Paris <eparis@redhat.com> |
inotify: check filename before dropping repeat events
inotify drops events if the last event on the queue is the same as the current event. But it does 2 things wrong. First it is comparing old->i
inotify: check filename before dropping repeat events
inotify drops events if the last event on the queue is the same as the current event. But it does 2 things wrong. First it is comparing old->inode with new->inode. But after an event if put on the queue the ->inode is no longer allowed to be used. It's possible between the last event and this new event the inode could be reused and we would falsely match the inode's memory address between two differing events.
The second problem is that when a file is removed fsnotify is passed the negative dentry for the removed object rather than the postive dentry from immediately before the removal. This mean the (broken) inotify tail drop code was matching the NULL ->inode of differing events.
The fix is to check the file name which is stored with events when doing the tail drop instead of wrongly checking the address of the stored ->inode.
Reported-by: Scott James Remnant <scott@ubuntu.com> Signed-off-by: Eric Paris <eparis@redhat.com>
show more ...
|
Revision tags: v2.6.31-rc2, v2.6.31-rc1, v2.6.30, v2.6.30-rc8, v2.6.30-rc7 |
|
#
e4aff117 |
| 21-May-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: allow groups to add private data to events
inotify needs per group information attached to events. This patch allows groups to attach private information and implements a callback so that
fsnotify: allow groups to add private data to events
inotify needs per group information attached to events. This patch allows groups to attach private information and implements a callback so that information can be freed when an event is being destroyed.
Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de>
show more ...
|
#
47882c6f |
| 21-May-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: add correlations between events
As part of the standard inotify events it includes a correlation cookie between two dentry move operations. This patch includes the same behaviour in fsnot
fsnotify: add correlations between events
As part of the standard inotify events it includes a correlation cookie between two dentry move operations. This patch includes the same behaviour in fsnotify events. It is needed so that inotify userspace can be implemented on top of fsnotify.
Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de>
show more ...
|
#
62ffe5df |
| 21-May-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: include pathnames with entries when possible
When inotify wants to send events to a directory about a child it includes the name of the original file. This patch collects that filename an
fsnotify: include pathnames with entries when possible
When inotify wants to send events to a directory about a child it includes the name of the original file. This patch collects that filename and makes it available for notification.
Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de>
show more ...
|
#
a2d8bc6c |
| 21-May-2009 |
Eric Paris <eparis@redhat.com> |
fsnotify: generic notification queue and waitq
inotify needs to do asyc notification in which event information is stored on a queue until the listener is ready to receive it. This patch implements
fsnotify: generic notification queue and waitq
inotify needs to do asyc notification in which event information is stored on a queue until the listener is ready to receive it. This patch implements a generic notification queue for inotify (and later fanotify) to store events to be sent at a later time.
Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de>
show more ...
|