14 Jan, 2012

1 commit

  • I don't know how I missed this obvious mistake when I
    reviewed Als' patches, sorry.

    [ Quoting Al:

    Grr... Note to self: do git status *and* git stash show -p
    before git push. Nothing like "WTF? I'd fixed that braino"
    feeling ;-/

    Al sent the same patch - it got broken in commit d668dc56631d:
    "autofs4: deal with autofs4_write/autofs4_write races". ]

    Reported-and-tested-by: Dave Airlie
    Signed-off-by: Ian Kent
    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Ian Kent
     

11 Jan, 2012

3 commits

  • Just serialize the actual writing of packets into pipe on
    a new mutex, independent from everything else in the locking
    hierarchy. As soon as something has started feeding a piece
    of packet into the pipe to daemon, we *want* everything else
    about to try the same to wait until we are done.

    Acked-by: Ian Kent
    Signed-off-by: Al Viro

    Al Viro
     
  • we need to hold ->wq_mutex while we are forming the packet to send,
    lest we have autofs4_catatonic_mode() setting wq->name.name to NULL
    just as autofs4_notify_daemon() decides to memcpy() from it...

    We do have check for catatonic mode immediately after that (under
    ->wq_mutex, as it ought to be) and packet won't be actually sent,
    but it'll be too late for us if we oops on that memcpy() from NULL...

    Fix is obvious - just extend the area covered by ->wq_mutex over
    that switch and check whether it's catatonic *before* doing anything
    else.

    Acked-by: Ian Kent
    Signed-off-by: Al Viro

    Al Viro
     
  • We need to recheck ->catatonic after autofs4_wait() got ->wq_mutex
    for good, or we might end up with wq inserted into queue after
    autofs4_catatonic_mode() had done its thing. It will stick there
    forever, since there won't be anything to clear its ->name.name.

    A bit of a complication: validate_request() drops and regains ->wq_mutex.
    It actually ends up the most convenient place to stick the check into...

    Acked-by: Ian Kent
    Signed-off-by: Al Viro

    Al Viro
     

09 Aug, 2011

