[lkml]   [2011]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 1/1] hugepages: Fix race between hugetlbfs umount and quota update.
On Wed, 12 Oct 2011 15:43:17 +1100
Paul Mackerras <> 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.

 \ /
  Last update: 2011-10-14 23:01    [W:0.057 / U:1.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site