Re: [PATCH v2 1/1] hugepages: Fix race between hugetlbfs umount andquota update.

[Andrew Morton]

On Wed, 12 Oct 2011 15:43:17 +1100
Paul Mackerras <paulus@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/