1 commit

  • The previous comit made the autofs4 debug printouts check types against
    the printout format, and uncovered this bug:

    fs/autofs4/waitq.c:106:2: warning: format ‘%08lx’ expects type ‘long unsigned int’, but argument 4 has type ‘autofs_wqt_t’

    which is due to the insane type for wait_queue_token. That thing should
    be some fixed well-defined size (preferably just 'unsigned int' or
    'u32') but for unexplained reasons it is randomly either 'unsigned long'
    or 'unsigned int' depending on the architecture.

    For now, cast it to 'unsigned long' for printing, the way we do
    elsewhere. Somebody else can try to explain the typedef mess.

    (There's a reason we don't support excessive use of typedefs in the
    kernel: it's usually just a good way of confusing yourself).

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

25 Mar, 2011

1 commit

  • The autofs4_lock introduced by the rcu-walk changes has unnecessarily
    broad scope. The locking is better handled by the per-autofs super
    block lookup_lock.

    Signed-off-by: Ian Kent
    Acked-by: David Howells
    Signed-off-by: Al Viro

    Ian Kent
     

16 Jan, 2011

1 commit

  • It is possible for the check in wait.c:validate_request() to return
    an incorrect result if the dentry that was mounted upon has changed
    during the callback.

    Signed-off-by: Ian Kent
    Signed-off-by: David Howells
    Signed-off-by: Al Viro

    Ian Kent
     

07 Jan, 2011

2 commits

  • dcache_lock no longer protects anything. remove it.

    Signed-off-by: Nick Piggin

    Nick Piggin
     
  • The remaining usages for dcache_lock is to allow atomic, multi-step read-side
    operations over the directory tree by excluding modifications to the tree.
    Also, to walk in the leaf->root direction in the tree where we don't have
    a natural d_lock ordering.

    This could be accomplished by taking every d_lock, but this would mean a
    huge number of locks and actually gets very tricky.

    Solve this instead by using the rename seqlock for multi-step read-side
    operations, retry in case of a rename so we don't walk up the wrong parent.
    Concurrent dentry insertions are not serialised against. Concurrent deletes
    are tricky when walking up the directory: our parent might have been deleted
    when dropping locks so also need to check and retry for that.

    We can also use the rename lock in cases where livelock is a worry (and it
    is introduced in subsequent patch).

    Signed-off-by: Nick Piggin

    Nick Piggin
     

10 Jun, 2009

1 commit

  • The recent ->lookup() deadlock correction required the directory inode
    mutex to be dropped while waiting for expire completion. We were
    concerned about side effects from this change and one has been identified.

    I saw several error messages.

    They cause autofs to become quite confused and don't really point to the
    actual problem.

    Things like:

    handle_packet_missing_direct:1376: can't find map entry for (43,1827932)

    which is usually totally fatal (although in this case it wouldn't be
    except that I treat is as such because it normally is).

    do_mount_direct: direct trigger not valid or already mounted
    /test/nested/g3c/s1/ss1

    which is recoverable, however if this problem is at play it can cause
    autofs to become quite confused as to the dependencies in the mount tree
    because mount triggers end up mounted multiple times. It's hard to
    accurately check for this over mounting case and automount shouldn't need
    to if the kernel module is doing its job.

    There was one other message, similar in consequence of this last one but I
    can't locate a log example just now.

    When checking if a mount has already completed prior to adding a new mount
    request to the wait queue we check if the dentry is hashed and, if so, if
    it is a mount point. But, if a mount successfully completed while we
    slept on the wait queue mutex the dentry must exist for the mount to have
    completed so the test is not really needed.

    Mounts can also be done on top of a global root dentry, so for the above
    case, where a mount request completes and the wait queue entry has already
    been removed, the hashed test returning false can cause an incorrect
    callback to the daemon. Also, d_mountpoint() is not sufficient to check
    if a mount has completed for the multi-mount case when we don't have a
    real mount at the base of the tree.

    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     

07 Jan, 2009

1 commit

  • - the type assigned at mount when no type is given is changed
    from 0 to AUTOFS_TYPE_INDIRECT. This was done because 0 and
    AUTOFS_TYPE_INDIRECT were being treated implicitly as the same
    type.

    - previously, an offset mount had it's type set to
    AUTOFS_TYPE_DIRECT|AUTOFS_TYPE_OFFSET but the mount control
    re-implementation needs to be able distinguish all three types.
    So this was changed to make the type setting explicit.

    - a type AUTOFS_TYPE_ANY was added for use by the re-implementation
    when checking if a given path is a mountpoint. It's not really a
    type as we use this to ask if a given path is a mountpoint in the
    autofs_dev_ioctl_ismountpoint() function.

    - functions to set and test the autofs mount types have been added to
    improve readability and make the type usage explicit.

    - the mount type is used from user space for the mount control
    re-implementtion so, for consistency, all the definitions have
    been moved to the user space include file include/linux/auto_fs4.h.

    Signed-off-by: Ian Kent
    Signed-off-by: Jeff Moyer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     

14 Nov, 2008

1 commit

  • Wrap access to task credentials so that they can be separated more easily from
    the task_struct during the introduction of COW creds.

    Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().

    Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
    sense to use RCU directly rather than a convenient wrapper; these will be
    addressed by later patches.

    Signed-off-by: David Howells
    Reviewed-by: James Morris
    Acked-by: Serge Hallyn
    Cc: Ian Kent
    Cc: autofs@linux.kernel.org
    Signed-off-by: James Morris

    David Howells
     

17 Oct, 2008

2 commits


25 Jul, 2008

8 commits

  • We have been seeing mount requests comming to the automount daemon for
    keys of the form "/" which are lookups for
    invalid map keys. But we can check for this in the kernel module and
    return a fail immediately, without having to send a request to the daemon.

    It is possible to recognise these requests are invalid based on whether
    the request dentry is negative and its relation to the autofs file system
    root.

    For example, given the indirect multi-mount map entry:

    idm1 \
    /mm1 :/
    /mm2 :/

    For a request to mount idm1, IS_ROOT((idm1)->d_parent) will be always be
    true and the dentry may be negative. But directories idm1/mm1 and
    idm1/mm2 will always be created as part of the mount request for idm1. So
    any mount request within idm1 itself must have a positive dentry otherwise
    the map key is invalid.

    In version 4 these multi-mount entries are all mounted and umounted as a
    single request and in version 5 the directories idm1/mm1 and idm1/mm2 are
    created and an autofs fs mounted on them to act as a mount trigger so the
    above is also true.

    This also holds true for the autofs version 4 pseudo direct mount feature.
    When this feature is used without the "--ghost" option automount(8) will
    create internal submounts as we go down the map key paths which are
    essentially normal indirect mounts for which the above holds. If the
    "--ghost" option is given the directories for map keys are created at
    daemon startup so valid map entries correspond to postive dentries in the
    autofs fs.

    autofs version 5 direct mount maps are similar except that the IS_ROOT
    check is not needed. This has been addressed in a previous patch tittled
    "autofs4 - detect invalid direct mount requests".

    For example, given the direct multi-mount map entry:

    /test/dm1 \
    /mm1 :/
    /mm2 :/

    An autofs fs is mounted on /test/dm1 as a trigger mount and when a mount
    is triggered for /test/dm1, the multi-mount offset directories
    /test/dm1/mm1 and /test/dm1/mm2 are created and an autofs fs is mounted on
    them to act as mount triggers. So valid direct mount requests must always
    have a positive dentry if they correspond to a valid map entry.

    Signed-off-by: Ian Kent
    Acked-by: Jeff Moyer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     
  • autofs v5 direct and offset mounts within an autofs filesystem are
    triggered by existing autofs triger mounts so the mount point dentry must
    be positive. If the mount point dentry is negative then the trigger
    doesn't exist so we can return fail immediately.

    Signed-off-by: Ian Kent
    Cc: Jeff Moyer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     
  • If an autofs mount becomes catatonic before autofs4_wait_release() is
    called the wait queue counter will not be decremented down to zero and the
    entry will never be freed. There are also races decrementing the wait
    counter in the wait release function. To deal with this the counter needs
    to be updated while holding the wait queue mutex and waiters need to be
    woken up unconditionally when the wait is removed from the queue to ensure
    we eventually free the wait.

    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     
  • It is possible for an autofs mount to become catatonic (and for the daemon
    communication pipe to become NULL) after a wait has been initiallized but
    before the request has been sent to the daemon. We need to check for this
    before sending the request packet.

    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     
  • It see that the patch tittled "autofs4 - fix pending mount race" is
    missing a change that I had recently made.

    It's missing a kfree for the case mutex_lock_interruptible() fails
    to aquire the wait queue mutex.

    Signed-off-by: Ian Kent
    Cc: Jeff Moyer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     
  • Close a race between a pending mount that is about to finish and a new
    lookup for the same directory.

    Process P1 triggers a mount of directory foo. It sets
    DCACHE_AUTOFS_PENDING in the ->lookup routine, creates a waitq entry for
    'foo', and calls out to the daemon to perform the mount. The autofs
    daemon will then create the directory 'foo', using a new dentry that will
    be hashed in the dcache.

    Before the mount completes, another process, P2, tries to walk into the
    'foo' directory. The vfs path walking code finds an entry for 'foo' and
    calls the revalidate method. Revalidate finds that the entry is not
    PENDING (because PENDING was never set on the dentry created by the
    mkdir), but it does find the directory is empty. Revalidate calls
    try_to_fill_dentry, which sets the PENDING flag and then calls into the
    autofs4 wait code to trigger or wait for a mount of 'foo'. The wait code
    finds the entry for 'foo' and goes to sleep waiting for the completion of
    the mount.

    Yet another process, P3, tries to walk into the 'foo' directory. This
    process again finds a dentry in the dcache for 'foo', and calls into the
    autofs revalidate code.

    The revalidate code finds that the PENDING flag is set, and so calls
    try_to_fill_dentry.

    a) try_to_fill_dentry sets the PENDING flag redundantly for this
    dentry, then calls into the autofs4 wait code.

    b) the autofs4 wait code takes the waitq mutex and searches for an
    entry for 'foo'

    Between a and b, P1 is woken up because the mount completed. P1 takes the
    wait queue mutex, clears the PENDING flag from the dentry, and removes the
    waitqueue entry for 'foo' from the list.

    When it releases the waitq mutex, P3 (eventually) acquires it. At this
    time, it looks for an existing waitq for 'foo', finds none, and so creates
    a new one and calls out to the daemon to mount the 'foo' directory.

    Now, the reason that three processes are required to trigger this race is
    that, because the PENDING flag is not set on the dentry created by mkdir,
    the window for the race would be way to slim for it to ever occur.
    Basically, between the testing of d_mountpoint(dentry) and the taking of
    the waitq mutex, the mount would have to complete and the daemon would
    have to be woken up, and that in turn would have to wake up P1. This is
    simply impossible. Add the third process, though, and it becomes slightly
    more likely.

    Signed-off-by: Jeff Moyer
    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     
  • The autofs4_catatonic_mode() function accesses the wait queue without any
    locking but can be called at any time. This could lead to a possible
    double free of the name field of the wait and a double fput of the daemon
    communication pipe or an fput of a NULL file pointer.

    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     
  • The autofs_wait_queue already contains all of the fields of the
    struct qstr, so change it into a qstr.

    This patch, from Jeff Moyer, has been modified a liitle by myself.

    Signed-off-by: Jeff Moyer
    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Moyer
     

