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 66DC0C4345F for ; Mon, 22 Apr 2024 19:47:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC1436B008A; Mon, 22 Apr 2024 15:47:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D715A6B008C; Mon, 22 Apr 2024 15:47:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5FCF6B0092; Mon, 22 Apr 2024 15:47:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A89866B008A for ; Mon, 22 Apr 2024 15:47:24 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3AB3F160AF2 for ; Mon, 22 Apr 2024 19:47:24 +0000 (UTC) X-FDA: 82038202008.24.EC223F9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 6DBD3140021 for ; Mon, 22 Apr 2024 19:47:21 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Akxs0LOb; dmarc=none; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713815241; 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=76gu8eUjnppxduDLoTKr4Q+dTol5uZXEnc2IOhBfsLI=; b=YhpNGIFKfWMX1xV1x72KLLqudZiYKYNtTC90zAF5TpM4YybwKwD2RySF5BAV+y5Q8dweNK EvuSTh3f4+9lPP/2lFJYI/8i90oFYLfjBzJRMbere5G0HnIctkNf5quh6CizTyPU1Rbsz+ zmdxrhQX3l0W4EaA71v2ll6nzu0ciKg= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Akxs0LOb; dmarc=none; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713815241; a=rsa-sha256; cv=none; b=1y46Rf9kQ5fAISvuHvx/OdoO/e+7FYWTbkXXiEutkpLvCUYAwzIYxLwDvlv2IrcRmvivyp 6cLGAwsep6E/qmqA1m7I2MZUEJQ9AOQc1r03UqRsg5T6joG2m/9FdtbAfXRC24RctXDCgB AeSUixn9IVAM0bREVwVBEE2l7qRSC8Y= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 46CFE60ED6; Mon, 22 Apr 2024 19:47:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6DE1C113CC; Mon, 22 Apr 2024 19:47:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1713815239; bh=qTTNSuUYZaV5HVhMNgNjy/ynO2wqp8xqpRZXrz8vE5Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Akxs0LObreD8YPZWiUNU5y8ADrgheTp/brMABs0nGXP/9sHrBZFzfi2XvfiPMz2ww 7NAukUIItD1cv4JiM2iJkD/t/QzFl0vMR/i7KL7kDMRd3I1C8goNvhOH5wV2bBt4f1 3vEUt7Iu8LtGgxI9B5eiOYWqzENYkg8/mxKAAckU= Date: Mon, 22 Apr 2024 12:47:19 -0700 From: Andrew Morton To: Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Nadav Amit , David Hildenbrand , syzbot+d8426b591c36b21c750e@syzkaller.appspotmail.com Subject: Re: [PATCH] mm/userfaultfd: Reset ptes when close() for wr-protected ones Message-Id: <20240422124719.5097e42a736403d306ba7cf0@linux-foundation.org> In-Reply-To: <20240422133311.2987675-1-peterx@redhat.com> References: <20240422133311.2987675-1-peterx@redhat.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6DBD3140021 X-Rspam-User: X-Stat-Signature: kmmaqh38n5ac8hq3nrdbmgn6rwmoaa5o X-HE-Tag: 1713815241-326716 X-HE-Meta: U2FsdGVkX18VS+kyHjY6zvJ288U9CSuc9w38t/gGm8+CRMWSxdJ2LsC87B5UgYc6a0kio/lidiNNhXMytYfHgJIy92M3vu8QP3rrKypoidKZWm9yea6VT6mnE3sgswTvjbhzfhdaQUjC5dMr6x/7kjr8TdbzL1R6uU4MUQ6TnojhDLnyq/n/THfiK3MesGd6O73n1yfzTk49cRqnAGJRNm8P29nqgrjp1HgY/+9UN+WC75fmNckBRzX7zl3urOJcQx+9xl6rRnnHgDycpB0Vwslmze0SxGHKvuLKa1V2PQ3LhsfnnjiZjRY+juAPr0rHLuFmryfXStn8q38slRX6Cx2nOgEf5rarz6b4nmzgggbm8tnBHmjnvgk13HS6wPVFe1H2fxL1DQRyFp+Vhre3v1pXID9DEkoa77BjpEKgay7TJawONo56HnVk9UlhsmK06xVtgQuxFTD4UIQ/hWX0C+EnpfdD3yllNA2uqlz3jCiyhlghYM/+fFb39cz329OFDqkRNPqP9BrPcm3UwJjUrjeEIDqoDMMIhFpuuaOORbdUdXq7jykvm9jr1tAEI3fyvZpT1dNG1k0NEugT8dUBAElZ7S+GYe6kpc6/FASCAoBjNl7m21FW07B0rI70qPpU+4HKlmyEW0pgj4+gsTMCgX8L9KujSZTGv07YQ+bfyqz5mhSvn0O885mbuwWrSi9F8AVIaTxidsz0fBp6xhGl1kEqPtam7zFCGPVL86tqL1LVzkkDZ4BX/w77D1h+v6wjBlv8VB9BqBr8LYE8V/dQ23TmvOLGLB0VX5PYHR4kbB015Q7VoOG9flsYBqlhZfgSHrTcTRJtXIBSWuTLnqiqWrd9Puj42RWE2riasHnRmqpeHdX/5ACGlKF0NStThOguKX1kygPlgnmCiBhRnBurKyWIZxV3g8pH01BRpjwYOcY3/E90SdJjWftQVcIHrsJzk1I6B33EmkmJyaIW9gJ ujwC/6df nZzQwvROOxdo+K+LVqDNY36od1FLRsOvrjJZ26zAD4bloRdbIrIPlW5cpx2OeQo+5YJ578VnQ2Uwk1zn7pmWczm+FjDveBbPaZBO0OQd6ktvGQWc5yuRmyMjLJdF9bfnLDXAkHcniPUXnX8p8DwvvrXNfG0MJBXkO1P/UDPgzfgo+OPR9Bn4L4enpxtf4w65K8yuOMXn2UaOIIBiHyJEi9k9j95kFYXNgbO4AOdSE69eGLGtgw2KHyNzXlWa+K5Pj1Cs9WIqidb+3BUK6j3pYk2Ok7tpubCNVMBzFQSwCbhF3C1HaGsekScJDOP114WvMHI271Gpp8Z0EJtANUWs/fLWpWeKh5VP7wWIk 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: List-Subscribe: List-Unsubscribe: On Mon, 22 Apr 2024 09:33:11 -0400 Peter Xu wrote: > Userfaultfd unregister includes a step to remove wr-protect bits from all > the relevant pgtable entries, but that only covered an explicit > UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover > that too. We should include a description of the userspace-visible effects of the bug, please. Always. I see it triggers a WARN, but so what - why ca't we simply delete the WARN statement if that's the only effect? Presumably there are other consequences - what are they? Also, a WARN-triggering bug should be fixed in -stable kernels so we'll need a FIXES:, please?