NMIs, Locks, linked lists, barriers, and rculists, oh my!

[Valdis.Kletnieks at vt.edu]

On Wed, 03 Apr 2013 19:08:45 -0700, Arlie Stephens said:

> - I've got a linked list, with entries occassionally added from normal
> contexts.
> - Entries are never deleted from the list.

This is already busted - you *will* eventually OOM the system this way.

> This would be simple, except that the routines which READ the list may
> get called from panic(), or inside an oops, or from an NMI. It's
> important that they succeed in doing their jobs in that case, even if
> they managed to interrupt a list addition in progress.

At that point, you need to be *really* specific on what the semantics
of "succeed" really are.  In particular, do they merely need to
succeed at reading a single specific entry, or the entire list?

You should also be clear on why panic() and oops need to poke the list
(hint - if you're in panic(), you're there because the kernel is already
convinced things are too screwed up to continue, so why should you
trust your list enough to walk across it during panic()?)

> 1) Use an rculist, and hope that it really does cover this
> situation.

That's probably safe/sufficient, as long as the read semantics of
an RCU-protected region are acceptable. In particular, check the
behavior of when an update happens, compared to when it becomes
visible to readers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130404/50ea62d6/attachment.bin