Re: [PATCH 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR.

From: Daniel Cashman
Date: Tue Nov 03 2015 - 13:21:45 EST

On 11/01/2015 01:50 PM, Eric W. Biederman wrote:
> Daniel Cashman <dcashman@xxxxxxxxxxx> writes:
>> On 10/28/2015 08:41 PM, Eric W. Biederman wrote:
>>> Dan Cashman <dcashman@xxxxxxxxxxx> 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.
>> Could you be more specific in what makes the first patch incomplete? Is
>> it because it is essentially a no-op without additional architecture
>> changes (e.g. the second patch) or is it specifically because it
>> introduces and uses the three "mmap_rnd_bits*" variables without
>> defining them? If the former, I'd like to avoid combining the general
>> procfs change with any architecture-specific one(s). If the latter, I
>> hope the proposal below addresses that.
> A bit of both. The fact that the code can not compile in the first
> patch because of missing variables is distressing. Having the arch
> specific code as a separate patch is fine, but they need to remain in
> the same patchset.

The first patch would compile as long as CONFIG_ARCH_MMAP_RND_BITS were
not defined without also defining the missing variables. I actually
viewed this as a safeguard against attempting to use those variables
without architecture support, but am ok with changing it.

I've gone ahead and submitted [PATCH v2] which aims to reduce
duplication in the arch-specific config files and concerning those
variables. The only caveat is that now the second patch depends on the
first, whereas before it did not.

Thank You,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at