linux-kernel - Re: [RFC] page fault retry with NOPAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 23 Sep 2006 15:21:40 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Andrew Morton <akpm@...l.org>
cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Mike Waychison <mikew@...gle.com>, linux-mm@...ck.org,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>
Subject: Re: [RFC] page fault retry with NOPAGE_RETRY

On Wed, 20 Sep 2006, Andrew Morton wrote:
> On Wed, 20 Sep 2006 16:54:59 +1000
> Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> > 
> > That's what I don't understand... where is the actual race that can
> > cause the livelock you are mentioning.
> 
> Suppose a program (let's call it "DoS") is written which sits in a loop
> doing fadvise(FADV_DONTNEED) against some parts of /lib/libc.so.

I agree there's an issue here, but I believe you're attacking the wrong
end, thereby complicating and uglifying the pagefault path (in every
arch) with your proposed arg block and retry limitation.

(Maybe one day there will be need for such an arg block,
but I don't see that yet.)

Isn't the real problem that fadvise(FADV_DONTNEED) is much more
powerful than it should be?  Whereas madvise(MADV_DONTNEED) is simply
releasing pages from my address space, fadvise(FADV_DONTNEED) is going
so far as to remove them from pagecache (if nothing at that instant
prevents): forcing others into I/O.  Why should I be allowed to
invalidate pagecache useful to others so quickly?

Shouldn't it merely, say, move the pages in its range to the inactive
list, giving other processes a chance to reassert an interest in them?
May not turn out as easy as that, I admit.

I'm fine with your idea of dropping mmap_sem while nopage waits on I/O,
I'm fine with your idea of an mm mmap transaction count, so nopage can
just reget mmap_sem without backing out when nothing changed meanwhile.

But I do think Ben should have the simple NOPAGE_RETRY he proposed,
going right back out to userspace; and that should be enough for your
case too (the mmap transaction count would make its use a rarity).

> So I think there's a nasty DoS here if we permit infinite retries.  But
> it's not just that - there might be other situations under really heavy
> memory pressure where livelocks like this can occur.

filemap_nopage would want to mark_page_accessed() before returning
NOPAGE_RETRY, but if that's not good enough to hold the page in cache
before the retried fault grabs it, your memory pressure is already
into thrashing.  I believe the livelock is peculiar to FADV_DONTNEED.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/