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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 Mar 2007 15:40:48 -0800
From:	Bill Irwin <bill.irwin@...cle.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Bill Irwin <bill.irwin@...cle.com>, Adam Litke <agl@...ibm.com>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] Fix get_unmapped_area and fsync for hugetlb shm segments

Bill Irwin <bill.irwin@...cle.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@...cle.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/