27 Apr, 2015

1 commit

  • Pull fourth vfs update from Al Viro:
    "d_inode() annotations from David Howells (sat in for-next since before
    the beginning of merge window) + four assorted fixes"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    RCU pathwalk breakage when running into a symlink overmounting something
    fix I_DIO_WAKEUP definition
    direct-io: only inc/dec inode->i_dio_count for file systems
    fs/9p: fix readdir()
    VFS: assorted d_backing_inode() annotations
    VFS: fs/inode.c helpers: d_inode() annotations
    VFS: fs/cachefiles: d_backing_inode() annotations
    VFS: fs library helpers: d_inode() annotations
    VFS: assorted weird filesystems: d_inode() annotations
    VFS: normal filesystems (and lustre): d_inode() annotations
    VFS: security/: d_inode() annotations
    VFS: security/: d_backing_inode() annotations
    VFS: net/: d_inode() annotations
    VFS: net/unix: d_backing_inode() annotations
    VFS: kernel/: d_inode() annotations
    VFS: audit: d_backing_inode() annotations
    VFS: Fix up some ->d_inode accesses in the chelsio driver
    VFS: Cachefiles should perform fs modifications on the top layer only
    VFS: AF_UNIX sockets should call mknod on the top layer only

    Linus Torvalds
     

23 Apr, 2015

1 commit

  • Pull audit fixes from Paul Moore:
    "Seven audit patches for v4.1, all bug fixes.

    The largest, and perhaps most significant commit helps resolve some
    memory pressure issues related to the inode cache and audit, there are
    also a few small commits which help resolve some timing issues with
    the audit log queue, and the rest fall into the always popular "code
    clean-up" category.

    In general, nothing really substantial, just a nice set of maintenance
    patches"

    * 'upstream' of git://git.infradead.org/users/pcmoore/audit:
    audit: Remove condition which always evaluates to false
    audit: reduce mmap_sem hold for mm->exe_file
    audit: consolidate handling of mm->exe_file
    audit: code clean up
    audit: don't reset working wait time accidentally with auditd
    audit: don't lose set wait time on first successful call to audit_log_start()
    audit: move the tree pruning to a dedicated thread

    Linus Torvalds
     

16 Apr, 2015

1 commit


24 Feb, 2015

1 commit

  • When file auditing is enabled, during a low memory situation, a memory
    allocation with __GFP_FS can lead to pruning the inode cache. Which can,
    in turn lead to audit_tree_freeing_mark() being called. This can call
    audit_schedule_prune(), that tries to fork a pruning thread, and
    waits until the thread is created. But forking needs memory, and the
    memory allocations there are done with __GFP_FS.

    So we are waiting merrily for some __GFP_FS memory allocations to complete,
    while holding some filesystem locks. This can take a while ...

    This patch creates a single thread for pruning the tree from
    audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
    thread creation can cause.

    Reported-by: Matt Wilson
    Cc: Matt Wilson
    Signed-off-by: Imre Palik
    Reviewed-by: Richard Guy Briggs
    Signed-off-by: Paul Moore

    Imre Palik
     

14 Dec, 2014

1 commit


12 Nov, 2014

1 commit

  • Audit rules disappear when an inode they watch is evicted from the cache.
    This is likely not what we want.

    The guilty commit is "fsnotify: allow marks to not pin inodes in core",
    which didn't take into account that audit_tree adds watches with a zero
    mask.

    Adding any mask should fix this.

    Fixes: 90b1e7a57880 ("fsnotify: allow marks to not pin inodes in core")
    Signed-off-by: Miklos Szeredi
    Cc: stable@vger.kernel.org # 2.6.36+
    Signed-off-by: Paul Moore

    Miklos Szeredi
     

11 Oct, 2014

1 commit


24 Sep, 2014

1 commit

  • Various audit events dealing with adding, removing and updating rules result in
    invalid values set for the op keys which result in embedded spaces in op=
    values.

    The invalid values are
    op="add rule" set in kernel/auditfilter.c
    op="remove rule" set in kernel/auditfilter.c
    op="remove rule" set in kernel/audit_tree.c
    op="updated rules" set in kernel/audit_watch.c
    op="remove rule" set in kernel/audit_watch.c

    Replace the space in the above values with an underscore character ('_').

    Coded-by: Burn Alting
    Signed-off-by: Richard Guy Briggs

    Burn Alting
     

18 Feb, 2014

1 commit

  • My rework of handling of notification events (namely commit 7053aee26a35
    "fsnotify: do not share events between notification groups") broke
    sending of cookies with inotify events. We didn't propagate the value
    passed to fsnotify() properly and passed 4 uninitialized bytes to
    userspace instead (so it is also an information leak). Sadly I didn't
    notice this during my testing because inotify cookies aren't used very
    much and LTP inotify tests ignore them.

    Fix the problem by passing the cookie value properly.

    Fixes: 7053aee26a3548ebaba046ae2e52396ccf56ac6c
    Reported-by: Vegard Nossum
    Signed-off-by: Jan Kara

    Jan Kara
     

22 Jan, 2014

3 commits

  • We usually rely on the fact that struct members not specified in the
    initializer are set to NULL. So do that with fsnotify function pointers
    as well.

    Signed-off-by: Jan Kara
    Reviewed-by: Christoph Hellwig
    Cc: Eric Paris
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     
  • After removing event structure creation from the generic layer there is
    no reason for separate .should_send_event and .handle_event callbacks.
    So just remove the first one.

    Signed-off-by: Jan Kara
    Reviewed-by: Christoph Hellwig
    Cc: Eric Paris
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     
  • Currently fsnotify framework creates one event structure for each
    notification event and links this event into all interested notification
    groups. This is done so that we save memory when several notification
    groups are interested in the event. However the need for event
    structure shared between inotify & fanotify bloats the event structure
    so the result is often higher memory consumption.

    Another problem is that fsnotify framework keeps path references with
    outstanding events so that fanotify can return open file descriptors
    with its events. This has the undesirable effect that filesystem cannot
    be unmounted while there are outstanding events - a regression for
    inotify compared to a situation before it was converted to fsnotify
    framework. For fanotify this problem is hard to avoid and users of
    fanotify should kind of expect this behavior when they ask for file
    descriptors from notified files.

    This patch changes fsnotify and its users to create separate event
    structure for each group. This allows for much simpler code (~400 lines
    removed by this patch) and also smaller event structures. For example
    on 64-bit system original struct fsnotify_event consumes 120 bytes, plus
    additional space for file name, additional 24 bytes for second and each
    subsequent group linking the event, and additional 32 bytes for each
    inotify group for private data. After the conversion inotify event
    consumes 48 bytes plus space for file name which is considerably less
    memory unless file names are long and there are several groups
    interested in the events (both of which are uncommon). Fanotify event
    fits in 56 bytes after the conversion (fanotify doesn't care about file
    names so its events don't have to have it allocated). A win unless
    there are four or more fanotify groups interested in the event.

    The conversion also solves the problem with unmount when only inotify is
    used as we don't have to grab path references for inotify events.

    [hughd@google.com: fanotify: fix corruption preventing startup]
    Signed-off-by: Jan Kara
    Reviewed-by: Christoph Hellwig
    Cc: Eric Paris
    Cc: Al Viro
    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     

13 Jun, 2013

1 commit

  • audit_add_tree_rule() must set 'rule->tree = NULL;' firstly, to protect
    the rule itself freed in kill_rules().

    The reason is when it is killed, the 'rule' itself may have already
    released, we should not access it. one example: we add a rule to an
    inode, just at the same time the other task is deleting this inode.

    The work flow for adding a rule:

    audit_receive() -> (need audit_cmd_mutex lock)
    audit_receive_skb() ->
    audit_receive_msg() ->
    audit_receive_filter() ->
    audit_add_rule() ->
    audit_add_tree_rule() -> (need audit_filter_mutex lock)
    ...
    unlock audit_filter_mutex
    get_tree()
    ...
    iterate_mounts() -> (iterate all related inodes)
    tag_mount() ->
    tag_trunk() ->
    create_trunk() -> (assume it is 1st rule)
    fsnotify_add_mark() ->
    fsnotify_add_inode_mark() -> (add mark to inode->i_fsnotify_marks)
    ...
    get_tree(); (each inode will get one)
    ...
    lock audit_filter_mutex

    The work flow for deleting an inode:

    __destroy_inode() ->
    fsnotify_inode_delete() ->
    __fsnotify_inode_delete() ->
    fsnotify_clear_marks_by_inode() -> (get mark from inode->i_fsnotify_marks)
    fsnotify_destroy_mark() ->
    fsnotify_destroy_mark_locked() ->
    audit_tree_freeing_mark() ->
    evict_chunk() ->
    ...
    tree->goner = 1
    ...
    kill_rules() -> (assume current->audit_context == NULL)
    call_rcu() -> (rule->tree != NULL)
    audit_free_rule_rcu() ->
    audit_free_rule()
    ...
    audit_schedule_prune() -> (assume current->audit_context == NULL)
    kthread_run() -> (need audit_cmd_mutex and audit_filter_mutex lock)
    prune_one() -> (delete it from prue_list)
    put_tree(); (match the original get_tree above)

    Signed-off-by: Chen Gang
    Cc: Eric Paris
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chen Gang
     

30 Apr, 2013

1 commit


12 Jan, 2013

1 commit

  • It's possible for audit_log_start() to return NULL. Handle it in the
    various callers.

    Signed-off-by: Kees Cook
    Cc: Al Viro
    Cc: Eric Paris
    Cc: Jeff Layton
    Cc: "Eric W. Biederman"
    Cc: Julien Tinnes
    Cc: Will Drewry
    Cc: Steve Grubb
    Cc: Andrea Arcangeli
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kees Cook
     

12 Dec, 2012

1 commit


15 Aug, 2012

3 commits

  • Drop the initial reference by fsnotify_init_mark early instead of
    audit_tree_freeing_mark() at destroy time.

    In the cases we destroy the mark before we drop the initial reference we need to
    get rid of the get_mark that balances the put_mark in audit_tree_freeing_mark().

    Signed-off-by: Miklos Szeredi

    Miklos Szeredi
     
  • Refcounting of fsnotify_mark in audit tree is broken. E.g:

    refcount
    create_chunk
    alloc_chunk 1
    fsnotify_add_mark 2

    untag_chunk
    fsnotify_get_mark 3
    fsnotify_destroy_mark
    audit_tree_freeing_mark 2
    fsnotify_put_mark 1
    fsnotify_put_mark 0
    via destroy_list
    fsnotify_mark_destroy -1

    This was reported by various people as triggering Oops when stopping auditd.

    We could just remove the put_mark from audit_tree_freeing_mark() but that would
    break freeing via inode destruction. So this patch simply omits a put_mark
    after calling destroy_mark or adds a get_mark before.

    The additional get_mark is necessary where there's no other put_mark after
    fsnotify_destroy_mark() since it assumes that the caller is holding a reference
    (or the inode is keeping the mark pinned, not the case here AFAICS).

    Signed-off-by: Miklos Szeredi
    Reported-by: Valentin Avram
    Reported-by: Peter Moody
    Acked-by: Eric Paris
    CC: stable@vger.kernel.org

    Miklos Szeredi
     
  • Don't do free_chunk() after fsnotify_add_mark(). That one does a delayed unref
    via the destroy list and this results in use-after-free.

    Signed-off-by: Miklos Szeredi
    Acked-by: Eric Paris
    CC: stable@vger.kernel.org

    Miklos Szeredi
     

14 Jul, 2012

1 commit

  • copy_tree() can theoretically fail in a case other than ENOMEM, but always
    returns NULL which is interpreted by callers as -ENOMEM. Change it to return
    an explicit error.

    Also change clone_mnt() for consistency and because union mounts will add new
    error cases.

    Thanks to Andreas Gruenbacher for a bug fix.
    [AV: folded braino fix by Dan Carpenter]

    Original-author: Valerie Aurora
    Signed-off-by: David Howells
    Cc: Valerie Aurora
    Cc: Andreas Gruenbacher
    Signed-off-by: Al Viro

    David Howells
     

21 Jul, 2011

1 commit


31 Mar, 2011

1 commit


30 Oct, 2010

1 commit


28 Jul, 2010

16 commits


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo