From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK Date: Fri, 18 Aug 2017 11:15:45 -0700 Message-ID: <20170818111545.ab371cfedb71d13d76590030@linux-foundation.org> References: <20170811212829.29186-1-riel@redhat.com> <20170811212829.29186-3-riel@redhat.com> <20170815155114.ff9f4164eed28bf02db48fbb@linux-foundation.org> <1502849899.6577.66.camel@redhat.com> <20170817155033.172cf22ec143713d5cf98b4e@linux-foundation.org> <1503073709.6577.68.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1503073709.6577.68.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rik van Riel Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, mike.kravetz-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, colm-ZXBCfW2eEe/k1uMJSBkQmQ@public.gmane.org, keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org, wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org, dave.hansen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org List-Id: linux-api@vger.kernel.org On Fri, 18 Aug 2017 12:28:29 -0400 Rik van Riel wrote: > On Thu, 2017-08-17 at 15:50 -0700, Andrew Morton wrote: > > On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel > > wrote: > > > > > > > --- a/mm/madvise.c > > > > > +++ b/mm/madvise.c > > > > > @@ -80,6 +80,17 @@ static long madvise_behavior(struct > > > > > vm_area_struct *vma, > > > > > __ } > > > > > __ new_flags &= ~VM_DONTCOPY; > > > > > __ break; > > > > > + case MADV_WIPEONFORK: > > > > > + /* MADV_WIPEONFORK is only supported on > > > > > anonymous > > > > > memory. */ > > > > > + if (vma->vm_file || vma->vm_flags & VM_SHARED) > > > > > { > > > > > + error = -EINVAL; > > > > > + goto out; > > > > > + } > > > > > + new_flags |= VM_WIPEONFORK; > > > > > + break; > > > > > + case MADV_KEEPONFORK: > > > > > + new_flags &= ~VM_WIPEONFORK; > > > > > + break; > > > > > __ case MADV_DONTDUMP: > > > > > __ new_flags |= VM_DONTDUMP; > > > > > __ break; > > > > > > > > It seems odd to permit MADV_KEEPONFORK against other-than-anon > > > > vmas? > > > > > > Given that the only way to set VM_WIPEONFORK is through > > > MADV_WIPEONFORK, calling MADV_KEEPONFORK on an > > > other-than-anon vma would be equivalent to a noop. > > > > > > If new_flags == vma->vm_flags, madvise_behavior() will > > > immediately exit. > > > > Yes, but calling MADV_WIPEONFORK against an other-than-anon vma is > > presumably a userspace bug.____A bug which will probably result in > > userspace having WIPEONFORK memory which it didn't want.____The kernel > > can trivially tell userspace that it has this bug so why not do so? > > Uh, what? > Braino. I meant MADV_KEEPONFORK. Calling MADV_KEEPONFORK against an other-than-anon vma is a presumptive userspace bug and the kernel should report that. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f199.google.com (mail-wr0-f199.google.com [209.85.128.199]) by kanga.kvack.org (Postfix) with ESMTP id 9BF716B0495 for ; Fri, 18 Aug 2017 14:15:50 -0400 (EDT) Received: by mail-wr0-f199.google.com with SMTP id r79so3422921wrb.0 for ; Fri, 18 Aug 2017 11:15:50 -0700 (PDT) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org. [140.211.169.12]) by mx.google.com with ESMTPS id k195si1673587wmd.158.2017.08.18.11.15.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 11:15:49 -0700 (PDT) Date: Fri, 18 Aug 2017 11:15:45 -0700 From: Andrew Morton Subject: Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK Message-Id: <20170818111545.ab371cfedb71d13d76590030@linux-foundation.org> In-Reply-To: <1503073709.6577.68.camel@redhat.com> References: <20170811212829.29186-1-riel@redhat.com> <20170811212829.29186-3-riel@redhat.com> <20170815155114.ff9f4164eed28bf02db48fbb@linux-foundation.org> <1502849899.6577.66.camel@redhat.com> <20170817155033.172cf22ec143713d5cf98b4e@linux-foundation.org> <1503073709.6577.68.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Rik van Riel Cc: linux-kernel@vger.kernel.org, mhocko@kernel.org, mike.kravetz@oracle.com, linux-mm@kvack.org, fweimer@redhat.com, colm@allcosts.net, keescook@chromium.org, luto@amacapital.net, wad@chromium.org, mingo@kernel.org, kirill@shutemov.name, dave.hansen@intel.com, linux-api@vger.kernel.org, torvalds@linux-foundation.org, willy@infradead.org On Fri, 18 Aug 2017 12:28:29 -0400 Rik van Riel wrote: > On Thu, 2017-08-17 at 15:50 -0700, Andrew Morton wrote: > > On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel > > wrote: > > > > > > > --- a/mm/madvise.c > > > > > +++ b/mm/madvise.c > > > > > @@ -80,6 +80,17 @@ static long madvise_behavior(struct > > > > > vm_area_struct *vma, > > > > > __ } > > > > > __ new_flags &= ~VM_DONTCOPY; > > > > > __ break; > > > > > + case MADV_WIPEONFORK: > > > > > + /* MADV_WIPEONFORK is only supported on > > > > > anonymous > > > > > memory. */ > > > > > + if (vma->vm_file || vma->vm_flags & VM_SHARED) > > > > > { > > > > > + error = -EINVAL; > > > > > + goto out; > > > > > + } > > > > > + new_flags |= VM_WIPEONFORK; > > > > > + break; > > > > > + case MADV_KEEPONFORK: > > > > > + new_flags &= ~VM_WIPEONFORK; > > > > > + break; > > > > > __ case MADV_DONTDUMP: > > > > > __ new_flags |= VM_DONTDUMP; > > > > > __ break; > > > > > > > > It seems odd to permit MADV_KEEPONFORK against other-than-anon > > > > vmas? > > > > > > Given that the only way to set VM_WIPEONFORK is through > > > MADV_WIPEONFORK, calling MADV_KEEPONFORK on an > > > other-than-anon vma would be equivalent to a noop. > > > > > > If new_flags == vma->vm_flags, madvise_behavior() will > > > immediately exit. > > > > Yes, but calling MADV_WIPEONFORK against an other-than-anon vma is > > presumably a userspace bug.____A bug which will probably result in > > userspace having WIPEONFORK memory which it didn't want.____The kernel > > can trivially tell userspace that it has this bug so why not do so? > > Uh, what? > Braino. I meant MADV_KEEPONFORK. Calling MADV_KEEPONFORK against an other-than-anon vma is a presumptive userspace bug and the kernel should report that. -- 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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751861AbdHRSPt (ORCPT ); Fri, 18 Aug 2017 14:15:49 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:33952 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751126AbdHRSPs (ORCPT ); Fri, 18 Aug 2017 14:15:48 -0400 Date: Fri, 18 Aug 2017 11:15:45 -0700 From: Andrew Morton To: Rik van Riel Cc: linux-kernel@vger.kernel.org, mhocko@kernel.org, mike.kravetz@oracle.com, linux-mm@kvack.org, fweimer@redhat.com, colm@allcosts.net, keescook@chromium.org, luto@amacapital.net, wad@chromium.org, mingo@kernel.org, kirill@shutemov.name, dave.hansen@intel.com, linux-api@vger.kernel.org, torvalds@linux-foundation.org, willy@infradead.org Subject: Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK Message-Id: <20170818111545.ab371cfedb71d13d76590030@linux-foundation.org> In-Reply-To: <1503073709.6577.68.camel@redhat.com> References: <20170811212829.29186-1-riel@redhat.com> <20170811212829.29186-3-riel@redhat.com> <20170815155114.ff9f4164eed28bf02db48fbb@linux-foundation.org> <1502849899.6577.66.camel@redhat.com> <20170817155033.172cf22ec143713d5cf98b4e@linux-foundation.org> <1503073709.6577.68.camel@redhat.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Aug 2017 12:28:29 -0400 Rik van Riel wrote: > On Thu, 2017-08-17 at 15:50 -0700, Andrew Morton wrote: > > On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel > > wrote: > > > > > > > --- a/mm/madvise.c > > > > > +++ b/mm/madvise.c > > > > > @@ -80,6 +80,17 @@ static long madvise_behavior(struct > > > > > vm_area_struct *vma, > > > > > __ } > > > > > __ new_flags &= ~VM_DONTCOPY; > > > > > __ break; > > > > > + case MADV_WIPEONFORK: > > > > > + /* MADV_WIPEONFORK is only supported on > > > > > anonymous > > > > > memory. */ > > > > > + if (vma->vm_file || vma->vm_flags & VM_SHARED) > > > > > { > > > > > + error = -EINVAL; > > > > > + goto out; > > > > > + } > > > > > + new_flags |= VM_WIPEONFORK; > > > > > + break; > > > > > + case MADV_KEEPONFORK: > > > > > + new_flags &= ~VM_WIPEONFORK; > > > > > + break; > > > > > __ case MADV_DONTDUMP: > > > > > __ new_flags |= VM_DONTDUMP; > > > > > __ break; > > > > > > > > It seems odd to permit MADV_KEEPONFORK against other-than-anon > > > > vmas? > > > > > > Given that the only way to set VM_WIPEONFORK is through > > > MADV_WIPEONFORK, calling MADV_KEEPONFORK on an > > > other-than-anon vma would be equivalent to a noop. > > > > > > If new_flags == vma->vm_flags, madvise_behavior() will > > > immediately exit. > > > > Yes, but calling MADV_WIPEONFORK against an other-than-anon vma is > > presumably a userspace bug.____A bug which will probably result in > > userspace having WIPEONFORK memory which it didn't want.____The kernel > > can trivially tell userspace that it has this bug so why not do so? > > Uh, what? > Braino. I meant MADV_KEEPONFORK. Calling MADV_KEEPONFORK against an other-than-anon vma is a presumptive userspace bug and the kernel should report that.