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 7A0DEECE579 for ; Mon, 9 Sep 2024 14:31:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB5556B0175; Mon, 9 Sep 2024 10:31:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D66716B0176; Mon, 9 Sep 2024 10:31:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2D736B0177; Mon, 9 Sep 2024 10:31:35 -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 A72116B0175 for ; Mon, 9 Sep 2024 10:31:35 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 273571601A4 for ; Mon, 9 Sep 2024 14:31:35 +0000 (UTC) X-FDA: 82545438150.09.F0BE7E1 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf29.hostedemail.com (Postfix) with ESMTP id 2F7F412000C for ; Mon, 9 Sep 2024 14:31:32 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=RIB3PDzc; dkim=pass header.d=linutronix.de header.s=2020e header.b=yzwzEdcE; spf=pass (imf29.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725892192; 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=p2DzKilptjmCGepX1IgkvLR+a5gWmN0aU0k+31PBodc=; b=QMmlHG9J8RLu+HgreqbGdxKes4oGF8YQmcH9bgrm/qO1Y76LJC2JE2fJhtwXQA4myeNyN1 tKpxMrhUg2Ra4wqp6dBS1tpncMXyJNprYBRj6YujWz8wr5Ddq/VuMGAof+1ktq7GkGmqKF 6q0/pDlaEv6MuTv79pw3itEK8Wkvnx0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725892192; a=rsa-sha256; cv=none; b=dSkdj8Nrd4WHe72B1C4kspGKwi5ilFh3JrQtquZnKpVH/+a4Hg/Zu0d4MBeLPXUe08Eh5q JT2WSkMLRNwvvtCHzzmIXeiOsYgCdAJl44xdM1DVFMQijTh95hNJofRVrtGmRgsOWxAFcJ 6s4xRvF9vdzERGLvdz26tpIY9MJ/9gw= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=RIB3PDzc; dkim=pass header.d=linutronix.de header.s=2020e header.b=yzwzEdcE; spf=pass (imf29.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1725892290; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p2DzKilptjmCGepX1IgkvLR+a5gWmN0aU0k+31PBodc=; b=RIB3PDzcOjbWVApDvjxxJMZ+aOWvLfUui1JhYQ7L+x4T2D8Ct/KNx9YOJBFrBAHiKMi9p8 gZqb/O1AhK5eUGoJaADl2M/JvxaQj0WtyBBpQOuTguhcrVWa1y/JUJxqwW3DGk3cJpPWwa jwYLXqyRhS10KIM04WN8bcEHisk3TS5nZ1ankjqTHPeoPE2yyUjI0zGEnH9ROIZyRcKtRL 6E27tltmLpmzBFWOaM35J3FthtKrty+WY4O7m0EubmZwpU7N6gqKe4wsjm6goTT16Vfq41 zCVMbONPszjUxntPK6vjPCuNiucDrZhWcigqFElQFtgD9PGJSduxdjaQV5gJxg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1725892290; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p2DzKilptjmCGepX1IgkvLR+a5gWmN0aU0k+31PBodc=; b=yzwzEdcE8zf0zoihvT/bDslO7NDo2F17T3q5Eqlj0FOfxGZlRUGimkx4ICjSePrj3tEBun We9BHmBE4Q1biJBA== To: Arnd Bergmann , Christian Brauner , Jan Kara , Linus Torvalds , Amir Goldstein , Aleksa Sarai , Mike Rapoport , Vlastimil Babka , Matthew Wilcox Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: copying from/to user question In-Reply-To: References: <4psosyj7qxdadmcrt7dpnk4xi2uj2ndhciimqnhzamwwijyxpi@feuo6jqg5y7u> <20240909-zutrifft-seetang-ad1079d96d70@brauner> Date: Mon, 09 Sep 2024 16:31:30 +0200 Message-ID: <87zfogc30d.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 2F7F412000C X-Stat-Signature: zyquc4jfi31m5wu5oa8nr47f1aq9dc9w X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1725892292-625483 X-HE-Meta: U2FsdGVkX18qho7PAYvSlv5w5AEf+ZgMvhciHNpkgLWyJ36nwiihKh62PaiM/HBuFU000cjGDcGDiF7o/eYhKjcf/Q1fty5Ek8Imfnm9TboIjEE/+9Mvs0USOMkNvE7RCvI9g/SKihK1HwoaJeT8mjM7ae/lCubkGipTMYz7Mkkt32H/ALIN0hsA/FYXlgYcAmJCgES8n1elOVtpoTJqKNEepPPnEZLmJRmcS32J8AFXifIYPXzVwU/AG7THg6S2lyki5LfBAvkn8R5ZgK5nlLqaYeO0zh7duxFMQZ1aWJ625haup5oN7IE81F7Gvglc9WBmkgjEuyIoHdv0Iyg1ghpFW6WVZnoTl0t1SrcJwkYN+3m8eP0bYisdmayzsHR1B1fjFZYjvhL7x/CElO3yF4n5lOHWdXcfoqQklgr8P3z+jPD8Y4c5F/L8YqvzTfAOH8RUCIGaNwm9a+3tWUXa4fPIxJ4MuhzX1HhID6x8fbd9tP/d9rO+L+TvnRzFDKuUnAVJHb3ibYIS5IEIKBTGkbnVxSHNsYzsDvntXvBJ8HUGPVdNA+l8sqtQHoH4fgu93AxFq2X8RH8r4Ml4cLxXcKs6+WTko1EQfMuCYjDAcvddvv7PYS4zX315zPwZu/JnpTkNBeRdyIft3gwUKHUfh1omI6uvJ3VjK/Rs7i2heF4q0YRl+cEpaB7KSPfpkOa2Csg04EDDSjs/fiLBnuj++4y6mF2pZCAyPKwZwuOtXci1ToDOy8nsSJvUeG/ClfIrB7FVmLhA0OEuqB/NWJDv+i/Klg5vfT9LhxnBC5xEKLsX5kbnaJGnUxbspg3tyEOphKlxOlqiST9P2Sh68m71kYRcrxHo9rAdeS+85RQXC5J4NDFOQbRN6dJ20w652J8jGuE0Lt8EUWg2dqQ8IQtpwMgMJADwa63EOxD6oNKaxmI92iUsz0mJkwPyT8Ppn8hvKy9YGajgRi9SWVm6htf +7v3Ceb/ B8Unc2QW3NCsZbiASGqzq3deZXN3mUXQ2u565v+0XPc+xDTPRBPSUrtR9kh/aPbhglF14APnR4Z7CQK/tVC+fijgCEAkvhGQzFuSD/lUB3PFO+RbE0aeMp1BTWzoF5fvKoexBXIGWE8zmPNV/wvhvKqDy3W0q7nEOYmOT 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, Sep 09 2024 at 12:14, Arnd Bergmann wrote: > On Mon, Sep 9, 2024, at 09:18, Christian Brauner wrote: >> On Mon, Sep 09, 2024 at 10:50:10AM GMT, Christian Brauner wrote: >>> >>> 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? > > I would be very suspicious if it's an actual __put_user() rather > than the normal put_user() since at least on x86 that skips the > __might_fault() instrumentation. epoll_put_uevent() uses __put_user(). __put_user() does neither have might_fault() nor does it check the destination pointer. It's documented that the caller needs to have validated it via access_ok(), which happens in do_epoll_wait(). > With the normal put_user() at least I would expect the > might_lock_read(¤t->mm->mmap_lock) instrumentation > in __might_fault() to cause a lockdep splat if you are holding > a mutex that is also required during a page fault, which > in turn would deadlock if your __user pointer is paged out. Right. But an actual page fault would still trip over that if there is a lock dependency chain because pagefaults are enabled. Coming back to your general question. It is generally safe to fault with a sleeping lock held when there is no invers lock chain vs. mmap_lock. Whether it's a good idea is a different question, which depends on the context of what the mutex is protecting and what consequences result in holding it for a extended period of time, e.g. due to a swapped out page. Thanks, tglx