Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: mpe@ellerman.id.au (Michael Ellerman)
To: linux-arm-kernel@lists.infradead.org
Subject: linux-next: Tree for Nov 7
Date: Tue, 14 Nov 2017 19:54:59 +1100
Message-ID: <87h8txw87w.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20171113120057.555mvrs4fjq5tyng@dhcp22.suse.cz>

Michal Hocko <mhocko@kernel.org> writes:

> On Mon 13-11-17 22:34:50, Michael Ellerman wrote:
>> Hi Michal,
>> 
>> Michal Hocko <mhocko@kernel.org> writes:
>> > On Mon 13-11-17 10:20:06, Michal Hocko wrote:
>> >> [Cc arm and ppc maintainers]
>> >
>> > Hmm, it turned out to be a problem on other architectures as well.
>> > CCing more maintainers. For your reference, we are talking about
>> > http://lkml.kernel.org/r/20171023082608.6167-1-mhocko at kernel.org
>> > which has broken architectures which do apply aligning on the mmap
>> > address hint without MAP_FIXED applied. See below my proposed way
>> > around this issue because I belive that the above patch is quite
>> > valuable on its own to be dropped for all archs.
>> 
>> I don't really like your solution sorry :)  The fact that you've had to
>> patch seven arches seems like a red flag.
>> 
>> I think this is a generic problem with MAP_FIXED, which I've heard
>> userspace folks complain about in the past.
>
> The thing is that we canno  change MAP_FIXED behavior as it is carved in
> stone

Yes obviously. I didn't mean to imply we would change MAP_FIXED, rather
we would add a new flag with the new semantics.

>> Currently MAP_FIXED does two things:
>>   1. makes addr not a hint but the required address
>>   2. blasts any existing mapping
>> 
>> You want 1) but not 2).
>
> + fail if there is a clashing range

Yep. I thought that was implied :)

>> So the right solution IMHO would be to add a new mmap flag to request
>> that behaviour, ie. a fixed address but iff there is nothing already
>> mapped there.
>> 
>> I don't know the mm code well enough to know if that's hard for some
>> reason, but it *seems* like it should be doable.
>
> Yes, I have mentioned that in the previous email but the amount of code
> would be even larger. Basically every arch which reimplements
> arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> do vma lookup.

I'd have to look, but my memory of the arch code is that it doesn't deal
with the vma so it wouldn't need any change.

> So this was the most simple solution I could come up
> with. If there was a general interest for MAP_FIXED_SAFE then we can
> introduce it later of course. I would just like the hardening merged
> sooner rather than later.

Sure. But in the scheme of things one more kernel release is not that
big a deal to get it right. Given that the simple approach of dropping
MAP_FIXED turns out to not be simple at all.

cheers

  parent reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20171107162217.382cd754@canb.auug.org.au>
     [not found] ` <CACPK8Xfd4nqkf=Lk3n6+TNHAAi327r0dkUfGypZ3TpR0LqfS4Q@mail.gmail.com>
     [not found]   ` <20171108142050.7w3yliulxjeco3b7@dhcp22.suse.cz>
     [not found]     ` <20171110123054.5pnefm3mczsfv7bz@dhcp22.suse.cz>
     [not found]       ` <CACPK8Xe5uUKEytkRiszdX511b_cYTD-z3X=ZsMcNJ-NOYnXfuQ@mail.gmail.com>
2017-11-13  9:20         ` Michal Hocko
2017-11-13  9:34           ` Russell King - ARM Linux
2017-11-13  9:42           ` Michal Hocko
2017-11-13 11:34             ` Michael Ellerman
2017-11-13 12:00               ` Michal Hocko
2017-11-13 15:16                 ` Michal Hocko
2017-11-13 15:48                   ` Russell King - ARM Linux
2017-11-13 15:59                     ` Michal Hocko
2017-11-13 15:49                   ` Michal Hocko
2017-11-13 16:06                     ` Michal Hocko
2017-11-13 16:35                       ` Khalid Aziz
2017-11-14  7:07                         ` Michal Hocko
2017-11-14  9:18                       ` Michael Ellerman
2017-11-14  9:29                         ` Michal Hocko
2017-11-14  9:02                   ` Michael Ellerman
2017-11-14  8:54                 ` Michael Ellerman [this message]
2017-11-14  9:04                   ` Michal Hocko
2017-11-14 14:52                     ` Khalid Aziz
2017-11-13 14:11           ` Michal Hocko
2017-11-13 15:09             ` Russell King - ARM Linux
2017-11-13 15:31               ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h8txw87w.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git