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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE992C6FA9D for ; Wed, 1 Mar 2023 17:54:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E41A36B0071; Wed, 1 Mar 2023 12:54:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF1CF6B0072; Wed, 1 Mar 2023 12:54:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE19A6B0073; Wed, 1 Mar 2023 12:54:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BE0D46B0071 for ; Wed, 1 Mar 2023 12:54:46 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 86F05C03EA for ; Wed, 1 Mar 2023 17:54:46 +0000 (UTC) X-FDA: 80521079772.02.01BADCA Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf07.hostedemail.com (Postfix) with ESMTP id CB8FC40005 for ; Wed, 1 Mar 2023 17:54:43 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=S7AKTOEG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677693283; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=AyLNyIT7ZjoMQJW2GlCLIqOaY5bHOAo2jgEq4LLuoAE=; b=wbaEduA4nlqZYLTrcLtK3FhdT/AZKcKySTegUdT/hO2UKV44fjPeVjSydlCHJWcF/kef0a rtxK06+C7/1jP3DlHUGpmPFC4ttKxITYds41lJCq7yg+oSWM1NQ73C1+RPayyk3hCzKRW/ SfA7IXb3K3H8SjhR5GAIIYl+O7nvkRY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=S7AKTOEG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677693283; a=rsa-sha256; cv=none; b=DCTUwJ/trN9Ef7B6XQG1zOfNX35lnbZo2Ab7+QFtVtEWoEKg6ItL3fpVvyQ5CduCdRZav8 3qxBhf14uDtr4nf5CajgPukNVZo4B8zOM3c7isS0zR6vQoG6VojYZ3bs2FFMJLSPbJqfJ7 lm5vJsT0BtZI+KuEcNc3QTxkW1Ugcog= Received: by mail-yb1-f178.google.com with SMTP id v13so1180887ybu.0 for ; Wed, 01 Mar 2023 09:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677693283; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AyLNyIT7ZjoMQJW2GlCLIqOaY5bHOAo2jgEq4LLuoAE=; b=S7AKTOEG8ccSlllU33sd2udJ7o3wQuqONCNYCoGBbSWh5tr0AaYnW++oJMe5vlk20+ uUbXs6bl24986BVLDkPr6wv98lmJPAPwLYXtTMwiwQiyoymLt4Z/YfFZ4skK7BbxuuMR F9CmS+EnZpmnXzBVvcQxPndeTx5qxU45adJREbgzRbmrtYpvdpXuOOeCVXwEBw2K/L/6 ojIF2UM1kZuXihEL6ZTrfZpjbraZlQbN8F0sf6LeSa4QSirWHDrmBK7Qfp5sCXW3VIyo 0exAISXBdjhEzA5pxBdbHkeZUas6B4H6F4XWu9FW3ZHAa2mrVJKAufXZq10iYoAC8rct ruDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677693283; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AyLNyIT7ZjoMQJW2GlCLIqOaY5bHOAo2jgEq4LLuoAE=; b=ENjGLCwmx4XFF8sO9nIMAIo3XPzant3ivIFIhOEtCvEmdb8eTG39/dn7nwYjmMDbDY lD7IfIBS8duG7mNj81j1YFj5ak3f16u7BT8PO39X9TrKZXWzCCJOkvG/6BCIbSgGbWvX 66S59mxVmXa0ueg0WlOSJfuOPnPW4G3Y7CcxJcaRTMkfD0AgWmW2L7P381Xvtl8r7UOH TJT2WdtpX6XoRUUTvpIrAVxl3feSqWc3FKmSziMC8IHzMttVgzGRxQxA4ocb2er072H8 rowvFBsWJDzY9NFTlIZt3IS/nDi6ktRUzNB0sbZdhKANZKfUH+bHjAA/yMoxoREK1/vd pw1A== X-Gm-Message-State: AO0yUKUJpFf/cfc4xI2aVTchuVDULwouyOA3x4DZVHTnwvKd0wHAGvUw 4DZ28EGd1vDokjIA3gvELVMFoXixBDurc7Lsy0hzWw== X-Google-Smtp-Source: AK7set/dSnHhKx7xfru8h/OIpFh9QWVOIPiJTQjnvPHex+KDJnAwAPgPl5xSjjDBF4ljOMfSbewKYsv73I29zPJNkVs= X-Received: by 2002:a05:6902:118c:b0:a06:538f:265f with SMTP id m12-20020a056902118c00b00a06538f265fmr14185596ybu.4.1677693282712; Wed, 01 Mar 2023 09:54:42 -0800 (PST) MIME-Version: 1.0 References: <20230301022720.1380780-1-surenb@google.com> <20230301141003.xh47kjle2lcezn55@revolver> In-Reply-To: <20230301141003.xh47kjle2lcezn55@revolver> From: Suren Baghdasaryan Date: Wed, 1 Mar 2023 09:54:31 -0800 Message-ID: Subject: Re: [PATCH 1/2] mm/mmap: remove unnecessary vp->vma check in vma_prepare To: "Liam R. Howlett" , Suren Baghdasaryan , akpm@linux-foundation.org, sfr@canb.auug.org.au, error27@gmail.com, willy@infradead.org, david@redhat.com, jgg@ziepe.ca, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, mathieu.desnoyers@efficios.com, pasha.tatashin@soleen.com, laurent.dufour@fr.ibm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel test robot Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: CB8FC40005 X-Stat-Signature: iqtj36sj3h3rouyuens5i8zi364cwhoa X-HE-Tag: 1677693283-982374 X-HE-Meta: U2FsdGVkX19In5WAuvPNPGVPm3pkf+CxW1/MCyXfyuH309PrNIiNE9y4mBQwb/GyW7eFTs1u86eO7JEOnKZghfJlauDDdTYh6jemo0QKLofFWJT8myy8pl6pZwrhn7Z8L5a9gnf6bJl04L1785SeLIDWhoVixdAAyY3zvh6rdK8e3hkKab/cYmvxs9TQ4yshmZbvbzcF2LBbJp5u3CAKSRtPXrQhH8II3Wb5ic4iBdgh+EF1n42RjzrMc6KRQmMJ4hr46Xj/BHSM2cIFr7nUWRAZsIMMHR1a/jfOHG/uH3tjZIrNEG8sfBs6Zas/WteOpkMPltninFawnMDRLCFVXhaxH5pCqe7XGmztaafJCFt9ruPiosDVEE3BIqZYhw3Q2r5OkZ6UDFVGH22dCGJQ26n/yto4yfElYJAY/H/wKeFz6ErknQbyJgb+5IpAH3U4a6eO5m9f906Vs04JVBwX32GuRrIN+/tjF7W0p6WYIT9Tb4Z3OAE38BFPf9UzLGmhfzhHmrzjqxVAvlkXEKfbnmy8c9uF9N+4iPyov/9oY9lv3eFOmpK5JwaZ88YGiBNnSfyPBjqbs8jttJ4yav+DaXXrpB7YD7QdJxkOvEIfuXHKFzb/UOhE22cPR7k6nob2sNl/QCcxXjTbAT+AGBrTV99riR5pIuRBsimTTtEiFJlcn1/YVUnvEvhx7NFOMw1bzh1gUPO3VYYeGCE6Oa4KOBZjlODLaf+RYaNrSoBKnD5ZgVuTjF8SphRHdaeFcrGmczcWekuuf/CCT+xo7ngjWJhKB5+8pA3haFl8y0R5bNJhcF6OlQ+eD3UGcBWXlgXyttXxXxTcKS4wg0g4+lzzvwndACx4jxRgLSJVMQ0RfXua2/wbbu5RmrijyweU6VV95WUDhg66DYNGXO2dMOA5ws5U6ZyqqBscHymXS7ZnzOyeq9XoTyUxXkuPvMrY9Jk4Lwd3pvGTWT/oDbAglGm Ypd1jUyV T4K2oEJ/2qgEjz8R1KlSJfeOIR1J1xpWm3RUUo02UFVq0vFQyKQ525Hj0FkdKbsb7/Z/r8ipHuhAEq7e/D4KPfsExp8XdHNw8ueiFLbXxoIIojsGGv61xAMSzg9wO/xUKYHe7rychqVmxKM1Fj4fvkeuEM60g53vOlRzYUZvqN+eP+JwdM/5N1b5cvJq+m1SjZg3BS+HKsEweurgX08jHpjslW8JyHYbzqhv/jf4FIEpGxreSQfixKKjOL1lORA5je+2+t633nx6B506X8/9nNQtOPF1XyVZU7jgTpE4VUd/cgNeGkgzCfnx8d/cd4X9ToklC+2xhQmM6dFemgnmjpilSzWd6YoH1U54d7X94ROxzPWH5PVocEB7kuVX3WW7vBoEIKISafOCztnwuHLIc6pBI35m38CEwVhSbqXMonZ+7+kxsiow0Sf7bnGMb8/9fgk7i X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 1, 2023 at 6:10=E2=80=AFAM Liam R. Howlett wrote: > > * Suren Baghdasaryan [230228 21:27]: > > vp->vma in vma_prepare() is always non-NULL, therefore checking it is > > not necessary. Remove the extra check. > > > > Fixes: e8f071350ea5 ("mm/mmap: write-lock VMAs in vma_prepare before mo= difying them") > > Reported-by: kernel test robot > > Reported-by: Dan Carpenter > > Link: https://lore.kernel.org/r/202302281802.J93Nma7q-lkp@intel.com/ > > Signed-off-by: Suren Baghdasaryan > > --- > > Fix cleanly apply over mm-unstable, SHA in "Fixes" is from that tree. > > > > mm/mmap.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 0cd3714c2182..0759d53b470c 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -505,8 +505,7 @@ static inline void init_vma_prep(struct vma_prepare= *vp, > > */ > > static inline void vma_prepare(struct vma_prepare *vp) > > { > > - if (vp->vma) > > - vma_start_write(vp->vma); > > + vma_start_write(vp->vma); > > Would a WARN_ON_ONCE() be worth it? Maybe not since it will be detected > rather quickly once we dereference it below, but it might make it more > clear as to what happened? WARN_ON_ONCE() seems like an overkill to me. It always follows after init_multi_vma_prep()/init_vma_prep() both of which set the VMA. Risk should be minimal here and as you said, misuse is easily discoverable. > > I'm happy either way. > > Reviewed-by: Liam R. Howlett > > > if (vp->adj_next) > > vma_start_write(vp->adj_next); > > /* vp->insert is always a newly created VMA, no need for locking = */ > > -- > > 2.39.2.722.g9855ee24e9-goog > >