Messages in this thread | | | Date | Mon, 3 Jul 2000 22:01:09 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: More 2.2.17pre9 VM issues |
| |
Hi,
On Mon, Jul 03, 2000 at 06:50:45PM +0200, Andrea Arcangeli wrote:
> With a new logic I now know when somebody have an fs lock held from under > me, thus I can skip the write in such cases.
But you can't afford do skip it. If I create a writable mmap and fill it with as much dirty data as we have got available physical memory, and then I write() a 1GB swapped-out virtual area to the same file, what are you going to do to clear me some free memory for the write? write(2) is an unbounded operation and you can't disable VM reclaim on that file for the duration of the write.
> However I see that if some filesystem down() a private lock needed by the > write(shared_file) path and then it generate a page fault it may deadlock > too.
Yes, but as long as it is using generic_file_write we can pretty much guarantee to be safe here --- we copy from the user buffer into the page cache before telling the filesystem to write the data, so the fs's internal locking doesn't overlap the VM operation in the write path.
> So checking down() in the filesystems (and not only in the VFS) will > be necessary.
Not if the fs is only being called from the page cache. If the fs is supplying its own file-write routine, then we probably need to mandate the use of non-GFP_IO calls for allocations, simply to avoid deadlock. The other solution --- disabling file reap --- is even more painful in the case above.
> >My gut feeling is that mmap002 needs such a substantial fix that we > >can't afford to fix it in 2.2. The fix above certainly won't do. > > Ok, but then we should drop the hacks that we have in 2.2.17pre9 to try to > fix this and declare MAP_SHARED allocations not relaible. I voted for this > at first (and that's what I did in 2.2.17pre6aa2) but I got this:
Right, my vote was always to revert to the 2.2.14 VM which is not perfect but which at least is reasonably well understood. We're fixing things as we go, sure, but we are breaking them too in 2.2 right now, and that is just not acceptable for a minor kernel update in a stable branch.
Cheers, 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/
| |