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 C60BCC001DC for ; Thu, 27 Jul 2023 18:46:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 605396B0074; Thu, 27 Jul 2023 14:46:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B4DD6B0075; Thu, 27 Jul 2023 14:46:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47DEB6B0078; Thu, 27 Jul 2023 14:46:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3A4796B0074 for ; Thu, 27 Jul 2023 14:46:49 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0AA701A05E6 for ; Thu, 27 Jul 2023 18:46:49 +0000 (UTC) X-FDA: 81058273338.28.B4C4F2F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id C70BB4001F for ; Thu, 27 Jul 2023 18:46:46 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="h1plePO/"; dmarc=none; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690483607; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=v+2d2fz9rEME7Y0Xsx/fiwIu2EBkpqU7AjglSy6mvgw=; b=jq7joNoOiTS7oRTEN78/OYapXQh0D9sPOyacmjP+rRip9df/9otS9WHOPgnHxD0a53aS0I irw2PH1pBmtoYhJSpuZrufuKKYwIFfX0JBcPlwUnV8KAPDG9ryy8RhPh45mAD+fbhBpDGR NLxBeczzWYjrLpCYiy/MdmzJjYGm7BU= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="h1plePO/"; dmarc=none; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690483607; a=rsa-sha256; cv=none; b=oeZnlB9+KVuN5BcCCi7BegAz6cGj9IWVS7aKshqsbPBYwaDDEr0I1edcXYwDptAtNYKGny dVuIncd1tVuArOnoOefo0HMsVpCgrSrFrcGrVtZC82L+jDYR1CXvc8++4JeN1RZEBYvtDF 0Fycf2aHRXHD/+GrvK3a1tlEutkC7SU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=v+2d2fz9rEME7Y0Xsx/fiwIu2EBkpqU7AjglSy6mvgw=; b=h1plePO/YXRkcTPAxTeQ9SuQ8p 5Ta7Znt8oEbDNYWorNcsi7Hhf4raQKG7hIo34yo7OfsM3+cnIF/A3djQ5LrFfE4lUpeIqXMWGYM7D P+eLz1Bo/zMZdRqZ30SavW5bxsJv9M1pvl7c2Ch/h5lamhNjQqeQTxSttmh7LrIGGmoWHjx3SOFBi 8rCk3YBDL1syjT5Ld5cL3aU9wA8O1Q/9kv7ZpxH2O5H5Mm5pIga82icpoXuB0+P/8lYhXi2am22J1 h8hycSzAwE8Ichk8xq4a5e44ObjKBYEKvfC0O4cON6OMNfws6+qIZioBQ4bJXsGIApvw0WJ9O2GXy g9LOXXVA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qP60V-007m3X-CS; Thu, 27 Jul 2023 18:46:39 +0000 Date: Thu, 27 Jul 2023 19:46:39 +0100 From: Matthew Wilcox To: Suren Baghdasaryan Cc: Jann Horn , "Liam R. Howlett" , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, syzbot Subject: Re: [syzbot] [mm?] WARNING: suspicious RCU usage in mas_walk (2) Message-ID: References: <000000000000607ff905ffc8e477@google.com> <0000000000000aeb7f06015e5cbd@google.com> <20230727164757.e2di75xjybxncohn@revolver> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: C70BB4001F X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: u4w19ht8jhp48ysh4p9dmfe5i55hstg6 X-HE-Tag: 1690483606-635023 X-HE-Meta: U2FsdGVkX19uLH0o+GfjIiSDQqd1//4vXdM+f3s22V5Y9iXxCA20C3q/URoHI3h1IRwJ8toQuuTQGNFdZ4GRmQ3KsveaGw+0kDyKE7wtJKWtosCgK5FNW+4n9cg65N69HR7tnoO+oBL6VZJTJ/yuKS9RZxWzaGMv8FN7rl7FXR/kh05ul8Q3LRYZ2Y7gIkiQ5LYnG2N6alpbHBj1O65SMLz5Y3y6Y3GneJ+c+++Z3khT1TWLBrmRUhjp1p2HrZg1eQhuKav0PV8EF8Zp+8H/vYL+NfG1wg2KgYPT4/gaay9gXTbLo47zRJsxW7tWst9D8/sM/q32iImT9gYCrCy09ENDjtl/ayPyV8XuEWBpJ4J1fkVo1sdVx6Jy5uakMXntBVy73fdiAxrfKt6zinsxEXhtQ00Z8l42JMgpbxUiKEUUSfvbevRkrSxwCSa6s9Ytd6+CmarNO40N8q7FxE3BAHKuga0QA2v/j2V5j0HOA7UG9RSmCSPbFq4zmRN3tWKEYAMyuIuqe4HWsbkhHptZ5K+ySDs4Cxz5W75ULYKL+Z5hwueRSz/w6l9HNX+ojtFqbcI2PDriMYJyrCdiD9PfGMzrIG4aAhaRMGKrdKSwgE/cgle95a1CK4yAcOWTg9Se+8Pf9MpSD7v8gPiTjnDdzd/nPoaOKLdGNW/KtYiJMLPDeN4LTS5VreY/WbC0wasB5pvhs4EqDh6Ir69f4w5PqpT+VV1EPSTYaiswVCT858EZTOk3QHfC5dTVR7fry1EppRBhEzTdMx0CkOe+rpfRNy3dWNX9894zYrX5QQ00SUd44N5hLg/EQqVHzyAEBVXFP9A6J+xUOPcQmMAhvX0cg0+Ea2y+1G9K+aVdxSNbOV5BB6Pclg/7IGGz0k6Amqx76TotHTK20BBnxQ0ZR3YVhmZjXWEtk5R+D17CDiSr3Q/4rmwTrZPV9JcTKycE251VupScilbeQenK7tSfSU3 6yaoT7DD SvALlZpgEyfVb1dutYkgdwNevnH/anvEKSFUBUyNQdj0Nrb3MOYDuovBCXFkHikBGe5xAK+VN2SoDyW7f9e+kT88G9xMz74SV0Kb4amN8eVLpjaV9NitffGhc/ae127i7w5IzFyEiJWKm+cZIlxriRpJm/kMVvkEgG0vU9vvdSb18+ECyX9tJ8vqCwrCWHO09YwKbH5mMiQe3SYxnIeL5G77jQH8n9lgqyGs9Bp9tZfeQlpY8+I001C4seOLPaLhSRNcQujRjybbh6h4vDREFFZtxdGOugZe+RlgkXyofgDRnYgszPOEUuddyc0m4BdNkZODye68+nQgJGi8= 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:31:01AM -0700, Suren Baghdasaryan wrote: > 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. Would it catch them faster than syzbot? > > +++ b/mm/memory.c > > @@ -3197,6 +3197,12 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf) > > 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. OK, then I think the right place to put this check is slightly before this function is called, to avoid bouncing the folio refcount: +++ b/mm/memory.c @@ -3567,6 +3567,12 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf) return 0; } copy: + if ((vmf->flags & FAULT_FLAG_VMA_LOCK) && !vma->anon_vma) { + pte_unmap_unlock(vmf->pte, vmf->ptl); + vma_end_read(vmf->vma); + return VM_FAULT_RETRY; + } + /* * Ok, we need to copy. Oh, well.. */ ... it compiles. Guess I should figure out the syntax to ask syzbot to test it.