LINUX: Avoid lookup ENOENT on fatal signals 30/13530/2
authorAndrew Deason <adeason@sinenomine.net>
Thu, 21 Mar 2019 20:24:06 +0000 (15:24 -0500)
committerBenjamin Kaduk <kaduk@mit.edu>
Fri, 5 Apr 2019 13:24:20 +0000 (09:24 -0400)
commit8b6ae2893b517bd4e008cae94acff70abe4d2227
tree8ab4c59e27b306863c9febb87447ac79e0b3aa61
parentb9f0b63792270383b23c6a6462cd5f4590db1975
LINUX: Avoid lookup ENOENT on fatal signals

Various Linux kernel operations on various Linux kernel versions can
fail if the current process has a pending fatal signal (i.e. SIGKILL),
including reads and writes to our local disk cache. Depending on what
and when something fails because of this, some parts of libafs throw
an ENOENT error, which may propagate up to callers, and be returned
from afs_lookup(). Notably this can happen via some functions in
src/dir/dir.c, and previously was possible with some code paths before
they were fixed by commit 2aa4cb04 (afs: Stop abusing ENOENT).

For the most part, the exact error given to the userspace caller
doesn't matter, since the process will die as soon as we return to
userspace. However, for ENOENT errors specifically for lookups, we
interpret this to mean that the target filename is known to not exist,
and so we create a negative dentry for that name, which is cached.
Future lookups for that filename will then result in ENOENT before any
AFS functions are called.

The lingering abuses of the ENOENT error code should be removed from
libafs entirely, but as an extra layer of safety, we can just avoid
returning ENOENT from lookups if the current process has a pending
fatal signal. So to do that, change all afs_lookup() callers in
src/afs/LINUX to translate ENOENT to EINTR if we have a pending fatal
signal. If fatal_signal_pending() is not available, then we don't do
this translation.

FIXES 134904

Change-Id: I00f1516c2aa0f45f1129f5d5a44150b7539c31cc
Reviewed-on: https://gerrit.openafs.org/13530
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
src/afs/LINUX/osi_vnodeops.c
src/cf/linux-kernel-func.m4