From mboxrd@z Thu Jan 1 00:00:00 1970 From: Khalid Aziz Date: Mon, 13 Nov 2017 16:35:22 +0000 Subject: Re: linux-next: Tree for Nov 7 Message-Id: List-Id: References: <20171108142050.7w3yliulxjeco3b7@dhcp22.suse.cz> <20171110123054.5pnefm3mczsfv7bz@dhcp22.suse.cz> <20171113092006.cjw2njjukt6limvb@dhcp22.suse.cz> <20171113094203.aofz2e7kueitk55y@dhcp22.suse.cz> <87lgjawgx1.fsf@concordia.ellerman.id.au> <20171113120057.555mvrs4fjq5tyng@dhcp22.suse.cz> <20171113151641.yfqrecpcxllpn5mq@dhcp22.suse.cz> <20171113154939.6ui2fmpokpm7g4oj@dhcp22.suse.cz> <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org 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 > 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 > > ...... 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Khalid Aziz Subject: Re: linux-next: Tree for Nov 7 Date: Mon, 13 Nov 2017 09:35:22 -0700 Message-ID: References: <20171108142050.7w3yliulxjeco3b7@dhcp22.suse.cz> <20171110123054.5pnefm3mczsfv7bz@dhcp22.suse.cz> <20171113092006.cjw2njjukt6limvb@dhcp22.suse.cz> <20171113094203.aofz2e7kueitk55y@dhcp22.suse.cz> <87lgjawgx1.fsf@concordia.ellerman.id.au> <20171113120057.555mvrs4fjq5tyng@dhcp22.suse.cz> <20171113151641.yfqrecpcxllpn5mq@dhcp22.suse.cz> <20171113154939.6ui2fmpokpm7g4oj@dhcp22.suse.cz> <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Cc: Joel Stanley , Stephen Rothwell , Andrew Morton , Linux-Next Mailing List , Linux Kernel Mailing List , Russell King , Benjamin Herrenschmidt , Abdul Haleem , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Yoshinori Sato , Rich Felker , "David S. Miller" , Chris Zankel , Max Filippov , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org, To: Michal Hocko , Michael Ellerman Return-path: In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips List-subscribe: List-owner: List-post: List-archive: 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 > 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 > > ...... 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753829AbdKMQhk (ORCPT ); Mon, 13 Nov 2017 11:37:40 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:27902 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752421AbdKMQhi (ORCPT ); Mon, 13 Nov 2017 11:37:38 -0500 Subject: Re: linux-next: Tree for Nov 7 To: Michal Hocko , Michael Ellerman Cc: Joel Stanley , Stephen Rothwell , Andrew Morton , Linux-Next Mailing List , Linux Kernel Mailing List , Russell King , Benjamin Herrenschmidt , Abdul Haleem , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Yoshinori Sato , Rich Felker , "David S. Miller" , Chris Zankel , Max Filippov , 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 References: <20171108142050.7w3yliulxjeco3b7@dhcp22.suse.cz> <20171110123054.5pnefm3mczsfv7bz@dhcp22.suse.cz> <20171113092006.cjw2njjukt6limvb@dhcp22.suse.cz> <20171113094203.aofz2e7kueitk55y@dhcp22.suse.cz> <87lgjawgx1.fsf@concordia.ellerman.id.au> <20171113120057.555mvrs4fjq5tyng@dhcp22.suse.cz> <20171113151641.yfqrecpcxllpn5mq@dhcp22.suse.cz> <20171113154939.6ui2fmpokpm7g4oj@dhcp22.suse.cz> <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> From: Khalid Aziz Organization: Oracle Corp Message-ID: Date: Mon, 13 Nov 2017 09:35:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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 > > ...... 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Khalid Aziz Subject: Re: linux-next: Tree for Nov 7 Date: Mon, 13 Nov 2017 09:35:22 -0700 Message-ID: References: <20171108142050.7w3yliulxjeco3b7@dhcp22.suse.cz> <20171110123054.5pnefm3mczsfv7bz@dhcp22.suse.cz> <20171113092006.cjw2njjukt6limvb@dhcp22.suse.cz> <20171113094203.aofz2e7kueitk55y@dhcp22.suse.cz> <87lgjawgx1.fsf@concordia.ellerman.id.au> <20171113120057.555mvrs4fjq5tyng@dhcp22.suse.cz> <20171113151641.yfqrecpcxllpn5mq@dhcp22.suse.cz> <20171113154939.6ui2fmpokpm7g4oj@dhcp22.suse.cz> <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> Content-Language: en-US Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Michal Hocko , Michael Ellerman Cc: Joel Stanley , Stephen Rothwell , Andrew Morton , Linux-Next Mailing List , Linux Kernel Mailing List , Russell King , Benjamin Herrenschmidt , Abdul Haleem , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Yoshinori Sato , Rich Felker , "David S. Miller" , Chris Zankel , Max Filippov , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org List-Id: linux-next.vger.kernel.org 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 > 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 > > ...... 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: khalid.aziz@oracle.com (Khalid Aziz) Date: Mon, 13 Nov 2017 09:35:22 -0700 Subject: linux-next: Tree for Nov 7 In-Reply-To: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> References: <20171108142050.7w3yliulxjeco3b7@dhcp22.suse.cz> <20171110123054.5pnefm3mczsfv7bz@dhcp22.suse.cz> <20171113092006.cjw2njjukt6limvb@dhcp22.suse.cz> <20171113094203.aofz2e7kueitk55y@dhcp22.suse.cz> <87lgjawgx1.fsf@concordia.ellerman.id.au> <20171113120057.555mvrs4fjq5tyng@dhcp22.suse.cz> <20171113151641.yfqrecpcxllpn5mq@dhcp22.suse.cz> <20171113154939.6ui2fmpokpm7g4oj@dhcp22.suse.cz> <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > 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 > > ...... 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