From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755406AbdK2PTw (ORCPT ); Wed, 29 Nov 2017 10:19:52 -0500 Received: from mail02.prevas.se ([62.95.78.10]:29256 "EHLO mail02.prevas.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbdK2PTu (ORCPT ); Wed, 29 Nov 2017 10:19:50 -0500 X-IronPort-AV: E=Sophos;i="5.44,473,1505772000"; d="scan'208";a="2743695" Subject: Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE To: Michal Hocko , CC: Khalid Aziz , Michael Ellerman , Andrew Morton , Russell King - ARM Linux , Andrea Arcangeli , , LKML , , Florian Weimer , John Hubbard , Abdul Haleem , Joel Stanley , Kees Cook , Michal Hocko References: <20171129144219.22867-1-mhocko@kernel.org> From: Rasmus Villemoes Message-ID: Date: Wed, 29 Nov 2017 16:13:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20171129144219.22867-1-mhocko@kernel.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.8.31] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-11-29 15:42, Michal Hocko wrote: > > The first patch introduced MAP_FIXED_SAFE which enforces the given > address but unlike MAP_FIXED it fails with ENOMEM if the given range > conflicts with an existing one. [s/ENOMEM/EEXIST/, as it seems you also did in the actual patch and changelog] >The flag is introduced as a completely > new one rather than a MAP_FIXED extension because of the backward > compatibility. We really want a never-clobber semantic even on older > kernels which do not recognize the flag. Unfortunately mmap sucks wrt. > flags evaluation because we do not EINVAL on unknown flags. On those > kernels we would simply use the traditional hint based semantic so the > caller can still get a different address (which sucks) but at least not > silently corrupt an existing mapping. I do not see a good way around > that. I think it would be nice if this rationale was in the 1/2 changelog, along with the hint about what userspace that wants to be compatible with old kernels will have to do (namely, check that it got what it requested) - which I see you did put in the man page. -- Rasmus Villemoes Software Developer Prevas A/S Hedeager 3 DK-8200 Aarhus N +45 51210274 rasmus.villemoes@prevas.dk www.prevas.dk From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Villemoes Subject: Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE Date: Wed, 29 Nov 2017 16:13:53 +0100 Message-ID: References: <20171129144219.22867-1-mhocko@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171129144219.22867-1-mhocko@kernel.org> Content-Language: en-US Sender: owner-linux-mm@kvack.org To: Michal Hocko , linux-api@vger.kernel.org Cc: Khalid Aziz , Michael Ellerman , Andrew Morton , Russell King - ARM Linux , Andrea Arcangeli , linux-mm@kvack.org, LKML , linux-arch@vger.kernel.org, Florian Weimer , John Hubbard , Abdul Haleem , Joel Stanley , Kees Cook , Michal Hocko List-Id: linux-api@vger.kernel.org On 2017-11-29 15:42, Michal Hocko wrote: > > The first patch introduced MAP_FIXED_SAFE which enforces the given > address but unlike MAP_FIXED it fails with ENOMEM if the given range > conflicts with an existing one. [s/ENOMEM/EEXIST/, as it seems you also did in the actual patch and changelog] >The flag is introduced as a completely > new one rather than a MAP_FIXED extension because of the backward > compatibility. We really want a never-clobber semantic even on older > kernels which do not recognize the flag. Unfortunately mmap sucks wrt. > flags evaluation because we do not EINVAL on unknown flags. On those > kernels we would simply use the traditional hint based semantic so the > caller can still get a different address (which sucks) but at least not > silently corrupt an existing mapping. I do not see a good way around > that. I think it would be nice if this rationale was in the 1/2 changelog, along with the hint about what userspace that wants to be compatible with old kernels will have to do (namely, check that it got what it requested) - which I see you did put in the man page. -- Rasmus Villemoes Software Developer Prevas A/S Hedeager 3 DK-8200 Aarhus N +45 51210274 rasmus.villemoes@prevas.dk www.prevas.dk -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.prevas.se ([62.95.78.10]:29256 "EHLO mail02.prevas.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbdK2PTu (ORCPT ); Wed, 29 Nov 2017 10:19:50 -0500 Subject: Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE References: <20171129144219.22867-1-mhocko@kernel.org> From: Rasmus Villemoes Message-ID: Date: Wed, 29 Nov 2017 16:13:53 +0100 MIME-Version: 1.0 In-Reply-To: <20171129144219.22867-1-mhocko@kernel.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Michal Hocko , linux-api@vger.kernel.org Cc: Khalid Aziz , Michael Ellerman , Andrew Morton , Russell King - ARM Linux , Andrea Arcangeli , linux-mm@kvack.org, LKML , linux-arch@vger.kernel.org, Florian Weimer , John Hubbard , Abdul Haleem , Joel Stanley , Kees Cook , Michal Hocko Message-ID: <20171129151353.ICKQm-FVtE_6ldUEwXG7Iia2F_TfSxw9ETfmauzIBiQ@z> On 2017-11-29 15:42, Michal Hocko wrote: > > The first patch introduced MAP_FIXED_SAFE which enforces the given > address but unlike MAP_FIXED it fails with ENOMEM if the given range > conflicts with an existing one. [s/ENOMEM/EEXIST/, as it seems you also did in the actual patch and changelog] >The flag is introduced as a completely > new one rather than a MAP_FIXED extension because of the backward > compatibility. We really want a never-clobber semantic even on older > kernels which do not recognize the flag. Unfortunately mmap sucks wrt. > flags evaluation because we do not EINVAL on unknown flags. On those > kernels we would simply use the traditional hint based semantic so the > caller can still get a different address (which sucks) but at least not > silently corrupt an existing mapping. I do not see a good way around > that. I think it would be nice if this rationale was in the 1/2 changelog, along with the hint about what userspace that wants to be compatible with old kernels will have to do (namely, check that it got what it requested) - which I see you did put in the man page. -- Rasmus Villemoes Software Developer Prevas A/S Hedeager 3 DK-8200 Aarhus N +45 51210274 rasmus.villemoes@prevas.dk www.prevas.dk