I've put this together for the swapoff case, and it should work OK.
There are still some problems though -- a number of places in the kernel
make decisions based on whether mm->count > 1 or not. So having an
unrelated task suddenly grap your mm means that the task now looks as
though it has a shared mmap.
Another problem is that clear_page_tables doesn't use the semaphore, so
even if your vma is safe, the page tables aren't.
> - keep track of which thread (not mm) that owns the mm semaphore, and if
> we're the mm holder then we don't need the count or semaphore stuff at
> all because we're already holding the count and the semaphore somewhere
> else..
The patch I posted for 2.0.30 dup_mmap added a flag to the task struct
to indicate we were holding the semaphore -- did that seem like a
reasonable approach?
> Although I have to say that I like Ingo's suggestion of no-wait locks.
> Then we could use spinlocks or rw-locks instead,
Yes, I like it too. You could do raceless swapout by finding a
candidate page, locating a swap page, writing it out (and _checking for
errors_!!), and then go back and see if the page still needed swapping
out. Swapoff could be rewritten to find the swap entries in use, read
them in, free the swap page, and then go look for a task using that
entry. Same amount of work, no races.
Regards,
Bill