All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khalid Aziz <khalid.aziz@oracle.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: linux-next: Tree for Nov 7
Date: Mon, 13 Nov 2017 16:35:22 +0000	[thread overview]
Message-ID: <c52fa249-9583-18a2-cbac-28abfb23d5a5@oracle.com> (raw)
In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz>

On 11/13/2017 09:06 AM, Michal Hocko wrote:
> OK, so this one should take care of the backward compatibility while
> still not touching the arch code
> ---
> commit 39ff9bf8597e79a032da0954aea1f0d77d137765
> Author: Michal Hocko <mhocko@suse.com>
> Date:   Mon Nov 13 17:06:24 2017 +0100
> 
>      mm: introduce MAP_FIXED_SAFE
>      
>      MAP_FIXED is used quite often but it is inherently dangerous because it
>      unmaps an existing mapping covered by the requested range. While this
>      might be might be really desidered behavior in many cases there are
>      others which would rather see a failure than a silent memory corruption.
>      Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
>      It is a MAP_FIXED extension with a single exception that it fails with
>      ENOMEM if the requested address is already covered by an existing
>      mapping. We still do rely on get_unmaped_area to handle all the arch
>      specific MAP_FIXED treatment and check for a conflicting vma after it
>      returns.
>      
>      Signed-off-by: Michal Hocko <mhocko@suse.com>
> 
> ...... deleted .......
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 680506faceae..aad8d37f0205 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>   	if (mm->map_count > sysctl_max_map_count)
>   		return -ENOMEM;
>   
> +	/* force arch specific MAP_FIXED handling in get_unmapped_area */
> +	if (flags & MAP_FIXED_SAFE)
> +		flags |= MAP_FIXED;
> +
>   	/* Obtain the address to map to. we verify (or select) it and ensure
>   	 * that it represents a valid section of the address space.
>   	 */

Do you need to move this code above:

         if (!(flags & MAP_FIXED))
                 addr = round_hint_to_min(addr);

         /* Careful about overflows.. */
         len = PAGE_ALIGN(len);
         if (!len)
                 return -ENOMEM;

Not doing that might mean the hint address will end up being rounded for 
MAP_FIXED_SAFE which would change the behavior from MAP_FIXED.

--
Khalid

WARNING: multiple messages have this Message-ID (diff)
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Michal Hocko <mhocko@kernel.org>, Michael Ellerman <mpe@ellerman.id.au>
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: Mon, 13 Nov 2017 09:35:22 -0700	[thread overview]
Message-ID: <c52fa249-9583-18a2-cbac-28abfb23d5a5@oracle.com> (raw)
In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz>

On 11/13/2017 09:06 AM, Michal Hocko wrote:
> OK, so this one should take care of the backward compatibility while
> still not touching the arch code
> ---
> commit 39ff9bf8597e79a032da0954aea1f0d77d137765
> Author: Michal Hocko <mhocko@suse.com>
> Date:   Mon Nov 13 17:06:24 2017 +0100
> 
>      mm: introduce MAP_FIXED_SAFE
>      
>      MAP_FIXED is used quite often but it is inherently dangerous because it
>      unmaps an existing mapping covered by the requested range. While this
>      might be might be really desidered behavior in many cases there are
>      others which would rather see a failure than a silent memory corruption.
>      Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
>      It is a MAP_FIXED extension with a single exception that it fails with
>      ENOMEM if the requested address is already covered by an existing
>      mapping. We still do rely on get_unmaped_area to handle all the arch
>      specific MAP_FIXED treatment and check for a conflicting vma after it
>      returns.
>      
>      Signed-off-by: Michal Hocko <mhocko@suse.com>
> 
> ...... deleted .......
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 680506faceae..aad8d37f0205 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>   	if (mm->map_count > sysctl_max_map_count)
>   		return -ENOMEM;
>   
> +	/* force arch specific MAP_FIXED handling in get_unmapped_area */
> +	if (flags & MAP_FIXED_SAFE)
> +		flags |= MAP_FIXED;
> +
>   	/* Obtain the address to map to. we verify (or select) it and ensure
>   	 * that it represents a valid section of the address space.
>   	 */

