From: Bill Irwin <bill.irwin@oracle.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Bill Irwin <bill.irwin@oracle.com>, Adam Litke <agl@us.ibm.com>,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org
Subject: Re: [PATCH] Fix get_unmapped_area and fsync for hugetlb shm segments
Date: Wed, 7 Mar 2007 15:40:48 -0800 [thread overview]
Message-ID: <20070307234048.GR18774@holomorphy.com> (raw)
In-Reply-To: <m1hcswbqru.fsf@ebiederm.dsl.xmission.com>
Bill Irwin <bill.irwin@oracle.com> writes:
>> A comment to prepare others for the impending doubletake might be nice.
>> Or maybe just open-coding the equality check for &hugetlbfs_file_operations
>> in is_file_shm_hugepages() if others find it as jarring as I. Please
>> extend my ack to any follow-up fiddling with that.
On Wed, Mar 07, 2007 at 04:03:17PM -0700, Eric W. Biederman wrote:
> You did notice we are testing a different struct file?
Yes.
Bill Irwin <bill.irwin@oracle.com> writes:
>> The patch addresses relatively straightforward issues and naturally at
>> that.
On Wed, Mar 07, 2007 at 04:03:17PM -0700, Eric W. Biederman wrote:
> The whole concept is recursive so I'm not certain being a recursive check
> is that bad but I understand the point.
Hence my characterization as natural. You did notice this was an ack?
On Wed, Mar 07, 2007 at 04:03:17PM -0700, Eric W. Biederman wrote:
> I think the right answer is most likely to add an extra file method or
> two so we can remove the need for is_file_hugepages.
> There are still 4 calls to is_file_hugepages in ipc/shm.c and
> 2 calls in mm/mmap.c not counting the one in is_file_shm_hugepages.
> The special cases make it difficult to properly wrap hugetlbfs files
> with another file, which is why we have the weird special case above.
It's not clear to me that the core can be insulated from hugetlb's
distinct pagecache and memory mapping granularities in a Linux-native
manner, but if you come up with something new or manage to get the
known methods past Linus, akpm, et al, more power to you.
I'm not entirely sure what you're up to, but I'm mostly here to sanction
others' design notions since my own are far too extreme, and, of course,
review and ack patches, take bugreports and write fixes (not that I've
managed to get to any of them first in a long while, if ever), and so on.
I say killing the is_whatever_hugepages() checks with whatever abstraction
is good, since I don't like them myself, provided it's sane. Go for it.
-- wli
next prev parent reply other threads:[~2007-03-07 23:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-01 23:46 [PATCH] Fix get_unmapped_area and fsync for hugetlb shm segments Adam Litke
2007-03-02 0:28 ` Bill Irwin
2007-03-07 23:03 ` Eric W. Biederman
2007-03-07 23:26 ` Adam Litke
2007-03-07 23:56 ` Bill Irwin
2007-03-07 23:40 ` Bill Irwin [this message]
2007-03-08 1:09 ` Eric W. Biederman
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=20070307234048.GR18774@holomorphy.com \
--to=bill.irwin@oracle.com \
--cc=agl@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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