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 80315ECE57A for ; Mon, 9 Sep 2024 14:55:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 036EF6B0185; Mon, 9 Sep 2024 10:55:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F29346B0186; Mon, 9 Sep 2024 10:55:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF0CD6B0187; Mon, 9 Sep 2024 10:55:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BFFE26B0185 for ; Mon, 9 Sep 2024 10:55:13 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6EBD4405A5 for ; Mon, 9 Sep 2024 14:55:13 +0000 (UTC) X-FDA: 82545497706.11.DCCCDAE Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf28.hostedemail.com (Postfix) with ESMTP id 734D5C001E for ; Mon, 9 Sep 2024 14:55:11 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=pHqKADI5; spf=none (imf28.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725893684; h=from:from:sender: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=mRmS78jNSEjRbW1RfkNVcIiFQs+BtHlpdjo+RIOliaY=; b=BdDLiOGa84qouLF4tWMQOjn6VXJajelmJbgNpy/ggZl4/acNyfoIdexqEvVfimFHqILKiH ZTFRKvRINbKq2vptjVyHKUlBblB9F+6cmbKPIhk50haTtqI79JvVQ0PMqerC2oOMIlLWGe pcXhnvI+il4CkulzbD2q6bonSd3Jn/Y= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=pHqKADI5; spf=none (imf28.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725893684; a=rsa-sha256; cv=none; b=CHXXJG4JGPUO866ythhQ1H36D5FapcR2/Luk3ePpBk+/H0TnOUsq3r5wbV5Lp8s50/AdSL sFmPdBlapUK8maOfYuAV6nJyHzn+9KZEY+mCkwrI71UACvAfJMn4W0pH/wxtqtZvefXtG8 tmmShMtuw+3NAA0MKi2N+Wu+R6BcXrM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mRmS78jNSEjRbW1RfkNVcIiFQs+BtHlpdjo+RIOliaY=; b=pHqKADI599qjUdgBEYHYVyDqe6 ou0qZ6mtipU3S8/Eiqj4Pd5m+fm9PeKEPgRjq8PIwM93gLrRIEHfIypzmcW01nbySu6HTLdBx35Tk Gu16v/G7/9q+pkktWzEtV0AdfjowT4yPU2yitKZzNx1NfDssUQHuHC/3X2eezwavD6f5tSY66o+B6 6LoLigZFFyUjS/KOgmCHOpBQhnea4mvNqPRGFheQsZ8zeyDqDGrg3eGQT+fz6tSDSKO+OmEbf1WGd 5yA1mP2EX+uvHM73Fx8RaT8toZMgsF6mayW1XU1Z6x8Mtpu6oBG9hn96oABxTDFN6WcHeUPw88XBv mfwFkw3A==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.98 #2 (Red Hat Linux)) id 1snfnG-0000000AKOl-3Xs9; Mon, 09 Sep 2024 14:55:06 +0000 Date: Mon, 9 Sep 2024 15:55:06 +0100 From: Al Viro To: Christian Brauner Cc: Jan Kara , Linus Torvalds , Amir Goldstein , Aleksa Sarai , Mike Rapoport , Vlastimil Babka , Matthew Wilcox , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: copying from/to user question Message-ID: <20240909145506.GL1049718@ZenIV> References: <4psosyj7qxdadmcrt7dpnk4xi2uj2ndhciimqnhzamwwijyxpi@feuo6jqg5y7u> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4psosyj7qxdadmcrt7dpnk4xi2uj2ndhciimqnhzamwwijyxpi@feuo6jqg5y7u> X-Rspam-User: X-Stat-Signature: 78t8tc1abc6a61x1gyrr19zmewp5t1oc X-Rspamd-Queue-Id: 734D5C001E X-Rspamd-Server: rspam11 X-HE-Tag: 1725893711-722493 X-HE-Meta: U2FsdGVkX19CeDVRQmDMjGwuGxNB+St4G6IEgb2l2l52YHnvyKKmlvunswItWgfcNfIyk7ll+YcFkT1VJsI+pHrJCf1Lbo0wYaqwemsgpjYjqSZm1htmWdAH2IVTdfqpHzfk2jtrHreS0Mzt+SeWTzzgMTCDQgulggBSkdotbG4k2U1Q4WM/zwpwk0SdE1iTm6DvX3A+aBkyXx1xybs9qYbU9SLbV8+yhyQBqRvdDPL0gIwYX04RYAlsbDAOxovTle5/5efiia5nBtMs/mVPFeqF9w/mDy8LBxtToN1XmCpabOjN8vG5eQrplzRlDeHvOyknf9h1lxon6TmjBBRU4aZs80DruHNFr8tld/a8G47e3TLaD5DKdQtfVIePhc4r+3gt8f37YZpwKAAobGoRzuhAgGTg8/fArWqcuDOnwCfwmiLytnKLZgZEIuorcOV8cCYanfVzq+17Chgqhm5ldeO6OGzjuLAZinsJhcEWyk9lXV+hPrB5FxeLC5+lrSvYvArAWXtoiMLivZe+ZJe2luRh/mz6cLmC7/RvpN8D+W+gbGzZo5FWeub4r0rW0+XAUWne5ZnnEdsBNEpa4UUKtrLNTIsFLNUsIupIqb14UsdNzpxNpIO0E1tcer9QKr4Z9tShhv2+YHufEEfq+yq8pgZ6G2+uEzVep5AK2fLpIjZ1wJ7w7FHDi/3tHZZEDnelg+3GT1ay8+xcVnM9Vonspy0NgEEqF/TpchuS+WODJ2ZFNjB7ZLnLZgMK4cGHyjrZiyUtRwgZYD1KuJwMbdGIvvKvSsC/9XFog4ZxOd5oy79TEGH96iypFdIUoSlupmmc9aNL/4CMpv5EDS6Eu/g6F5j+/A0n1UGloZuVtvcu374DJ7OTXRTcWz7eAGJ/grVMXcmsX3WnxP9c5aP3WdDOWETaCK0B67o5bs397xbIxIDU9sj3H9C/+dYAGrQ65rGYoIX9mxeNAH0suc5mFjr 8ahsbSZz dDswu8tmI6bynn9bd6EL02LbAqb9Z2NY7Msnh8lGBOtpkVqAewegH1i5vnSFBFHlRISUjgXKTsfWBdhf4SEkNvmGbWgKxo0tTxai5OShODm+Z821xcbgwnlOq2wqMzk9yFzYy7TNNQzws1c9PggnzRReDhUN8gZxsrNPZmPDMzGMl+CO0ONzC8YadpJr2jbjswz1U087TTpsoI19Knp0IwgyIXnpqHi7BMY6hzd6jaWZB8jLVi/2jPvJN+yh+mLwgQTHODZoY4KR0KelMQA73B9hS2G1j0hcJ2t8a4BOkQlxp6ltVeoHrsTtiH3w+w5CMxrSrXIRPQUH9vfI2AYXnFWmMAxOcAPjZ/4bzBK7NibQIzBqkP8xeYywbVVS5DDLCr5EQgGr+/aPaKoZCWaonUwTYqqVTfRLtzrl9aCskKetxlvqpHSERmimjXJEG1jYbjv+q X-Bogosity: Ham, tests=bogofilter, spamicity=0.000242, 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, Sep 09, 2024 at 10:50:04AM +0200, Christian Brauner wrote: > Hey, > > This is another round of Christian's asking sus questions about kernel > apis. I asked them a few people and generally the answers I got was > "Good question, I don't know." or the reasoning varied a lot. So I take > it I'm not the only one with that question. > > I was looking at a potential epoll() bug and it got me thinking about > dos & don'ts for put_user()/copy_from_user() and related helpers as > epoll does acquire the epoll mutex and then goes on to loop over a list > of ready items and calls __put_user() for each item. Granted, it only > puts a __u64 and an integer but still that seems adventurous to me and I > wondered why. > > Generally, new vfs apis always try hard to call helpers that copy to or > from userspace without any locks held as my understanding has been that > this is best practice as to avoid risking taking page faults while > holding a mutex or semaphore even though that's supposedly safe. > > Is this understanding correct? And aside from best practice is it in > principle safe to copy to or from userspace with sleeping locks held? You do realize that e.g. write(2) will copy from userland with a sleeping lock (->i_rwsem) held, right? Inevitably so. It really depends upon the lock in question; sure, milder locking environment is generally less headache, but that's about it. You can't do that under page lock. You can do that under ->i_rwsem. As for the epoll mutex... do we ever have it nested inside anything taken on #PF paths? I don't see anything of that sort, but I might've missed something...