On Wed, 10 Nov 1999, Stephen C. Tweedie wrote:
> 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.
this is interesting. I will look for some sample code in the kernel
tonight but if you have any particular pointers that will be appreciated.
> 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.
Yes, Ingo pointed that out but it does not look very nice. Guaranteeing
(temporary) that user buffer is pinned feels much better (if I learn how
to use it).
> Alternatively, can you make do with a semaphore?
I tried - didn't work. If you are curious, have a look at my
semaphore-based implementation (with deadlock)
http://www.ocston.org/~tigran/patches/modsem-2.3.27-p5.patch
> 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.
Silly question - do the interrupts ever do request_module()? If not, then
we can forget about the above two paragraphs?
Regards,
Tigran.
-
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/