[OpenAFS-devel] Locking in Linux?

[Tom Keiser]

On 4/8/06, Dean Anderson <dean@av8.com> wrote:
> I'm building openafs 1.4.0 on Aurora 2.0 beta 2, which is essentially a l=
inux
> 2.6.13 kernel.  I've just notice that there are no definitions for
>
> SPLVAR,
> NETPRI
> USERPRI
>

IIRC, these were a holdover from uniprocessor days when netpri was
sufficient to ensure mutual exclusion.  They are not sufficient to
provide safety on multiprocessors, so they have been removed.  Most of
the cache manager is protected by afs_global_lock.  Much of Rx is
protected by a bunch of afs_kmutex_t variables (on platforms where
RX_ENABLE_LOCKS is defined; which I believe is most of them).

> for use by the kernel module, for any linux variant.  I saw a patch for
> sparc64_linux26, which just had the effect of nulling out the locks, caus=
ing it
> to compile with no locking, which is may be fine on a uniprocessor (or no=
t). Is
> is really safe to run afs on SMP or even UP kernels without locks?
>

People are running AFS on largish smp boxes, so I'd say it's safe to
run on smp and preemptive UP kernels.  Granted, we do discover
deadlocks and races from time to time, but the code is mostly
thread-safe.

There is one major caveat: the code is mp-safe, NOT mp-fast.  There
are a bunch of afs_lock structs that protect broad subsystems of the
cache manager.  However, these are "pseudo-locks".  There are no
kernel mutexes associated with these structures.  Instead, entry and
exit to these locks is controlled by afs_global_lock.  Thus, they
provide a method of time division multiplexing without providing any
MP speedup.

Hope that helps,

-Tom