[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABXk95DOSKv70p+=DQvHck5LCvRDc0WDORpoobSStWhrcrCiyg@mail.gmail.com>
Date: Wed, 28 Oct 2015 17:01:37 -0700
From: Jeffrey Vander Stoep <jeffv@...gle.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Daniel Cashman <dcashman@...roid.com>,
linux-kernel@...r.kernel.org, linux@....linux.org.uk,
Andrew Morton <akpm@...ux-foundation.org>,
keescook@...omium.org, mingo@...nel.org,
linux-arm-kernel@...ts.infradead.org, corbet@....net,
dzickus@...hat.com, xypron.glpk@....de, jpoimboe@...hat.com,
kirill.shutemov@...ux.intel.com, n-horiguchi@...jp.nec.com,
aarcange@...hat.com, mgorman@...e.de, tglx@...utronix.de,
rientjes@...gle.com, linux-mm@...ck.org, linux-doc@...r.kernel.org,
salyzyn@...roid.com, Nick Kralevich <nnk@...gle.com>,
dcashman <dcashman@...gle.com>
Subject: Re: [PATCH 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR.
plain text this time...
> This all would be much cleaner if the arm architecture code were just to
> register the sysctl itself.
>
> As it sits this looks like a patchset that does not meaninfully bisect,
> and would result in code that is hard to trace and understand.
I believe the intent is to follow up with more architecture specific
patches to allow each architecture to define the number of bits to use
(min, max, and default) since these values are architecture dependent.
Arm64 patch should be forthcoming, and others after that. With that in
mind, would you still prefer to have the sysctl code in the
arm-specific patch?
--
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/
Powered by blists - more mailing lists