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.