29 Oct, 2010

1 commit


12 Oct, 2010

1 commit

  • This patch disables the fanotify syscalls by just not building them and
    letting the cond_syscall() statements in kernel/sys_ni.c redirect them
    to sys_ni_syscall().

    It was pointed out by Tvrtko Ursulin that the fanotify interface did not
    include an explicit prioritization between groups. This is necessary
    for fanotify to be usable for hierarchical storage management software,
    as they must get first access to the file, before inotify-like notifiers
    see the file.

    This feature can be added in an ABI compatible way in the next release
    (by using a number of bits in the flags field to carry the info) but it
    was suggested by Alan that maybe we should just hold off and do it in
    the next cycle, likely with an (new) explicit argument to the syscall.
    I don't like this approach best as I know people are already starting to
    use the current interface, but Alan is all wise and noone on list backed
    me up with just using what we have. I feel this is needlessly ripping
    the rug out from under people at the last minute, but if others think it
    needs to be a new argument it might be the best way forward.

    Three choices:
    Go with what we got (and implement the new feature next cycle). Add a
    new field right now (and implement the new feature next cycle). Wait
    till next cycle to release the ABI (and implement the new feature next
    cycle). This is number 3.

    Signed-off-by: Eric Paris
    Signed-off-by: Linus Torvalds

    Eric Paris
     

28 Jul, 2010

1 commit

  • fanotify is a novel file notification system which bases notification on
    giving userspace both an event type (open, close, read, write) and an open
    file descriptor to the object in question. This should address a number of
    races and problems with other notification systems like inotify and dnotify
    and should allow the future implementation of blocking or access controlled
    notification. These are useful for on access scanners or hierachical storage
    management schemes.

    This patch just implements the basics of the fsnotify functions.

    Signed-off-by: Eric Paris

    Eric Paris
     

22 Jul, 2009

1 commit

  • fsnotify doens't give the user anything. If someone chooses inotify or
    dnotify it should build fsnotify, if they don't select one it shouldn't be
    built. This patch changes fsnotify to be a def_bool=n and makes everything
    else select it. Also fixes the issue people complained about on lwn where
    gdm hung because they didn't have inotify and they didn't get the inotify
    build option.....

    Signed-off-by: Eric Paris

    Eric Paris
     

12 Jun, 2009

1 commit

  • fsnotify is a backend for filesystem notification. fsnotify does
    not provide any userspace interface but does provide the basis
    needed for other notification schemes such as dnotify. fsnotify
    can be extended to be the backend for inotify or the upcoming
    fanotify. fsnotify provides a mechanism for "groups" to register for
    some set of filesystem events and to then deliver those events to
    those groups for processing.

    fsnotify has a number of benefits, the first being actually shrinking the size
    of an inode. Before fsnotify to support both dnotify and inotify an inode had

    unsigned long i_dnotify_mask; /* Directory notify events */
    struct dnotify_struct *i_dnotify; /* for directory notifications */
    struct list_head inotify_watches; /* watches on this inode */
    struct mutex inotify_mutex; /* protects the watches list

    But with fsnotify this same functionallity (and more) is done with just

    __u32 i_fsnotify_mask; /* all events for this inode */
    struct hlist_head i_fsnotify_mark_entries; /* marks on this inode */

    That's right, inotify, dnotify, and fanotify all in 64 bits. We used that
    much space just in inotify_watches alone, before this patch set.

    fsnotify object lifetime and locking is MUCH better than what we have today.
    inotify locking is incredibly complex. See 8f7b0ba1c8539 as an example of
    what's been busted since inception. inotify needs to know internal semantics
    of superblock destruction and unmounting to function. The inode pinning and
    vfs contortions are horrible.

    no fsnotify implementers do allocation under locks. This means things like
    f04b30de3 which (due to an overabundance of caution) changes GFP_KERNEL to
    GFP_NOFS can be reverted. There are no longer any allocation rules when using
    or implementing your own fsnotify listener.

    fsnotify paves the way for fanotify. In brief fanotify is a notification
    mechanism that delivers the lisener both an 'event' and an open file descriptor
    to the object in question. This means that fanotify is pathname agnostic.
    Some on lkml may not care for the original companies or users that pushed for
    TALPA, but fanotify was designed with flexibility and input for other users in
    mind. The readahead group expressed interest in fanotify as it could be used
    to profile disk access on boot without breaking the audit system. The desktop
    search groups have also expressed interest in fanotify as it solves a number
    of the race conditions and problems present with managing inotify when more
    than a limited number of specific files are of interest. fanotify can provide
    for a userspace access control system which makes it a clean interface for AV
    vendors to hook without trying to do binary patching on the syscall table,
    LSM, and everywhere else they do their things today. With this patch series
    fanotify can be implemented in less than 1200 lines of easy to review code.
    Almost all of which is the socket based user interface.

    This patch series builds fsnotify to the point that it can implement
    dnotify and inotify_user. Patches exist and will be sent soon after
    acceptance to finish the in kernel inotify conversion (audit) and implement
    fanotify.

    Signed-off-by: Eric Paris
    Acked-by: Al Viro
    Cc: Christoph Hellwig

    Eric Paris
     

01 Jan, 2009

1 commit

  • Creating a generic filesystem notification interface, fsnotify, which will be
    used by inotify, dnotify, and eventually fanotify is really starting to
    clutter the fs directory. This patch simply moves inotify and dnotify into
    fs/notify/inotify and fs/notify/dnotify respectively to make both current fs/
    and future notification tidier.

    Signed-off-by: Eric Paris
    Signed-off-by: Al Viro

    Eric Paris