All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: linux-next: Tree for Nov 7
Date: Tue, 14 Nov 2017 08:54:59 +0000	[thread overview]
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@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

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Michal Hocko <mhocko@kernel.org>
Cc: Joel Stanley <joel@jms.id.au>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Abdul Haleem <abdhalee@linux.vnet.ibm.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org,
Subject: Re: linux-next: Tree for Nov 7
Date: Tue, 14 Nov 2017 19:54:59 +1100	[thread overview]
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@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

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Michal Hocko <mhocko@kernel.org>
Cc: Joel Stanley <joel@jms.id.au>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Abdul Haleem <abdhalee@linux.vnet.ibm.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org,
	linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org
Subject: Re: linux-next: Tree for Nov 7
Date: Tue, 14 Nov 2017 19:54:59 +1100	[thread overview]
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@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

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Michal Hocko <mhocko@kernel.org>
Cc: Joel Stanley <joel@jms.id.au>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Abdul Haleem <abdhalee@linux.vnet.ibm.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org
Subject: Re: linux-next: Tree for Nov 7
Date: Tue, 14 Nov 2017 19:54:59 +1100	[thread overview]
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@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

WARNING: multiple messages have this Message-ID (diff)
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	[thread overview]
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	other threads:[~2017-11-14  8:54 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07  5:22 linux-next: Tree for Nov 7 Stephen Rothwell
2017-11-07 22:22 ` Joel Stanley
2017-11-08 14:20   ` Michal Hocko
2017-11-10 12:30     ` Michal Hocko
2017-11-12  1:08       ` Joel Stanley
2017-11-13  9:20         ` Michal Hocko
2017-11-13  9:20           ` Michal Hocko
2017-11-13  9:34           ` Russell King - ARM Linux
2017-11-13  9:34             ` Russell King - ARM Linux
2017-11-13  9:42           ` Michal Hocko
2017-11-13  9:42             ` Michal Hocko
2017-11-13  9:42             ` Michal Hocko
2017-11-13  9:42             ` Michal Hocko
2017-11-13 11:34             ` Michael Ellerman
2017-11-13 11:34               ` Michael Ellerman
2017-11-13 11:34               ` Michael Ellerman
2017-11-13 11:34               ` Michael Ellerman
2017-11-13 11:34               ` Michael Ellerman
2017-11-13 12:00               ` Michal Hocko
2017-11-13 12:00                 ` Michal Hocko
2017-11-13 12:00                 ` Michal Hocko
2017-11-13 12:00                 ` Michal Hocko
2017-11-13 12:00                 ` Michal Hocko
2017-11-13 15:16                 ` Michal Hocko
2017-11-13 15:16                   ` Michal Hocko
2017-11-13 15:16                   ` Michal Hocko
2017-11-13 15:16                   ` Michal Hocko
2017-11-13 15:16                   ` Michal Hocko
2017-11-13 15:48                   ` Russell King - ARM Linux
2017-11-13 15:48                     ` Russell King - ARM Linux
2017-11-13 15:48                     ` Russell King - ARM Linux
2017-11-13 15:48                     ` Russell King - ARM Linux
2017-11-13 15:48                     ` Russell King - ARM Linux
2017-11-13 15:59                     ` Michal Hocko
2017-11-13 15:59                       ` Michal Hocko
2017-11-13 15:59                       ` Michal Hocko
2017-11-13 15:59                       ` Michal Hocko
2017-11-13 15:59                       ` Michal Hocko
2017-11-13 15:49                   ` Michal Hocko
2017-11-13 15:49                     ` Michal Hocko
2017-11-13 15:49                     ` Michal Hocko
2017-11-13 15:49                     ` Michal Hocko
2017-11-13 15:49                     ` Michal Hocko
2017-11-13 16:06                     ` Michal Hocko
2017-11-13 16:06                       ` Michal Hocko
2017-11-13 16:06                       ` Michal Hocko
2017-11-13 16:06                       ` Michal Hocko
2017-11-13 16:06                       ` Michal Hocko
2017-11-13 16:35                       ` Khalid Aziz
2017-11-13 16:35                         ` Khalid Aziz
2017-11-13 16:35                         ` Khalid Aziz
2017-11-13 16:35                         ` Khalid Aziz
2017-11-13 16:35                         ` Khalid Aziz
2017-11-14  7:07                         ` Michal Hocko
2017-11-14  7:07                           ` Michal Hocko
2017-11-14  7:07                           ` Michal Hocko
2017-11-14  7:07                           ` Michal Hocko
2017-11-14  9:18                       ` Michael Ellerman
2017-11-14  9:18                         ` Michael Ellerman
2017-11-14  9:18                         ` Michael Ellerman
2017-11-14  9:18                         ` Michael Ellerman
2017-11-14  9:18                         ` Michael Ellerman
2017-11-14  9:29                         ` Michal Hocko
2017-11-14  9:29                           ` Michal Hocko
2017-11-14  9:29                           ` Michal Hocko
2017-11-14  9:29                           ` Michal Hocko
2017-11-14  9:29                           ` Michal Hocko
2017-11-14  9:02                   ` Michael Ellerman
2017-11-14  9:02                     ` Michael Ellerman
2017-11-14  9:02                     ` Michael Ellerman
2017-11-14  9:02                     ` Michael Ellerman
2017-11-14  9:02                     ` Michael Ellerman
2017-11-14  8:54                 ` Michael Ellerman [this message]
2017-11-14  8:54                   ` Michael Ellerman
2017-11-14  8:54                   ` Michael Ellerman
2017-11-14  8:54                   ` Michael Ellerman
2017-11-14  8:54                   ` Michael Ellerman
2017-11-14  9:04                   ` Michal Hocko
2017-11-14  9:04                     ` Michal Hocko
2017-11-14  9:04                     ` Michal Hocko
2017-11-14  9:04                     ` Michal Hocko
2017-11-14  9:04                     ` Michal Hocko
2017-11-14 14:52                     ` Khalid Aziz
2017-11-14 14:52                       ` Khalid Aziz
2017-11-14 14:52                       ` Khalid Aziz
2017-11-14 14:52                       ` Khalid Aziz
2017-11-13 14:11           ` Michal Hocko
2017-11-13 14:11             ` Michal Hocko
2017-11-13 15:09             ` Russell King - ARM Linux
2017-11-13 15:09               ` Russell King - ARM Linux
2017-11-13 15:31               ` Michal Hocko
2017-11-13 15:31                 ` Michal Hocko
2017-11-14  0:03         ` Andrew Morton
2017-11-14  0:36           ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2023-11-07  1:17 Stephen Rothwell
2022-11-07  3:44 Stephen Rothwell
2019-11-07  8:07 Stephen Rothwell
2018-11-07  3:16 Stephen Rothwell
2013-11-07  7:31 Stephen Rothwell
2013-11-07  7:31 ` Stephen Rothwell
2012-11-07  5:15 Stephen Rothwell
2012-11-07  5:15 ` Stephen Rothwell

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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.