lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.074 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site