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 X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7D17C49EA2 for ; Tue, 22 Jun 2021 15:53:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 778C261380 for ; Tue, 22 Jun 2021 15:53:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 778C261380 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 666C06B005D; Tue, 22 Jun 2021 11:53:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 616E76B006C; Tue, 22 Jun 2021 11:53:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 491FD6B006E; Tue, 22 Jun 2021 11:53:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0031.hostedemail.com [216.40.44.31]) by kanga.kvack.org (Postfix) with ESMTP id 04CD16B005D for ; Tue, 22 Jun 2021 11:53:24 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 434071693E for ; Tue, 22 Jun 2021 15:53:25 +0000 (UTC) X-FDA: 78281804370.07.0B14E30 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf05.hostedemail.com (Postfix) with ESMTP id DB558E0009B7 for ; Tue, 22 Jun 2021 15:53:24 +0000 (UTC) Received: by mail-lf1-f51.google.com with SMTP id f30so36812256lfj.1 for ; Tue, 22 Jun 2021 08:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gwo/MhC5LC0KEncK3DG2C2podgit3zr1JlakISdk5lc=; b=EekqAlLo38I3+bma4TRfQUoU/27cGolaw5/ao3/1ym1iTDRjXSqaJK56RPEHetSNrU cl69eLI5kvNsYfD5bCSlk2NKM/guKT0Vxi8kFK7heezPGm1iuj8Gk/evz2SAI87Ydvuw WF17T260tx9+dZfHefOuNan6bAz6vuwSYjfN4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gwo/MhC5LC0KEncK3DG2C2podgit3zr1JlakISdk5lc=; b=ip4ygBuyfVCwBN4+N53KmGDg+Mrb49e4GfEtqbjue6wSxjTlT15yGHOjxIH6tqZZCF 5KqcUWIVIaRq4C2Mvn9mcRSk0JAkkDBGdyfG59jn9gUr3BwZEEvgY5K3Ot0tSOJAuWru o4Hc0s5mV8g++vT+Rcq6Ffiz3T9nrwXZ0O/pNJ9qc9iXDxkMK2kw9Ui+ZFEQdJ1nT4Pc dk3VlTWuUr/UVrlzVgYsXPonSVq0cQev8CmzMxH1rAXJy9FMG7c0hxWgKTCS5kkzIMTh tl3NwG9/S9295/hdbB40XwAnaCCPMSsYa3Mz0rT0PTnkSdJtSxN3L5D2htr7gd0yT4Iq N2dQ== X-Gm-Message-State: AOAM533JqP3OecLELjsxXrRjDYtbXKOo483RLuxHZ3aT4Ir9EoM5KOlN 3WbHCT2znCTn2Kg9VQ/zcqFpNqAzuS1KbHy2Vvs= X-Google-Smtp-Source: ABdhPJzC8CRfT7q3urxOnEFMK3rP1GmzLBvCjp/d/g/SRUWgZiX3tTl17HK/vBnmwbJHC2y5/ufpaw== X-Received: by 2002:a05:6512:943:: with SMTP id u3mr3353769lft.413.1624377203201; Tue, 22 Jun 2021 08:53:23 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id e30sm2259141lfc.67.2021.06.22.08.53.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 08:53:21 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id d25so2750780lji.7 for ; Tue, 22 Jun 2021 08:53:21 -0700 (PDT) X-Received: by 2002:a2e:22c4:: with SMTP id i187mr3838207lji.251.1624377200796; Tue, 22 Jun 2021 08:53:20 -0700 (PDT) MIME-Version: 1.0 References: <3221175.1624375240@warthog.procyon.org.uk> In-Reply-To: From: Linus Torvalds Date: Tue, 22 Jun 2021 08:53:05 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Do we need to unrevert "fs: do not prefault sys_write() user buffer pages"? To: David Howells Cc: "Ted Ts'o" , Dave Hansen , Andrew Morton , Matthew Wilcox , Al Viro , Linux-MM , Ext4 Developers List , linux-fsdevel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=EekqAlLo; spf=pass (imf05.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.51 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: DB558E0009B7 X-Stat-Signature: g4owyyi1z3tti4njh88sc6zb4kfpot6q X-HE-Tag: 1624377204-695151 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 Tue, Jun 22, 2021 at 8:32 AM Linus Torvalds wrote: > > But yes, it could get unmapped again before the actual copy happens > with the lock held. But that's why the copy is using that atomic > version, so if that happens, we'll end up repeating. Side note: search for "iov_iter_fault_in_writeable()" on lkml for a gfs2 patch-series that is buggy, exactly because it does *not* use the atomic user space accesses, and just tries to do the fault-in to hide the real bug. So you are correct that the fault-in is something people need to be very wary of. Without the atomic side of the access, it's pure voodoo programming. You have two choices: - don't hold any filesystem locks (*) over a user space access - do the user space access with the atomic versions and repeat (with pre-faulting to make the repeat work) There's one special case of that "no filesystem locks" case that I put that (*) for: you could do a read-recursive lock if the filesystem page fault path can only ever take read locks. But none of our regular locks are read-recursive apart from the very special case of the spinning rwlock in interrupts (see comment in queued_read_lock_slowpath()). That special read-recursive model "works", but I would seriously caution against it, simply because such locks can get very unfair very quickly. So it's a DoS magnet. It's part of why none of the normal locking models really have that (any more - rwlocks used to all be that way). Linus