From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2400BC05027 for ; Wed, 1 Feb 2023 12:24:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DmrFk0QWBW3dh+SYcXByxUHL30TlqDUmz1DfKUMD+x8=; b=E8Aup7Yt1QClaQ TFhGoaag/pSXfz5X+m0O70RbVoIOTyZzMyFpmC+Ol4acAM5qWUt0L8Fk5CKrIPDW2+jfFlpcxpIlm 57PAtmjeLjEwTqYD659N8NsmSN9FMX4xGuqxKwkV2297+P8uJwQQHfj5xZXQ7m1GlB3SEKxh6X7Sj EPCLGkAvU7/f0nUDx5Ovmaud6eDfiZGgk2m/EWBMk/P1QC6C7ene+RA4R4NM/exNm5uVKl+Sk+qxC ge+c/p4lfSt0IYCcvPBRMRWQt3VodDLAJXFzLnXIJKDLOVHrrNyInIeqAQuI1/g/mJFMu2DR7frhr st6J0cYYelRjC/9KUjGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNC9H-00Bhdk-Py; Wed, 01 Feb 2023 12:23:35 +0000 Received: from mail-pf1-x429.google.com ([2607:f8b0:4864:20::429]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNC9E-00Bhci-0h for linux-arm-kernel@lists.infradead.org; Wed, 01 Feb 2023 12:23:33 +0000 Received: by mail-pf1-x429.google.com with SMTP id z3so12487339pfb.2 for ; Wed, 01 Feb 2023 04:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=JEkiUTacxMxuQViA2zFVDrCybVhWswU79PAFJJV/w9g=; b=JFlcwhut2YxmzOnINTmfWPgykYOoLnNzxL7qoNOpca+oiLZu8x5995wnOMAxVO+Ros XgubNWP6I84WorhX/iUfTp0ZDNOaxcuFDzmMCuFrPtBkuuwag9xqEI4RqxxPsooCQ0FQ 8ItpDZyF9Zv4u2C+Vf2/v7tnRbxkE0PXjCp8YbR7borkIjcoVXpNWrcJDiJDLyjgnV/h u+tsoufLduN4tVPPYx1Pb4csiCV27ywPKrB0bIF6biJifnwwzaBm16XfH7DpmZgLL3tX 3uDLvtanpupnMFpJac9gBh/h5/dmuW1WAMrZpBHcqEuzjxkX8xL9mH5HpZhHq2X6gAz4 07MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JEkiUTacxMxuQViA2zFVDrCybVhWswU79PAFJJV/w9g=; b=SM3YzpubovyUaWWmsFWd7Fq6gojEhhM7WNN+GHuVMIeR/Fn/+haz7EuN3SPkbkl2bU h/ZFsBALzornh/RFbChJXmuv9d4Pj/nF2AH5jeGe55eHibfNAr1cBaWp3NeBt0JgwJG1 9FiuZfq7vFYhOzENj/e6JNzaEuZrzwnujy8KiisTnC3/5E38SxX6JZCHdVZD4aLa9IO6 ifWmhiK6RepWbVIPd4RkRsNONOfOka2K15t6lGzVfX/j9B+rJpGPDCk3VQpF8D+ChPaA rPp7KDMx7UDmuFZGgfDLgOZX3S9LYbOVJNABo/fO9FV23m87Q1CCZs+BT7k2LyWJNPLc nlEg== X-Gm-Message-State: AO0yUKV7/NfCmwYwhIST1SgZq+FuHqnFREOdeocqj+K8lJYemfgLGWc4 ihPLPOzspbWlXS3Xaa1NuTk= X-Google-Smtp-Source: AK7set+GpUrYJx7Y0L584QZ8mHnSLMQmzHWvHob6Mlx6VGj4q3DTD2lRBF5v76Gk3l8+0GlLwkWQow== X-Received: by 2002:a05:6a00:1392:b0:593:91e4:99e2 with SMTP id t18-20020a056a00139200b0059391e499e2mr2628027pfg.34.1675254210775; Wed, 01 Feb 2023 04:23:30 -0800 (PST) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id y40-20020a056a001ca800b0058dbb5c5038sm243351pfw.182.2023.02.01.04.23.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Feb 2023 04:23:29 -0800 (PST) Date: Wed, 1 Feb 2023 21:23:16 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, rppt@kernel.org, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com, Sebastian Reichel Subject: Re: [PATCH v4 4/7] mm: replace vma->vm_flags direct modifications with modifier calls Message-ID: References: <20230126193752.297968-1-surenb@google.com> <20230126193752.297968-5-surenb@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230201_042332_080033_C069E036 X-CRM114-Status: GOOD ( 33.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 31, 2023 at 10:54:22AM -0800, Suren Baghdasaryan wrote: > On Tue, Jan 31, 2023 at 12:32 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: > > > > On Thu, Jan 26, 2023 at 11:37:49AM -0800, Suren Baghdasaryan wrote: > > > Replace direct modifications to vma->vm_flags with calls to modifier > > > functions to be able to track flag changes and to keep vma locking > > > correctness. > > > > > > Signed-off-by: Suren Baghdasaryan > > > Acked-by: Michal Hocko > > > Acked-by: Mel Gorman > > > Acked-by: Mike Rapoport (IBM) > > > Acked-by: Sebastian Reichel > > > --- > > > arch/arm/kernel/process.c | 2 +- > > > 120 files changed, 188 insertions(+), 199 deletions(-) > > > > > > > Hello Suren, > > Hi Hyeonggon, > > > > > [...] > > > > Whoa, it's so long. > > Mostly looks fine but two things I'm not sure about: > > > > > diff --git a/drivers/misc/open-dice.c b/drivers/misc/open-dice.c > > > index 9dda47b3fd70..7be4e6c9f120 100644 > > > --- a/drivers/misc/open-dice.c > > > +++ b/drivers/misc/open-dice.c > > > @@ -95,12 +95,12 @@ static int open_dice_mmap(struct file *filp, struct vm_area_struct *vma) > > > if (vma->vm_flags & VM_WRITE) > > > return -EPERM; > > > /* Ensure userspace cannot acquire VM_WRITE later. */ > > > - vma->vm_flags &= ~VM_MAYWRITE; > > > + vm_flags_clear(vma, VM_MAYSHARE); > > > } > > > > I think it should be: > > s/VM_MAYSHARE/VM_MAYWRITE/ > > Good eye! Yes, this is definitely a bug. Will post a next version with this fix. > > > > > > diff --git a/mm/mlock.c b/mm/mlock.c > > > index 5c4fff93cd6b..ed49459e343e 100644 > > > --- a/mm/mlock.c > > > +++ b/mm/mlock.c > > > @@ -380,7 +380,7 @@ static void mlock_vma_pages_range(struct vm_area_struct *vma, > > > */ > > > if (newflags & VM_LOCKED) > > > newflags |= VM_IO; > > > - WRITE_ONCE(vma->vm_flags, newflags); > > > + vm_flags_reset(vma, newflags); > > > > > > lru_add_drain(); > > > walk_page_range(vma->vm_mm, start, end, &mlock_walk_ops, NULL); > > > @@ -388,7 +388,7 @@ static void mlock_vma_pages_range(struct vm_area_struct *vma, > > > > > > if (newflags & VM_IO) { > > > newflags &= ~VM_IO; > > > - WRITE_ONCE(vma->vm_flags, newflags); > > > + vm_flags_reset(vma, newflags); > > > } > > > } > > > > wondering the if the comment above is still true? > > > > /* > > * There is a slight chance that concurrent page migration, > > * or page reclaim finding a page of this now-VM_LOCKED vma, > > * will call mlock_vma_folio() and raise page's mlock_count: > > * double counting, leaving the page unevictable indefinitely. > > * Communicate this danger to mlock_vma_folio() with VM_IO, > > * which is a VM_SPECIAL flag not allowed on VM_LOCKED vmas. > > * mmap_lock is held in write mode here, so this weird > > * combination should not be visible to other mmap_lock users; > > * but WRITE_ONCE so rmap walkers must see VM_IO if VM_LOCKED. > > */ > > > > does ACCESS_PRIVATE() still guarentee that compiler cannot mysteriously > > optimize writes like WRITE_ONCE()? > > I don't see ACCESS_PRIVATE() providing the same guarantees as > WRITE_ONCE(), therefore I think this also needs to be changed. I'll > need to introduce something like vm_flags_reset_once() and use it > here. vm_flags_reset_once() would do WRITE_ONCE() and otherwise would > be identical to vm_flags_reset(). > > I'll post a new version with the fixes later today. > > Thanks for the review! > Suren. Thanks for quick reply! Andrew's fix and the new patch looks good to me. with these two things addressed: Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Regards, Hyeonggon _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel