Re: [PATCH] Fix get_unmapped_area and fsync for hugetlb shm segments

[Bill Irwin]

Bill Irwin <bill.irwin@xxxxxxxxxx> 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@xxxxxxxxxx> 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
-
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/