Do you need to move this code above:

         if (!(flags & MAP_FIXED))
                 addr = round_hint_to_min(addr);

         /* Careful about overflows.. */
         len = PAGE_ALIGN(len);
         if (!len)
                 return -ENOMEM;

Not doing that might mean the hint address will end up being rounded for 
MAP_FIXED_SAFE which would change the behavior from MAP_FIXED.

--
Khalid

WARNING: multiple messages have this Message-ID (diff)
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Michal Hocko <mhocko@kernel.org>, Michael Ellerman <mpe@ellerman.id.au>
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: Mon, 13 Nov 2017 09:35:22 -0700	[thread overview]
Message-ID: <c52fa249-9583-18a2-cbac-28abfb23d5a5@oracle.com> (raw)
In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz>

On 11/13/2017 09:06 AM, Michal Hocko wrote:
> OK, so this one should take care of the backward compatibility while
> still not touching the arch code
> ---
> commit 39ff9bf8597e79a032da0954aea1f0d77d137765
> Author: Michal Hocko <mhocko@suse.com>
> Date:   Mon Nov 13 17:06:24 2017 +0100
> 
>      mm: introduce MAP_FIXED_SAFE
>      
>      MAP_FIXED is used quite often but it is inherently dangerous because it
>      unmaps an existing mapping covered by the requested range. While this
>      might be might be really desidered behavior in many cases there are
>      others which would rather see a failure than a silent memory corruption.
>      Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
>      It is a MAP_FIXED extension with a single exception that it fails with
>      ENOMEM if the requested address is already covered by an existing
>      mapping. We still do rely on get_unmaped_area to handle all the arch
>      specific MAP_FIXED treatment and check for a conflicting vma after it
>      returns.
>      
>      Signed-off-by: Michal Hocko <mhocko@suse.com>
> 
> ...... deleted .......
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 680506faceae..aad8d37f0205 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>   	if (mm->map_count > sysctl_max_map_count)
>   		return -ENOMEM;
>   
> +	/* force arch specific MAP_FIXED handling in get_unmapped_area */
> +	if (flags & MAP_FIXED_SAFE)
> +		flags |= MAP_FIXED;
> +
>   	/* Obtain the address to map to. we verify (or select) it and ensure
>   	 * that it represents a valid section of the address space.
>   	 */

Do you need to move this code above:

         if (!(flags & MAP_FIXED))
                 addr = round_hint_to_min(addr);

         /* Careful about overflows.. */
         len = PAGE_ALIGN(len);
         if (!len)
                 return -ENOMEM;

Not doing that might mean the hint address will end up being rounded for 
MAP_FIXED_SAFE which would change the behavior from MAP_FIXED.

--
Khalid

WARNING: multiple messages have this Message-ID (diff)
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Michal Hocko <mhocko@kernel.org>, Michael Ellerman <mpe@ellerman.id.au>
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: Mon, 13 Nov 2017 09:35:22 -0700	[thread overview]
Message-ID: <c52fa249-9583-18a2-cbac-28abfb23d5a5@oracle.com> (raw)
In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz>

