Absolutely ... you would need to do a get_file() in try_to_swap_out,
then a fput() after return from the swapout() method. I was just
focusing attention on the vma-does-not-have-to-exist point.
> >
> > This works for filemap_swapout, but you can not expect every regular Joe
> > driver writer to adhere to this rule.
> The result is not a rare lock-up, but it will lock-up nearly
> immediately. Even Joe would notice that.
> [I know this is ugly]
Oh, the lockup will hapen only if Joe tests his driver under huge
memory demand conditions, that too, if a page stealer decides to
victimize the vma Joe set up. Entirely missable during driver
developement, imo. Even if Joe hits the scenario, it would be cruel
for us to ask him to understand how swapping works; its enough for
him to have to worry about MP issues ...
>
> > And here's one more. Before invoking swapout(), and before loosing the
> > vmlist_lock in try_to_swap_out, the vma might be marked with a flag
> > that indicates that swapout() is looking at the vma.
> Or: use a multiple reader - single writer semaphore with "starve writer"
> policy.
> IMO that's cleaner than a semaphore with an attached waitqueue for
> do_munmap().
>
Explain ... who are the readers, and who are the writers? I think if you
are talking about a semaphore lock being held thru out swapout() in the
try_to_swap_out path, you are reduced to the same deadlock I just pointed
out. I was talking more about a monitor like approach here.
Kanoj
-
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/