[lkml]   [2011]   [Oct]   [17]   [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 Fri, Oct 14, 2011 at 01:59:48PM -0700, Andrew Morton wrote:
> 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

Which usual techniques did you have in mind?

> 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.

Well, that might have something to be said for it, the distinction has
always been tenuous at best.

> 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.

Hrm, as opposed to leaving the crash bug there until someone has time
to do the requested cleanup.

David Gibson | I'll have my music baroque, and my code
david AT | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!

 \ /
  Last update: 2011-10-17 07:17    [W:0.083 / U:6.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site