OpenAFS Master Repository branch, master, updated. openafs-devel-1_9_0-11-g74f46e0

Gerrit Code Review gerrit@openafs.org
Fri, 23 Oct 2020 11:26:52 -0400


The following commit has been merged in the master branch:
commit 74f46e0912b3f9061d7fadc3b3d08a11d6adda97
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Dec 12 21:00:20 2019 -0600

    afs: Return to userspace after AFS_NEW_BKG reqs
    
    Currently, for AFS_NEW_BKG, background daemons run in the context of a
    normal user process (afsd), in order to return to run
    userspace-handled background ops. For non-AFS_NEW_BKG when
    AFS_DAEMONOP_ENV is defined, background daemons run as kernel threads
    instead, and have no corresponding userspace process.
    
    On LINUX, whether or not we run as a kernel thread has some odd
    side-effects: at least one example of this is how open file handles
    (struct file) are treated when closed. When the last reference to a
    struct file is closed, the final free is deferred to an asynchronous
    call to be executed "later", in order to avoid issues with lock
    inversion. For kernel threads, "later" means the work is schedule on
    the global system work queue (schedule_work()), but for userspace
    processes, it is scheduled on the task work queue (task_work_add()),
    which is run around when the thread returns to userspace. For
    background daemons, we never return from the relevant syscall until we
    get a userspace background request (or the client is shutting down),
    
    Commit ca472e66 (LINUX: Turn on AFS_NEW_BKG) changed LINUX to use
    AFS_NEW_BKG background daemons, so background requests now run as a
    normal userspace process, and last-reference file closes are deferred.
    Since we may never return to userspace, this means that our file
    handles (used for accessing the disk cache) may never get freed,
    leading to an unbounded number of file handles remaining open.
    
    This can be seen by seeing the first value in /proc/sys/fs/file-nr
    growing without bound (possibly slowly), as accessing /afs causes
    background requests. Eventually the number of open files can exceed
    the /proc/sys/fs/file-max limit, causing further file opens to fail,
    causing various other problems and potentially panics.
    
    To avoid this issue, define a new userspace background op, called
    AFS_USPC_NOOP, which gets returned to the afsd background daemon
    process. When afsd sees this, it just does nothing and calls the
    AFSOP_BKG_HANDLER syscall again, to go into the background daemon loop
    again. In afs_BackgroundDaemon, we return the AFS_USPC_NOOP op
    whenever there are no pending background requests, or if we've run 100
    background requests in a row without a break. This causes us to return
    to userspace periodically, preventing any such task-queued work from
    building up indefinitely.
    
    Do this for all platforms (currently just LINUX and DARWIN), in order
    to simplify the code, and possibly avoid other similar issues, since
    staying inside a syscall for so long while doing real work is arguably
    weird.
    
    Add a documentation comment block for afs_BackgroundDaemon while we're
    here.
    
    Thanks to mvitale@sinenomine.net for discovering the file leak.
    
    Change-Id: I1953d73b2142d4128b064f8c5f95a5858d7df131
    Reviewed-on: https://gerrit.openafs.org/13984
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

 src/afs/afs_daemons.c |   59 +++++++++++++++++++++++++++++++++++++++++++++++-
 src/afsd/afsd.c       |    6 +++++
 src/config/afs_args.h |    1 +
 3 files changed, 64 insertions(+), 2 deletions(-)

-- 
OpenAFS Master Repository