01 May, 2008

1 commit


19 Oct, 2007

1 commit

  • Get rid of sparse related warnings from places that use integer as NULL
    pointer.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Stephen Hemminger
    Cc: Andi Kleen
    Cc: Jeff Garzik
    Cc: Matt Mackall
    Cc: Ian Kent
    Cc: Arnd Bergmann
    Cc: Davide Libenzi
    Cc: Stephen Smalley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Hemminger
     

21 Feb, 2007

1 commit

  • The current header file definitions for autofs version 5 have caused a couple
    of problems for application builds downstream.

    This fixes the problem by separating the definitions.

    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     

15 Nov, 2006

1 commit

  • Resolve the panic on failed mount of an autofs filesystem originally
    reported by Mao Bibo.

    It addresses two issues that happen after the mount fail. The first a NULL
    pointer reference to a field (pipe) in the autofs superblock info structure
    and second the lack of super block cleanup by the autofs and autofs4
    modules.

    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     

12 Oct, 2006

1 commit

  • Make sure all dentries refs are released before calling kill_anon_super() so
    that the assumption that generic_shutdown_super() can completely destroy the
    dentry tree for there will be no external references holds true.

    What was being done in the put_super() superblock op, is now done in the
    kill_sb() filesystem op instead, prior to calling kill_anon_super().

    This makes the struct autofs_sb_info::root member variable redundant (since
    sb->s_root is still available), and so that is removed. The calls to
    shrink_dcache_sb() are also removed since they're also redundant as
    shrink_dcache_for_umount() will now be called after the cleanup routine.

    Signed-off-by: David Howells
    Acked-by: Ian Kent
    Cc: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

