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 4BFE5ECE577 for ; Mon, 9 Sep 2024 17:14:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D986E6B00CC; Mon, 9 Sep 2024 13:14:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D472F6B01A7; Mon, 9 Sep 2024 13:14:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0E3D6B01A8; Mon, 9 Sep 2024 13:14:28 -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 A506F6B00CC for ; Mon, 9 Sep 2024 13:14:28 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 35E1540D06 for ; Mon, 9 Sep 2024 17:14:28 +0000 (UTC) X-FDA: 82545848616.01.7F6631B Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf11.hostedemail.com (Postfix) with ESMTP id 24C6540006 for ; Mon, 9 Sep 2024 17:14:25 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=BtI40dwS; dmarc=none; spf=pass (imf11.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.221.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725901991; a=rsa-sha256; cv=none; b=yjy/G3N3MpcdmE/jQveA7g5TGhXv1pvOxkDHxC1TJS/Z29M5rSzvt4GW8XKNnZv5zWJSCV ZysIZHlc7pshLiUsYhobOlsFH2C0EoW0Cho5wf7dMlVMif0EpgB2dF1SDkmVHSU85DFQxS 5tehuRMED+tt6WQYkaBNdcRMAcE9Bfg= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=BtI40dwS; dmarc=none; spf=pass (imf11.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.221.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725901991; 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=WxmI8NiKkO8wbPu3kCjrzQtaE0L8pBmGZ0OhyJkNRrU=; b=rLXq9+05ZxhJAxHu4QO9KsStX+WFpskAmyuDTzMPBSjbxoOhidvRmkuS72g9M5wj25xqeV 8+GuBHqhcJ3CEb9ICLIm3HYb22YAR8csLv4RXJel/UuIB91SNRhRGI2AkOGzf0gN8gdVdx gec8etMGU5n6FUSNoD002KTCDPc2Fis= Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-374ca65cafdso2869310f8f.2 for ; Mon, 09 Sep 2024 10:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1725902064; x=1726506864; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WxmI8NiKkO8wbPu3kCjrzQtaE0L8pBmGZ0OhyJkNRrU=; b=BtI40dwSWvbCMdkhcEPJIcwx/gK3SwnSlmtZ4LTO+ilxugT5RwuKKplOZT7Tnd6V8W vl1u/vamTq/jimj28cOtAUrWUIFWmHsV6AptEERKb7veGuGFEG/supbLfrRQKJ3X5cUd 5Dka1FBvYBCPL+IX9RlU+K3yqtbQRxWWnosZk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725902064; x=1726506864; h=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=WxmI8NiKkO8wbPu3kCjrzQtaE0L8pBmGZ0OhyJkNRrU=; b=vc7SKa+AiOUdacbc0YQg8CBOMLkfW8PHWHrAFkeEf3R+y8JtGMXb5ycJMtDWm5nwnS dn6XAjmrVO5W45+c+rZzu6VPF03ohB6zEWzpPfxb/FNv7QTSdxfaL2xSCViyMVI8qC2F 5N5tSIEX3VkH378Z/n4F21nozWYbIuULXdFBZHiFeZm7NoqnxohxqNKwcaR5VuxpohIh m1uL+oYllU7w4a3W+H7eEcckiFL6clHepH+o/HF2obY5vzHGoU/ovxrS7vcoT2kPwoXD ID816l3Yk7SYVhbDpwIfOKZk1oNzBNQojZRP1aOKSpmOK747suZzCpB6gzUklfhS9lr4 ylRQ== X-Forwarded-Encrypted: i=1; AJvYcCX2zJ2/A9vthCmJUm4FunaU1DyORPwUpPvpYjnwhK7Cga2+8YsivpTCkIeQhWm65Lk59A2CVElV+w==@kvack.org X-Gm-Message-State: AOJu0YztinI2Bl1r3mZgKCeXzFQ080sFYlHBqry2eGeRCzTvLgtxvKaJ DMVW5YdKNyzXp9tlPP5/M+xUN3JKbKiVhy3LhqDQP2YZKKZJBhX8S4gil2P0jTTcnV/g/hvssZ2 vHac= X-Google-Smtp-Source: AGHT+IFqz6mAdsAOJRK8QRwPV60VcMytcAo1qeGVfOZumx8hTFrXfCgxzz5OsuUSim+nXFXGVHIE2w== X-Received: by 2002:a05:6000:1568:b0:364:6c08:b9b2 with SMTP id ffacd0b85a97d-37894a535e9mr6721031f8f.45.1725902063970; Mon, 09 Sep 2024 10:14:23 -0700 (PDT) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c3ebd8cdbbsm3223565a12.81.2024.09.09.10.14.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Sep 2024 10:14:23 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5c27067b81aso4533237a12.0 for ; Mon, 09 Sep 2024 10:14:23 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWhcrL7SFws/fldFrIAjiHyHsQ3GSFKCek+bLBvW1KZ5hbPq2944pQJDzhXnhq1nm0osZzFbtQ7fw==@kvack.org X-Received: by 2002:a05:6402:3708:b0:5a4:622f:63c6 with SMTP id 4fb4d7f45d1cf-5c3eac063cbmr3980933a12.13.1725902062748; Mon, 09 Sep 2024 10:14:22 -0700 (PDT) MIME-Version: 1.0 References: <4psosyj7qxdadmcrt7dpnk4xi2uj2ndhciimqnhzamwwijyxpi@feuo6jqg5y7u> <20240909-zutrifft-seetang-ad1079d96d70@brauner> In-Reply-To: <20240909-zutrifft-seetang-ad1079d96d70@brauner> From: Linus Torvalds Date: Mon, 9 Sep 2024 10:14:06 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: copying from/to user question To: Christian Brauner Cc: Thomas Gleixner , Arnd Bergmann , Jan Kara , Amir Goldstein , Aleksa Sarai , Mike Rapoport , Vlastimil Babka , Matthew Wilcox , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 24C6540006 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 7w3peswyt3d49obk4ftakwastf1dwd3z X-HE-Tag: 1725902065-757316 X-HE-Meta: U2FsdGVkX186p8r79jbEWGTROT4Qt9VUgnrTnsmftBKKgciqYgwQEgrTvoL7EI+Nsmmg+JYOx47GGIIxgJX3ehs/CrJ5+7mC8gjHfakoJrg4FIFmq00wC/E/zzzRw0NbJCALLDDt/zlTE9G3Xul01cIFnIdrZKd7hWHBBiEx18rf2f30Ln97f6TjoP/6JJL/EyHDF7gYq96ftZpjf4G42tXzs5/v5DV9a8HFrjb4thphbWCQJepWNzD9bnChjMpM9yYjtEf1+Tb4wuEvUZ4/Ugm+UqUWaplJhZk9vGwCFPLwiLL5xvWNAzveLdlgoleKAAFTUXOtmg1kN6aJlQq4XE5AMX1q6us3EOL84RP21rLdAy7b6LBS2mycjaVPulJR1vjj1D8TYLZeM7ms9Hyt7ELigXafVWjfP4fGxbQhKyfGwRfNEa++5OH+4NCIyqM9F7yvkXtTYv9KMzaI7B3Q2yOaMrtl0BM7AbH4UKL13t40iF/fb+jwx64EPGGleQz1BAlp8q1TJ4eXwbmfN6Ef7EgFrjbWSxA/YeDXxV75AQWjCft+pc2QfRZgSITntcCUAWROG1gJgDWVrPsZPKgsLW0WL5TF8Kjt1yrWqK5DvqaE9vSDdogGxYkJ7MKdocUNv9pF2tRjzD3qAgkbh9xqjL5u0fcb5T5A47QqwzdTMq9lPcAIkN5Kt4DIksQsJcd34mbuGqjk+snVbskDraVOVh6XX/+Mestmz41PiZNghW64kOnteC2FWkNeMK85hxMFSf7JGoShJX4T4Rj4/qlxgAgEDv78wWjMndWumXQ12Bwl8nCPBIrbizvaGBuKC3oHyF7cySkKzbqYYcSpymcXspLjlY05tUmCMoKNcxPriGOsOK5x1cwTLG1ttapdUmMeJvwbu6HIvERWULujZ7xAg5jT96Uqi/SL384RZgJMoCfUFSq551uWKUPtO3U3uby4ZYCCYRMctRVSTJmrA/6 vZcPguDW QvP1eMpZloia0xcSEUn2FRMxCID+IwpKu/NzDYHJP479TIio74C5FCDiUDsv1aActujPNXuKmmFZeyrOEZRytv9OHidjYk9e12pw+obQEDFFoUVUnaLqpT9w9P7YbWY/qfo3QPiNpk3bomuZMqcmyqeCkK9qZLKuQ1KqpUCw8l6+EsKM9D06eApbkYSUZOB9RfwCwbudZIKz4p9AYcU2fEQYloNGCiFO7oMkCKb2yT21mpbvqi/3CgeE86PQw4cCz6AC9NhZvpdQsU5mabpuMvS5FmlVtZtAaTwcHHpDV4ohnoMZShwJ/VuIxYayBXikRcxvUmH4lE9uuY7HI2CrECxsHx7SHK4OgbGI/fyGTQ7zEXPco4PGr3FI5XF8UHs8rTvgVfinrj9FsJI3SguXzwtxGvOIIbW68xd0L3naso3Pa9Infx5tjUGGfbjgudDsSHBeuy62D6e113aFWN189AWAzFcwMUb10qnOZ5+ftZB4sxwp9HxR+Hz9bHuzt9ohaNIYNNUvwynPUb2rAXzuRkbpwdw== 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, 9 Sept 2024 at 02:18, Christian Brauner wrote: > > > 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. It's indeed "best practices" to strive to do user copies without locks, but it's not always possible to reasonably avoid. IOW, accessing user space with a lock held *can* cause some nasty issues, but is not necessarily wrong. The worst situation is where that lock then may be needed to *deal* with user space page faults, and that complicates the write() paths in particular (generic_perform_write() and friends using copy_folio_from_iter_atomic() and other magical games). But that's actually fairly unusual. The much more common situation is just a random lock, and we have user accesses under them all the time. You still want to be careful, because if the lock is important enough, it can cause users to be able to effectively DoS some subsystem and/or just be a huge nuisance (we used to have that in the tty layer). And no, the size of the user copy doesn't much matter. A __put_user() isn't much better than a big copy_from_user() - it may be faster for the simple case where things are in memory, but it's the "it's paged out" case that causes issues, and then it's the IO (and possible extra user-controlled fuse paths in particular) that are an issue, not whether it's "just one 64-bit word". Epoll is disgusting. But the real problems with epoll tend to be about the random file descriptor recursions, not the epoll mutex that only epoll cares about. Linus