From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756666AbbJ2Dvd (ORCPT ); Wed, 28 Oct 2015 23:51:33 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:53477 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751220AbbJ2Dva (ORCPT ); Wed, 28 Oct 2015 23:51:30 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Dan Cashman Cc: Jeffrey Vander Stoep , linux-kernel@vger.kernel.org, linux@arm.linux.org.uk, Andrew Morton , Kees Cook , mingo@kernel.org, linux-arm-kernel@lists.infradead.org, Jonathan Corbet , dzickus@redhat.com, xypron.glpk@gmx.de, jpoimboe@redhat.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, aarcange@redhat.com, Mel Gorman , tglx@linutronix.de, rientjes@google.com, linux-mm@kvack.org, linux-doc@vger.kernel.org, Mark Salyzyn , Nick Kralevich , dcashman References: <1446067520-31806-1-git-send-email-dcashman@android.com> <871tcewoso.fsf@x220.int.ebiederm.org> Date: Wed, 28 Oct 2015 22:41:35 -0500 In-Reply-To: (Dan Cashman's message of "Wed, 28 Oct 2015 17:39:49 -0700") Message-ID: <87oafiuys0.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1/X9nhoo/h+UiWq/L6DkKbXVwiAsrW6KUA= X-SA-Exim-Connect-IP: 67.3.201.231 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4997] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Dan Cashman X-Spam-Relay-Country: X-Spam-Timing: total 305 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 4.6 (1.5%), b_tie_ro: 3.2 (1.1%), parse: 1.25 (0.4%), extract_message_metadata: 18 (5.8%), get_uri_detail_list: 1.98 (0.6%), tests_pri_-1000: 6 (2.1%), tests_pri_-950: 1.40 (0.5%), tests_pri_-900: 1.29 (0.4%), tests_pri_-400: 25 (8.0%), check_bayes: 23 (7.6%), b_tokenize: 7 (2.3%), b_tok_get_all: 7 (2.4%), b_comp_prob: 2.5 (0.8%), b_tok_touch_all: 3.4 (1.1%), b_finish: 0.86 (0.3%), tests_pri_0: 238 (77.9%), tests_pri_500: 6 (2.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR. X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dan Cashman writes: >> > 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 > > Yes. I included these patches together because they provide mutual > context, but each has a different outcome and they could be taken > separately. They can not. The first patch is incomplete by itself. > The arm architecture-specific portion allows the changing > of the number of bits used for mmap ASLR, useful even without the > sysctl. The sysctl patch (patch 1) provides another way of setting > this value, and the hope is that this will be adopted across multiple > architectures, with the arm changes (patch 2) providing an example. I > hope to follow this with changes to arm64 and x86, for example. If you want to make the code generic. Please maximize the sharing. That is please define the variables in a generic location, as well as the Kconfig variables (if possible). As it is you have an architecture specific piece of code that can not be reused without duplicating code, and that is just begging for problems. Eric