16 May, 2006

1 commit

  • This patch fixes two problems.

    First, the comparison of entries in the waitq.c was incorrect.

    Second, the NFY_NONE check was incorrect. The test of whether the dentry
    is mounted if ineffective, for example, if an expire fails then we could
    wait forever on a non existant expire. The bug was identified by Jeff
    Moyer.

    The patch changes autofs4 to wait on expires only as this is all that's
    needed. If there is no existing wait when autofs4_wait is call with a type
    of NFY_NONE it delays until either a wait appears or the the expire flag is
    cleared.

    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     

28 Mar, 2006

4 commits


23 Mar, 2006

1 commit

  • Semaphore to mutex conversion.

    The conversion was generated via scripts, and the result was validated
    automatically via a script as well.

    Signed-off-by: Ingo Molnar
    Acked-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

07 Nov, 2005

1 commit

  • This is the fs/ part of the big kfree cleanup patch.

    Remove pointless checks for NULL prior to calling kfree() in fs/.

    Signed-off-by: Jesper Juhl
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     

08 Jul, 2005

1 commit


22 Jun, 2005

1 commit

  • At the tail end of an expire it's possible for a process to enter
    autofs4_wait, with a waitq type of NFY_NONE but find that the expire is
    finished. In this cause autofs4_wait will try to create a new wait but not
    notify the daemon leading to a hang. As the wait type is meant to delay mount
    requests from revalidate or lookup during an expire and the expire is done all
    we need to do is check if the dentry is a mountpoint. If it's not then we're
    done.

    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     

01 May, 2005

1 commit

  • It's possible for an event wait request to arive before the event
    requestor. If this happens the daemon never gets notified and autofs
    hangs.

    Signed-off-by: Ian Kent
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ian Kent
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds