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 E8B39C001DC for ; Thu, 27 Jul 2023 18:31:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DC8C6B0075; Thu, 27 Jul 2023 14:31:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4662D6B0078; Thu, 27 Jul 2023 14:31:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E22A6B007B; Thu, 27 Jul 2023 14:31:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1DD3C6B0075 for ; Thu, 27 Jul 2023 14:31:22 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E31C5C0628 for ; Thu, 27 Jul 2023 18:31:21 +0000 (UTC) X-FDA: 81058234362.05.D3D7445 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by imf24.hostedemail.com (Postfix) with ESMTP id A80AE18000B for ; Thu, 27 Jul 2023 18:31:17 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=klIm4XDl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 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=1690482677; 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=Cuix17oN1As2F9cKjO6qI0WP+i+QUzfFJXKaqWcIw5U=; b=Q4+O/cr2tugy0S5xYGSEUiD4wr9ko22m+KmQwiwPSL+GSHfAvANbNWzxgzSA1HMsM84Npc 0TrVnNd/EFcD8Q2JAm2TsXul1vXwDJCiF0BDoMIAa2uPjsE7Us2IeoWE8S8DqzOhiw7Ffs ZtQnUK/f+fgGp0A1Ih5+mQLYo0DrM7E= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=klIm4XDl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690482677; a=rsa-sha256; cv=none; b=P8bGvNc5ErxvDSJvH7WabJlN5bobZkEf5MnlQ2m9M587074BJosRLh38KaUPvrFsuH85yu jtFzvrDl6GV3IPZH9ota8KpN1HckIk4HnNLtOElBz/t+GQjX1RIHuBD3KtdWvJSvqalEml giMP1nxP/dgNyq9oVejRUfeblsBp97Q= Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-583a8596e2aso13936127b3.1 for ; Thu, 27 Jul 2023 11:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690482676; x=1691087476; 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=Cuix17oN1As2F9cKjO6qI0WP+i+QUzfFJXKaqWcIw5U=; b=klIm4XDlEQx1Pzosih1WqdpHLfAmSKX62qjoQHiHKdm+IY4QJq0VjANoi/XLz4fjTS qYGCP+29ONX0IMFjdxiE6hpggNps5K757mi54oKznztzhxPMVWygjTH9zbjBTpPsDiRQ x71n2g4qdwfGRgBlrtUs1lTdrAM2sIJAmTX/CN8W5X9dvFV/LIMKqd3wy2HaAz6U21hf LS6njBjCJtA8GZ9DC94dDKEeco3SkwpnrjvOvx13K6xwnbzzGFm7Cwhf1fR/2VqXl+DL jxczcuYm0SCWn+wEeM/lBti94iuLtqgMrPNXZoWGN0bN10ukCE8yFEOuyHd/omH4OeAx 1pyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690482676; x=1691087476; 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=Cuix17oN1As2F9cKjO6qI0WP+i+QUzfFJXKaqWcIw5U=; b=Bd6yd6c3qYNHjZV80zxCMTxZixSWhVO531bvrMG/i5DZ3Ix4WbrxoMkbgEhl4a0ZDg R7yXWyf9c8DcDo4uG7OZ/lY5n4NgAlKd4LF7AEOkaddlBvWKnlgNAGiOgMDCi33naeK8 ZGwbBCF+gikK5lNOQmf3+/m1J4ZwXOsTE3VcUDFltCs8zIqhCzHZDCGe7nAAkrumzc8j TPvFX0j7vNWlgdcGauL5aSrk7sDJ3lBbEBY8n4TPlSHPpNCwOegnEfBJ/cBN+IHh1RNv Xn5X/eTT5CEnVpt7YD/ZARqnJ4FrQQbH9KgxM28I7z9MyNiTWgI+RPTU3QECFJegwplG 4eEA== X-Gm-Message-State: ABy/qLasr79/hcCaWL6BOOVw5vLtrXVROBZ5zpvXoTKEJiUjVOReSI49 fCygnGEyxhgeoGorWT8US8zKMVUL1yjEU5Cp2nb2Xw== X-Google-Smtp-Source: APBJJlG1OjtjMH5KGWRrsqvdl4t6T4NYpi8HpLoGO/Tola0XsUYaeZ4dPZgLeAQjbKKyoE5a2e/EamCpo6Riyly9Lc8= X-Received: by 2002:a25:c508:0:b0:d00:cc5b:8a9f with SMTP id v8-20020a25c508000000b00d00cc5b8a9fmr221127ybe.16.1690482676162; Thu, 27 Jul 2023 11:31:16 -0700 (PDT) MIME-Version: 1.0 References: <000000000000607ff905ffc8e477@google.com> <0000000000000aeb7f06015e5cbd@google.com> <20230727164757.e2di75xjybxncohn@revolver> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 27 Jul 2023 11:31:01 -0700 Message-ID: Subject: Re: [syzbot] [mm?] WARNING: suspicious RCU usage in mas_walk (2) To: Matthew Wilcox Cc: Jann Horn , "Liam R. Howlett" , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, syzbot Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A80AE18000B X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: nkdfqbd7s8s5fsf8pwux8cmzg8aotxwd X-HE-Tag: 1690482677-133978 X-HE-Meta: U2FsdGVkX1+5VCk0+FXbDbCnPplAXwZVk6j68NfoD/RDXEE3q7RUA8YA1bHdtn5/5USbSHVOKT458pvg2Ftoql+cdNE6HpVgj2Y2OfVk6OS8Q0XSZbefailh13k1UGmJC/hLwbBa3e7wKC/tn/OCLInVOKEm3QetgtnWhCyVF9LYLJpoQ+m7al8Ec5eU7duJFcBfTKc3O3VCTPfhfEW02Y8PMPt5luJdR+XKjvIzboupOzIfGrWJs9dETiBMnwPxJfEicv5mpLApCzDO3jjAWbdVbbWv4w/ep50jJHTVu1KUuHpgVBS1zsU4ue3hJrgvBLxnmigKJQOHV4CS2bsXtTDkbco/IFg3Fgtr/2W8HhP4ULE315fa0R5+A3nJL7a2YFdBACFgKZLspF6UlAhNKgC4d7CETVFMJVL/+wSPfUM1CsXXGvQjAGYGrzIZ2dgaNJCBWpRP5loKnbms4l8j3AtsfFZxL0tM72Wqh/nRJWyhspWpZClKCZcB8OotX9bKKW2ed3xiN7puPRKzGymFOmmW5xrWErZ3LkP6KLrHvWEpN9HLwA8MKiNPhkmP6SMEaUpUthI+DWTbq4saEExrreC1WatcsCB9aPqRaxjHTZI8f5yhjsSPTtC9NkivVYEkkGRpiy0IT/bWVvOIE5n4XcoAt4DfZwGMqKXjC0tiM+DL0O3vOlK9P8l7u/POUyIfzO0rdQr14jV9Gl2aXPg4mIL51CsT9rGT07LBdiRktE8ZoHB8IR9gFngpWPyD8PFAA+JE63TZkCZ2QKrIa8eSORSby2TVZF2brAXQblHP0zgpaNhrVRaA42lV3+Ax/K1rJC3WX83YY0CG4CDraGJwS1ghn0Td/2Os5k5kHZdeHyMuqkWiDp/lVvn1UNXHPychKhy9ZiZ5C+4jZxW7jOkcNJZ4gQPeoyET6nWCAYoSnsEHuZmHzBwweugQz+3lZ0Cfe3UZnXOFxgn8ynoErZj RLU1Tf96 k+NZZIApOSl215uhxx+VkpIPNoWf2nBVxvg6rZScNJ8CJ82DAdv36uBvHeTajL3ocDNAJTms2FWu/0LPyUxIdu2qVola0NFZ6kuNzrr+kJPFXBkejesU2A63u7Eiz0CJU4PpRoGhrQeXGTdPisjWjc9eC2o6P6WCb/0a6nD047UKzDL4V64xwOU11VdPAzyMi4zlEUdlybHigiHuVOq37apD2EDGaAFA2f+9BCnZNFeyCcDkj4g2NvyeNFgwhQbQUPEOwR4rL47poBJJlnjauPyrRO7I5o4U2lq/6gjiuigjknYIpxI17OtybU1qQx+1WoZFlBKTulT39kHRUAtJ7+DkSvwN3uQuB241GobrM1Zlgt/hy0qE1OX9w4/FYNoPuIZ47TrmaJikDV+9xN44Slgvrtl1Iq07WGgYybS269lhf5JaNpKSpLalRJc2jE0svflx2frVaZT3hRkSvcTXj0dpK42W2qNU9geY+Xun9ZMhSK9QxlnZlNI5nR0krRGFL8sFPFzfYFkHJrc6wZEoGfbvj3kKZdFkrhRxNaUPt8Bkr5qc= 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 Thu, Jul 27, 2023 at 11:17=E2=80=AFAM Matthew Wilcox wrote: > > On Thu, Jul 27, 2023 at 07:59:33PM +0200, Jann Horn wrote: > > On Thu, Jul 27, 2023 at 7:22=E2=80=AFPM Suren Baghdasaryan wrote: > > > Hmm. lock_vma_under_rcu() specifically checks for vma->anon_vma=3D=3D= NULL > > > condition (see [1]) to avoid going into find_mergeable_anon_vma() (a > > > check inside anon_vma_prepare() should prevent that). So, it should > > > fall back to mmap_lock'ing. > > > > This syzkaller report applies to a tree with Willy's in-progress patch > > series, where lock_vma_under_rcu() only checks for vma->anon_vma if > > vma_is_anonymous() is true - it permits private non-anonymous VMAs > > (which require an anon_vma for handling write faults) even if they > > don't have an anon_vma. > > > > The commit bisected by syzkaller > > (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/co= mmit/?id=3Da52f58b34afe095ebc5823684eb264404dad6f7b) > > removes the vma_is_anonymous() check in handle_pte_fault(), so it lets > > us reach do_wp_page() with a non-anonymous private VMA without > > anon_vma, even though that requires allocation of an anon_vma. > > > > So I think this is pretty clearly an issue with Willy's in-progress > > patch series that syzkaller blamed correctly. A comment for __anon_vma_prepare() says "This must be called with the mmap_lock held for reading." I think adding an explicit mmap_assert_locked() in this function would help catch such issues. > > Agreed. What do we think the right solution is? > > Option 1: > > +++ b/mm/memory.c > @@ -3197,6 +3197,12 @@ static vm_fault_t wp_page_copy(struct vm_fault *vm= f) > struct mmu_notifier_range range; > int ret; > > + if (!vma->anon_vma) { > + // check if there are other things to undo here > + vma_end_read(vmf->vma); > + return VM_FAULT_RETRY; > + } > + This one bails out later but if the path is not taken too often I think it's cleaner. > delayacct_wpcopy_start(); > > Option 2: > > @@ -5581,7 +5587,8 @@ struct vm_area_struct *lock_vma_under_rcu(struct mm= _struct *mm, > goto inval; > > /* find_mergeable_anon_vma uses adjacent vmas which are not locke= d */ > - if (vma_is_anonymous(vma) && !vma->anon_vma) > + if ((vma_is_anonymous(vma) || > + vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) && !vma->anon_vma= ) > goto inval; > > The problem with option 2 is that we don't know whether this is a write > fault or not, so we'll handle read faults on private file > mappings under the mmap_lock UNTIL somebody writes to the mapping, which > might be never. That seems like a bad idea. > > We could pass FAULT_FLAG_WRITE into lock_vma_under_rcu(), but that also > seems like a bad idea. I dunno. Three bad ideas. Anyone think of a > good one?