"David S. Miller" wrote:
>
> From: Kasper Dupont <kasperd@daimi.au.dk>
> Date: Tue, 06 Aug 2002 16:16:03 +0200
>
> "David S. Miller" wrote:
> > What if we have to sleep and page in some memory from disk?
> >
> > Your idea could lead to deadlock in a multi-threaded app.
>
> Why? The page should eventually get into memory from the disk,
> at this point the process doing the copy can continue, and
> when it finishes the other processes gets waked up. While the
> copy_to_user is in progress all the processes witht this mm
> should be in noninterruptible sleep. The sleeping procces
> doesn't need to do anything to get the page into memory, so I
> cannot see the problem.
>
> What if the other thread we freeze is holding a lock we
> need in order to get the page from disk?
If the other thread is in user mode, that should not be possible.
If the other thread is in kernel mode, things starts getting
complicated. Maybe we could delay the freezing until the other
thread leaves kernel. I don't right away see if the current
thread has to wait for the other process to leave kernel and
get frozen.
I just get another idea, that might be easier to get right. If
the only problem is one process changing the mm while another
process is doing a copy_to_user, we should be able to fix it by
placing a readlock on the mm while the copy_to_user is in progress.
I don't remember if the mm is protected by a spinlock or
semaphore, if it is a spinlock maybe it could be replaced by a
semaphore? Otherwise we could prevent the copy_to_user from
completing if it has to sleep, and just release the lock if it
does go to sleep. In that case when the process gets waked up, it
has to get a special return value, that forces it to repeat the
verification of the area. (Isn't there a way to ensure the pages
are in memory before starting the actual copy, that would make
things simpler?)
-- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:razrep@daimi.au.dk or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:31 EST