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 0F1ABEB64D7 for ; Mon, 26 Jun 2023 20:51:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6CBA18D0002; Mon, 26 Jun 2023 16:51:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 67C488D0001; Mon, 26 Jun 2023 16:51:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56A4D8D0002; Mon, 26 Jun 2023 16:51:18 -0400 (EDT) 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 465278D0001 for ; Mon, 26 Jun 2023 16:51:18 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F2C77C084D for ; Mon, 26 Jun 2023 20:51:17 +0000 (UTC) X-FDA: 80946094194.21.21B3CE7 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf24.hostedemail.com (Postfix) with ESMTP id 17585180022 for ; Mon, 26 Jun 2023 20:51:15 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=XgQTFOT6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.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=1687812676; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=y2wVtYa2vqyVKl9o91me/mKW8BTuC3FGzPHOpu6HMUY=; b=C32Lg47SixLePWERNPP9UvmGHoIgkd4SWwSRei8O24zf/tJdCiy1zxjXEkeTOWtB4pKuve nyWY1ucvO9bvGejVVMxxaGz7aod1ClcqS2ostFrDlL3T0/7mtQDorY+SWi8NONZDkBEb6N MfeVuSvjXgoY2MoMWxxQCAWuvLGLlZ8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=XgQTFOT6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.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=1687812676; a=rsa-sha256; cv=none; b=UkPt3vzxxAxmYnCkcU2Et9XhO8N1mDQbSoNhOZ2tP8LNJrwvNIrfETYAzmRPfQ1XhBktA2 t0GfJgsm4x3SNIkt34tUz7K+ADFaYlw0EnUADKCki9i++W/8mRdKbVhXOHwHmwgAQGUsvr 0ld0Z2Is4vPnfg3bK+/58J2kXG9lcEw= Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-bdd069e96b5so3856786276.2 for ; Mon, 26 Jun 2023 13:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687812675; x=1690404675; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=y2wVtYa2vqyVKl9o91me/mKW8BTuC3FGzPHOpu6HMUY=; b=XgQTFOT6k9V779cjl2JLqY02nPwY/RTzphuzZ2hnOJvfWBTSEj6Kv8I/dTqSSyIr/d CbTITKUurWjQjbQpxt5ApsLtUvKk06XAgTDW/j95MHO+8yMbiTmBTHXoe+gIWorLodTs QudtoaCOKvUfKMYNGshN6JnrsyqqcAEg6lQGQ1bn+4IFXYOurknO+ZdsU/FgZrw420MF 8t7VZvr6jEYHYaSO/kwxGK9eyHxaM+rylmII2imP/2sCChe1/jrO5WnEZsFS7RUgfrSW 2hzkTV8YNXSXG9pBqzohG/S42rHjGh9/R9/BgkSgGypMimxZ+KU9SCjJxrKo0l84ZCoO O+uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687812675; x=1690404675; h=content-transfer-encoding:cc: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=y2wVtYa2vqyVKl9o91me/mKW8BTuC3FGzPHOpu6HMUY=; b=ice1UM6ZAmP9THnIbwodOmrNGkWpq7YIaGFt82cEG/x01mq+v6+a73a3cbmzZwwPAO piWkTgRiQjfuklT70dNTZuesWe81M7ZLHReOfDzuXXvfgA/FpK8qmxJSqGzv7loHsZEc qnv0IzIDznSeSqnM7bXD7vtmcy612O9srnEILUGW5Ke6qX2f3W1GA1L5wpsathhCDU3C fhWE+w7HqCabAOz5Un7vCS5RC8GUFbPVTrWc9giJIci3dz5nNl540RvVNH8AdPt39cms sxtQgQr0Jo7Cvd3fsEG6IZpHlN1rbIq28CBCtukvdUBKQ8U/D+KeQu/4IG/+oiSN+wRR FNqg== X-Gm-Message-State: AC+VfDwhnymJaXAtAudseBchlzQ0fekEwazToKYiV3n5Da293XrRrhZb gkNYdxDsAi6wNrtTNumvcjovHYVsxJAacZfzmYbpIQ== X-Google-Smtp-Source: ACHHUZ5jUc5atIflbAoCqP1iuoHBqp5gAGvVJwpi2/6J+5nRNsQlzCeC+4ypWGb7ME7TRoDDEUxDqm4Nd1II1cuOnFs= X-Received: by 2002:a25:f802:0:b0:ba8:6c1f:f5ad with SMTP id u2-20020a25f802000000b00ba86c1ff5admr25085848ybd.29.1687812675044; Mon, 26 Jun 2023 13:51:15 -0700 (PDT) MIME-Version: 1.0 References: <20230620235726.3873043-1-surenb@google.com> In-Reply-To: <20230620235726.3873043-1-surenb@google.com> From: Suren Baghdasaryan Date: Mon, 26 Jun 2023 20:51:04 +0000 Message-ID: Subject: Re: [PATCH 1/3] mm: change vma_start_read to fail if VMA got detached from under it To: akpm@linux-foundation.org Cc: willy@infradead.org, torvalds@linuxfoundation.org, vegard.nossum@oracle.com, mpe@ellerman.id.au, Liam.Howlett@oracle.com, lrh2000@pku.edu.cn, mgorman@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 17585180022 X-Stat-Signature: hn6w77b7wrjebff8of4cs31f43znfzdn X-HE-Tag: 1687812675-714541 X-HE-Meta: U2FsdGVkX1+oYYGiqpdHm2HqB/3IcXnKCDGYYP4gWSkM1sRMQRItrdGTzhH87cdFUcgoasRnHgsZps56gRlm0UFJ4UnaQAkBvuCCXvWALu7Uv0xpkxhXSvYVcyudoJjOpUySTOfL1x650TBuAo6kg3Z3Z3WDJcGGBObopysLRMTbrukCi2RhgEzRHW6Bp+KF+Vn9RQ7mlCN0luJA8T/Cm6KrVKQ+zUUoGSYkj/n959PYw90g31rXQr7oWgpGRWrKA7l+GNxnAvZYr3Eu3BHuqrskYjkkbCLCPBdYXLr/SnkLU9lUwul0Pmr83Eybxj1c/xo2RIB9MHxOYMcsOj1qmcIHW24eLrxeUVsoiAdHgZH0egMcdgnhnaeK0qXyE7jIBBVs6M1MShQB9Vq5CLpoLbzYjay0A11t4dHuZ2bhtNz16x3BwCuiARdy7hM+W2wIfny9bRO3dM1n+K/UddhyqYvwcEDruZfjCF6gUMKq5dA/cIdkF7XlB5vMj+oSJaRWEnyYLpxKarJeZSb+ft69S7Aq53yThkG1fsgdAnCb0i3L+Zh2INXQULCowD8rkG1cM4BlmPSIdbRTba9NBr/zavxZ43EdWv4CpABvwKT9Xsh7pb3hcqyvH3kCrGUUfOp2a0aD52BZrtAezBRJJtf3QCmQVshJ5620RAuuZLtqNhlPYnPWnc1iIwJ2luPukBknH9xTydWGLMxSJfQWJPxuVJVUnWZk2wdtyj9fQvbwMaH5sop1PK2ELOR7UoK/KGfLtQAPCo7ywKqtNnzkUlF6NkYvNGF2DGYWmLaCgN16Jic7h5hbHIrJjy9XkCJVgcy1UaG/u9WrWr0iPR0/HnoGP/JCEKLiOfnGn4b+0trIktvO3XxE+SjaWhVqEGdj5ZB0ZQSPz60dEYBhL11ToI7RLBGBw3MNraI+RgvI8CU5j7gTVfvH8iAVvJ4T/ne3F/C84nkIfNX9qQkUOplPX7O Kquz9EKg Txq2RFZzphMABMgl9VmoEFT5ISPltxFCNh+KnLlGRNeVRCHortOoy40WSqJ5ZxqErTREzRMacNGCf4CA/97+B4XDPYp6aY63A1u0mh+VUDCWa0yE2Bu4D4OMmWRfxspupOKuCyP/3bvkhU8U6pEYJ2PLRX/8k/5fr2LyGEmTi+6426Nk7I8PB13Xpc/rWediP/M10ociYBRyo8xvrAO+DQ+wFPdE1KB3Wqmk+FAjsnDff5ArP06iYoGwwiCLtZ5FXGGteoR9SRxsHQWf54ZFQMeU0K6ZjZbuFJK4aTaNp6Aoh8xXd8xOfyD8PK3EwBMIXSdetkT82udcRFn/J5nLXxaOJBOMEj2rXbRzp0IScxfNQSKU= 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 Tue, Jun 20, 2023 at 11:57=E2=80=AFPM Suren Baghdasaryan wrote: > > Current implementation of vma_start_read() checks VMA for being locked > before taking vma->vm_lock and then checks that again. This mechanism > fails to detect a case when the VMA gets write-locked, modified and > unlocked after the first check but before the vma->vm_lock is obtained. > While this is not strictly a problem (vma_start_read would not produce > a false unlocked result), this allows it to successfully lock a VMA which > got detached from the VMA tree while vma_start_read was locking it. > New condition checks for any change in vma->vm_lock_seq after we obtain > vma->vm_lock and will cause vma_start_read() to fail if the above race > occurs. Just a friendly ping for feedback. I know most people were busy fixing the stack expansion problem and these patches are not urgent, so no rush. If nobody reviews them, I'll ping again next week. > > Fixes: 5e31275cc997 ("mm: add per-VMA lock and helper functions to contro= l it") > Suggested-by: Matthew Wilcox > Signed-off-by: Suren Baghdasaryan > --- > include/linux/mm.h | 19 ++++++++++--------- > 1 file changed, 10 insertions(+), 9 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 27ce77080c79..8410da79c570 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -639,23 +639,24 @@ static inline void vma_numab_state_free(struct vm_a= rea_struct *vma) {} > */ > static inline bool vma_start_read(struct vm_area_struct *vma) > { > - /* Check before locking. A race might cause false locked result. = */ > - if (vma->vm_lock_seq =3D=3D READ_ONCE(vma->vm_mm->mm_lock_seq)) > + int vm_lock_seq =3D READ_ONCE(vma->vm_lock_seq); > + > + /* > + * Check if VMA is locked before taking vma->vm_lock. A race or > + * mm_lock_seq overflow might cause false locked result. > + */ > + if (vm_lock_seq =3D=3D READ_ONCE(vma->vm_mm->mm_lock_seq)) > return false; > > if (unlikely(down_read_trylock(&vma->vm_lock->lock) =3D=3D 0)) > return false; > > - /* > - * Overflow might produce false locked result. > - * False unlocked result is impossible because we modify and chec= k > - * vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock= _seq > - * modification invalidates all existing locks. > - */ > - if (unlikely(vma->vm_lock_seq =3D=3D READ_ONCE(vma->vm_mm->mm_loc= k_seq))) { > + /* Fail if VMA was write-locked after we checked it earlier */ > + if (unlikely(vm_lock_seq !=3D READ_ONCE(vma->vm_lock_seq))) { > up_read(&vma->vm_lock->lock); > return false; > } > + > return true; > } > > -- > 2.41.0.162.gfafddb0af9-goog >