linux-kernel - Re: [PATCH v2 1/1] hugepages: Fix race between hugetlbfs umount and quota update.

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]

Message-Id: <20111014135948.a45a8ac1.akpm@linux-foundation.org>
Date:	Fri, 14 Oct 2011 13:59:48 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Andrew Barry <abarry@...y.com>, linux-mm <linux-mm@...ck.org>,
	Rik van Riel <riel@...hat.com>,
	Minchan Kim <minchan.kim@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mel Gorman <mgorman@...e.de>,
	David Gibson <david@...son.dropbear.id.au>,
	Hugh Dickins <hughd@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Hastings <abh@...y.com>
Subject: Re: [PATCH v2 1/1] hugepages: Fix race between hugetlbfs umount and
 quota update.

On Wed, 12 Oct 2011 15:43:17 +1100
Paul Mackerras <paulus@...ba.org> wrote:

> In the meantime we have a user-triggerable kernel crash.  As far as I
> can see, if we did what you suggest, we would end up with a situation
> where we could run out of huge pages even though everyone was within
> quota.  Which is arguably better than a kernel crash, but still less
> than ideal.  What do you suggest?

My issue with the patch is that it's rather horrible.  We have a layer
of separation between core hugetlb pages and hugetlbfs.  That layering
has already been mucked up in various places and this patch mucks it up
further, and quite severely.

So I believe we should rethink the patch.  Either a) get the layering
correct by not poking into hugetlbfs internals from within hugetlb core
via one of the usual techniques or b) make a deliberate decision to
just give up on that layering: state that hugetlb and hugetlbfs are now
part of the same subsystem.  Make the necessaary Kconfig changes,
remove ifdefs, move code around, etc.

If we go ahead with the proposed patch-n-run bugfix, the bad code will
be there permanently - nobody will go in and clean this mess up and the
kernel is permanently worsened.
--
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/