Re: question: spinlocks and userspace.

Stephen C. Tweedie (sct@redhat.com)
Wed, 10 Nov 1999 15:54:23 +0000 (GMT)


Hi,

On Wed, 10 Nov 1999 08:59:01 +0000 (GMT), Tigran Aivazian
<tigran@sco.COM> said:

> walk through some linked list {
> for each element take a bit thereof and append to supplied user buf
> }

> If I wished to protect the linked list with a spinlock I need to redesign
> the loop and the only way I can think of is to temporarily store those
> elements in kernel buffer and then copy the lot to userspace. But as the
> size of the acumulated buffers is not known in advance the whole thing is
> not as trivial as it should be.

In 2.3 one alternative is to map the whole user buffer into a kiobuf and
then write to the kiobuf's pages with the spinlock held: kiobufs are
guaranteed to hold pinned memory.

Alternatively you can copy the list elements one by one into a single
temporary buffer with the spinlock held, drop the lock to copy to user
space, and then retake the lock to continue accessing the list. That
does require the ability to resync your position in the list reliably,
of course. It's exactly the same problem we have in the filesystems
with things like readdir(): in that case too, the accesses to the
directory obviously have to be atomic wrt. other filesystem operations,
but we still need to resync the directory file pointer when we enter
each successive getdents() syscall.

Alternatively, can you make do with a semaphore? Even if you need to
access the data structure from inside an interrupt, a semaphore may do,
as long as the interrupt only requires read access to the list: you can
protect the list with both a read-write spinlock and a semaphore, and
require that both are held before permitting writes to the list.

That way, holding either a readonly spinlock or the semaphore will allow
read access to the list, and you can still allow interrupts to take the
read lock while you have a semaphore protecting the user-mode copy.

--Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/