From: Andrew Morton <akpm@linux-foundation.org>
To: Paul Mackerras <paulus@samba.org>
Cc: Andrew Barry <abarry@cray.com>, linux-mm <linux-mm@kvack.org>,
Rik van Riel <riel@redhat.com>,
Minchan Kim <minchan.kim@gmail.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mel Gorman <mgorman@suse.de>,
David Gibson <david@gibson.dropbear.id.au>,
Hugh Dickins <hughd@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Hastings <abh@cray.com>
Subject: Re: [PATCH v2 1/1] hugepages: Fix race between hugetlbfs umount and quota update.
Date: Fri, 14 Oct 2011 13:59:48 -0700 [thread overview]
Message-ID: <20111014135948.a45a8ac1.akpm@linux-foundation.org> (raw)
In-Reply-To: <20111012044317.GA31436@drongo>
On Wed, 12 Oct 2011 15:43:17 +1100
Paul Mackerras <paulus@samba.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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-10-14 20:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 19:14 [PATCH v2 1/1] hugepages: Fix race between hugetlbfs umount and quota update Andrew Barry
2011-08-19 21:51 ` Andrew Morton
2011-08-22 20:07 ` Andrew Barry
2011-08-23 4:10 ` David Gibson
2011-09-01 5:28 ` David Gibson
2011-10-12 4:43 ` Paul Mackerras
2011-10-14 20:59 ` Andrew Morton [this message]
2011-10-17 5:14 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111014135948.a45a8ac1.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=abarry@cray.com \
--cc=abh@cray.com \
--cc=david@gibson.dropbear.id.au \
--cc=hughd@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan.kim@gmail.com \
--cc=paulus@samba.org \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).