linux-kernel - Re: [RFC v2 PATCH 0/7] thp: transparent hugepages on s390

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, 5 Sep 2012 00:40:27 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Gerald Schaefer <gerald.schaefer@...ibm.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Hugh Dickins <hughd@...gle.com>,
	Hillf Danton <dhillf@...il.com>, linux-kernel@...r.kernel.org,
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [RFC v2 PATCH 0/7] thp: transparent hugepages on s390

Hi Andrew and Martin,

On Fri, Aug 31, 2012 at 12:47:02PM -0700, Andrew Morton wrote:
> On Fri, 31 Aug 2012 09:07:57 +0200
> Martin Schwidefsky <schwidefsky@...ibm.com> wrote:
> 
> > > I grabbed them all.  Patches 1-3 look sane to me and I cheerfully
> > > didn't read the s390 changes at all.  Hopefully Andrea will be able to
> > > review at least patches 1-3 for us.
> > > 
> > > If that all goes well, how do we play this?  I'd prefer to merge 1-3
> > > myself, as they do interact with ongoing MM development.  I can also
> > > merge 4-7 if appropriate s390 maintainer acks are seen.  Or I can drop
> > > them and the s390 parts can be merged via the s390 tree at a later
> > > date?
> > 
> > I would really appreciate if Andrea could have a look at the code.
> 
> Yes please ;)

:) Sorry for the delay! I was at the Plumbers until last Friday and
I'm catching up with the emails.

I finished reviewing them and they look perfectly fine. In fact it was
a pleasure to read them. Patch 1 and 2 are noops in x86 context, patch
3 is fine as well.

The s390 solution to send a dummy IPIs to wait gup-fast to exit the
critical section after setting the splitting bit looks fine as well.

The only additional code cleanup suggestion I can give is to also add
a HAVE_ARCH_TRANSPARENT_HUGEPAGE on the same lines of:

http://git.kernel.org/?p=linux/kernel/git/andrea/aa.git;a=commitdiff;h=36c2d096cce61fcfc1726ea1c1fd6dd65ddf8b08;hp=b2a86603629e2401d85f9ed1acbcf6c0043b2b23

as patch 8. In order to convert the below:

+       depends on (X86 || (S390 && 64BIT)) && MMU

to:

       depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE

The MMU check looks already superflous, even more so after adding the
HAVE_ARCH_TRANSPARENT_HUGEPAGE (if something it'll be up to the arch
code to add a dependency on it before defining HAVE_ARCH_).

Thanks,
Andrea
--
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/