On 11/13/2017 09:06 AM, Michal Hocko wrote:
> OK, so this one should take care of the backward compatibility while
> still not touching the arch code
> ---
> commit 39ff9bf8597e79a032da0954aea1f0d77d137765
> Author: Michal Hocko <mhocko@suse.com>
> Date:   Mon Nov 13 17:06:24 2017 +0100
> 
>      mm: introduce MAP_FIXED_SAFE
>      
>      MAP_FIXED is used quite often but it is inherently dangerous because it
>      unmaps an existing mapping covered by the requested range. While this
>      might be might be really desidered behavior in many cases there are
>      others which would rather see a failure than a silent memory corruption.
>      Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
>      It is a MAP_FIXED extension with a single exception that it fails with
>      ENOMEM if the requested address is already covered by an existing
>      mapping. We still do rely on get_unmaped_area to handle all the arch
>      specific MAP_FIXED treatment and check for a conflicting vma after it
>      returns.
>      
>      Signed-off-by: Michal Hocko <mhocko@suse.com>
> 
> ...... deleted .......
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 680506faceae..aad8d37f0205 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>   	if (mm->map_count > sysctl_max_map_count)
>   		return -ENOMEM;
>   
> +	/* force arch specific MAP_FIXED handling in get_unmapped_area */
> +	if (flags & MAP_FIXED_SAFE)
> +		flags |= MAP_FIXED;
> +
>   	/* Obtain the address to map to. we verify (or select) it and ensure
>   	 * that it represents a valid section of the address space.
>   	 */

Do you need to move this code above:

         if (!(flags & MAP_FIXED))
                 addr = round_hint_to_min(addr);

         /* Careful about overflows.. */
         len = PAGE_ALIGN(len);
         if (!len)
                 return -ENOMEM;

Not doing that might mean the hint address will end up being rounded for 
MAP_FIXED_SAFE which would change the behavior from MAP_FIXED.

--
Khalid

WARNING: multiple messages have this Message-ID (diff)
From: khalid.aziz@oracle.com (Khalid Aziz)
To: linux-arm-kernel@lists.infradead.org
Subject: linux-next: Tree for Nov 7
Date: Mon, 13 Nov 2017 09:35:22 -0700	[thread overview]
Message-ID: <c52fa249-9583-18a2-cbac-28abfb23d5a5@oracle.com> (raw)
In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz>

On 11/13/2017 09:06 AM, Michal Hocko wrote:
> OK, so this one should take care of the backward compatibility while
> still not touching the arch code
> ---
> commit 39ff9bf8597e79a032da0954aea1f0d77d137765
> Author: Michal Hocko <mhocko@suse.com>
> Date:   Mon Nov 13 17:06:24 2017 +0100
> 
>      mm: introduce MAP_FIXED_SAFE
>      
>      MAP_FIXED is used quite often but it is inherently dangerous because it
>      unmaps an existing mapping covered by the requested range. While this
>      might be might be really desidered behavior in many cases there are
>      others which would rather see a failure than a silent memory corruption.
>      Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
>      It is a MAP_FIXED extension with a single exception that it fails with
>      ENOMEM if the requested address is already covered by an existing
>      mapping. We still do rely on get_unmaped_area to handle all the arch
>      specific MAP_FIXED treatment and check for a conflicting vma after it
>      returns.
>      
>      Signed-off-by: Michal Hocko <mhocko@suse.com>
> 
> ...... deleted .......
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 680506faceae..aad8d37f0205 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>   	if (mm->map_count > sysctl_max_map_count)
>   		return -ENOMEM;
>   
> +	/* force arch specific MAP_FIXED handling in get_unmapped_area */
> +	if (flags & MAP_FIXED_SAFE)
> +		flags |= MAP_FIXED;
> +
>   	/* Obtain the address to map to. we verify (or select) it and ensure
>   	 * that it represents a valid section of the address space.
>   	 */

Do you need to move this code above:

         if (!(flags & MAP_FIXED))
                 addr = round_hint_to_min(addr);

         /* Careful about overflows.. */
         len = PAGE_ALIGN(len);
         if (!len)
                 return -ENOMEM;

Not doing that might mean the hint address will end up being rounded for 
MAP_FIXED_SAFE which would change the behavior from MAP_FIXED.

--
Khalid

  reply	other threads:[~2017-11-13 16:35 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 [this message]
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
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=c52fa249-9583-18a2-cbac-28abfb23d5a5@oracle.com \
    --to=khalid.aziz@oracle.com \
    --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.