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 393B1C38A02 for ; Sat, 29 Oct 2022 21:00:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C29AD6B0071; Sat, 29 Oct 2022 17:00:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD9008E0001; Sat, 29 Oct 2022 17:00:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC7DF6B0074; Sat, 29 Oct 2022 17:00:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 998916B0071 for ; Sat, 29 Oct 2022 17:00:04 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6651E160693 for ; Sat, 29 Oct 2022 21:00:04 +0000 (UTC) X-FDA: 80075204328.02.2B50D10 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf16.hostedemail.com (Postfix) with ESMTP id D7AD918003B for ; Sat, 29 Oct 2022 21:00:03 +0000 (UTC) Received: from letrec.thunk.org ([142.44.75.242]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 29TKxXms024528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 29 Oct 2022 16:59:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1667077177; bh=EZKkqCeXaLZ8T9HRw8I9LaqHcaQSMf+IL4bg8ajaLlA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KoosaJyX9zI91btp1+85K5o0uLnH71GTcXpZSBZDpk8b5H7h6kosS66F3YxoZx4Gi hOVJ3m4IJavsFvBREuh97JJA27i8y/cTE/plnmn9v9cz6PUx0kRjvUH/5iesCB/HCN cauIMA+3IPh9edqP0VH08VGbdfOxp6HR0SdLG8LefJ9BdhQF677+EwFuHDFpHv0FMh ll0+Ez0otlvNHLVX1Dw9+AbPeFjih5XCvTh658w7Tpuk0dIaOrgM7YbWmRQ6PneIA0 iZ7Z5NU0FHqd7ckaIQ9aCmRkA832CDKASCRoS5oTm0qp5Z8/XOsJpd+htkUVXi9Nbm Did1wMpw2oVtQ== Received: by letrec.thunk.org (Postfix, from userid 15806) id 3AC608C29FD; Sat, 29 Oct 2022 16:59:30 -0400 (EDT) Date: Sat, 29 Oct 2022 16:59:30 -0400 From: "Theodore Ts'o" To: Linus Torvalds Cc: John Hubbard , Nadav Amit , Peter Zijlstra , Jann Horn , X86 ML , Matthew Wilcox , Andrew Morton , kernel list , Linux-MM , Andrea Arcangeli , "Kirill A . Shutemov" , jroedel@suse.de, ubizjak@gmail.com, Alistair Popple Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment Message-ID: References: <6C548A9A-3AF3-4EC1-B1E5-47A7FFBEB761@gmail.com> <47678198-C502-47E1-B7C8-8A12352CDA95@gmail.com> <3a57cfc5-5db4-bdc9-1ddf-5305a37ffa62@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=KoosaJyX; spf=pass (imf16.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667077204; a=rsa-sha256; cv=none; b=r4GxLHOxSLiaViFJk8k/wDBcVT5LMGCG5IDK9hx1Mz4wVVyd0vYoSy2WW9yI6xi38oymlX aKCsa7jhHbbT3uNF36gPOsnNWvfkeR/ErS57oTP9BwtP2qHUff9wZhaKyfDITbQY8QV9Gt 4I5tQHrgN1uYbg0fWK+1uOVVHqH9of0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667077204; 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=EZKkqCeXaLZ8T9HRw8I9LaqHcaQSMf+IL4bg8ajaLlA=; b=goldA9e09AgwQ1eGPLM3NaxBQOhOBSDr/gs4/pKxIZLKpaCTz4RpYrfTbNrIPh+apiUajN N1YRgY2JXx4iOoqHVz5+7xbN16vzVTPwlXpbqPK/RENT2MFKBreJmtUh1t+fnj43VtoN16 zUSHTLwwj7zUWXLhlyHSrMKaJxEgM0g= X-Rspam-User: X-Rspamd-Queue-Id: D7AD918003B Authentication-Results: imf16.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=KoosaJyX; spf=pass (imf16.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu X-Stat-Signature: wmx5x96s61jq68t55gk5d81htwtctjj3 X-Rspamd-Server: rspam10 X-HE-Tag: 1667077203-579573 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 Sat, Oct 29, 2022 at 01:15:26PM -0700, Linus Torvalds wrote: > On Sat, Oct 29, 2022 at 12:39 PM John Hubbard wrote: > > > > ext4 has since papered over the problem, by soldiering on if it finds a > > page without writeback buffers when it expected to be able to writeback > > a dirty page. But you get the idea. > > I suspect that "soldiering on" is the right thing to do, but yes, our > 'mkdirty' vs 'mkclean' thing has always been problematic. > > ... > > (a) filesystems just deal with it It should be noted that "soldiering on" just means that the kernel will not crash or BUG. It may mean that the dirty page will not gotten written back (since at the time when it is discovered we are in a context we may not allocate memory or block if there is a need to allocate blocks if the file system uses delayed allocation). Furthermore, since the file system does not know that one or more pages have dirtied behind it's back, if the file system is almost full, some writes may silently fail --- including writes where the usesrspace application was implicitly promised that the write would succeed by having the write(2) system call return without errors. If people are OK with that, it's fine. Just don't complain to the file system maintainers. :-) - Ted P.S. The reason why this isn't an utter disaster is because normally users of remote RMA use preallocated and pre-written/initialized files. And there aren't _that_ many other users of gup. So long as this remains the case, we might be happy to let sleeping canines lie. Just please dear $DEITY, let's not have any additional users of gup until we have a better solution.