[lkml]   [2001]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
On Thu, Sep 27, 2001 at 05:03:49PM -0700, Linus Torvalds wrote:
> On Fri, 28 Sep 2001, Andrea Arcangeli wrote:
> >
> > Moving clear_bit just above submit_bh will fix it (please Robert make
> > this change before testing it), because if we block in submit_bh in the
> > bounce, then we won't deadlock on ourself because of the pagehighmem
> > check
> We won't block on _ourselves_, but we can block on _two_ people doing it,

If other people waits for us it's ok (if they waits it means they're not
using GFP_NOIO and they're also not using GFP_NOHIGHIO).

We cannot wait on other two people doing it since they would be highmem
pages and the pagehighmem check forbids that.

> and blocking on each others requests that are blocked waiting on a bounce
> buffer. Both will have one locked buffer, both will be waiting for the
> other person unlocking that buffer, and neither will ever make progress.
> You could clear that bit _after_ the bounce buffer allocation, I suspect.

I don't think it's necessary.

> But I also suspect that it doesn't matter much, and as I can imagine
> similar problems with GFP_NOIO and loopback etc (do you see any reason why
> loopback couldn't deadlock on waiting for itself?), I think the GFP_XXX
> thing is the proper fix.

GFP_NOIO is a no brainer, it cannot go wrong see the other email.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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