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 B209BC5478C for ; Wed, 28 Feb 2024 19:30:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8C196B009C; Wed, 28 Feb 2024 14:30:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D3C1F6B009D; Wed, 28 Feb 2024 14:30:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C03B16B009E; Wed, 28 Feb 2024 14:30:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AD3126B009C for ; Wed, 28 Feb 2024 14:30:00 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1052A140F9C for ; Wed, 28 Feb 2024 19:30:00 +0000 (UTC) X-FDA: 81842202960.17.84FF156 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) by imf08.hostedemail.com (Postfix) with ESMTP id 52DE8160017 for ; Wed, 28 Feb 2024 19:29:57 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=sfKDi1Jw; spf=pass (imf08.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709148597; 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=3bEiqF8nKNDfPOHcfJQT88nOjb9dvia7MJkVhkJVj+I=; b=8CXmvB96FLXgdP0Vg2z3IptURYmvJOvj54dVqUYYopF928//UEhOd0LhopmB3O5ZNqih3F ny5SHzB8gtVbCrR//AiA09H9GTT95GGjtwKskdQKWVmsNnwTO1eGU77y6A/hJJdg16cYG/ 3DDcNUSEI0lcoCNYu2D3pbidzwCS50o= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=sfKDi1Jw; spf=pass (imf08.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709148597; a=rsa-sha256; cv=none; b=K/Px06ps70AqbT0ecTtUMZUnNGgu0ffM7zlzrjMKTXLFfiwJA3tDHdHQ71bUHRqk6YTnBI iEkWBGxCqyjNBc4W+cJUdR+PiQU39VJioEw++2pvUZ+L6oLbStrjgHTRfW500ogHXT3ivr l74KbQDcI+o+pUVwt9k9N3O1+Lf6WkU= Date: Wed, 28 Feb 2024 14:29:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709148595; 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=3bEiqF8nKNDfPOHcfJQT88nOjb9dvia7MJkVhkJVj+I=; b=sfKDi1JwoWb11G1OH2fvye9orutfpFajmw3ximt3T/JXfuCnp6fai/xBsJaKAS4TdxUHMF 8o242ulyHfrbBbbKBEo30TO5GuInCXxUduZvWiLxM2d750Yb0YH30PQ6ee2qc8k9qATMKx bDMd7pq7x7ONpXJJnCb/MlGSUg5BLzE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Linus Torvalds Cc: Dave Chinner , Luis Chamberlain , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm , Daniel Gomez , Pankaj Raghav , Jens Axboe , Christoph Hellwig , Chris Mason , Johannes Weiner , Matthew Wilcox Subject: Re: [LSF/MM/BPF TOPIC] Measuring limits and enhancing buffered IO Message-ID: References: <4uiwkuqkx3lt7cbqlqchhxjq4pxxb3kdt6foblkkhxxpohlolb@iqhjdbz2oy22> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 52DE8160017 X-Rspam-User: X-Stat-Signature: n3om46pm5yfo4wynnq6fx1z5zj8zmeg4 X-Rspamd-Server: rspam01 X-HE-Tag: 1709148597-393262 X-HE-Meta: U2FsdGVkX1/CRGMgqdXg3GVPbfruVND//qn7+ieQ3ydQlX71Rk8KzmKYc+iuV8fcJWwGJOAhqYaw4jnm3D4MvVGVFNI8z8pYHoJ5HV+2OUpjInvtYwmF+GfL6QI7yl3agPI8jSbpOfv+owCnOLu04p2uNgE+w469COQh0vbojZf02cRLlpKy3DOKFFvadicfMloT0ENKV3Fb2eP+EIwR03Lc3DcOJkWTzaYFB6dErQIA28AeMrqRuNZeECT3BtgeNTYqe0tRgkoX6WZkRezjJIyVYFNOS3ooVeUPl6q/W57K0v8TkR0hTb+gDiA2/6d4W3MKbbfTgyjjWNT+8/87ED8H0ktcXPjxFL5RvyFXO/eSqbwuFZ/7n7mXrAm7H2JbHquBZCy2eXz7fVxXz/XZv91J5jrbKhH8v2K/buPSC0HyaUfeKyxm7tHVvVGYBJ7oEb8J2Ic9HYsCUE01N1W7MMkg5uIhwlr8NcQMLo1YQnVSnr5j+Yq3HOGH/kvKoVMD5S81hk6s5ipEm+OyCs98zbVWmwJB7izWfDwOsW3DF1ZndfT+DgQQ2hrHDx1nFmeAd4rYW4uO46oUB89OOOgHBsRntsj1v9/apcWOmjrlV0sm3JY+jKJkIbVd4hn9WDbnpjQ2nT7Kii0rQH+4pykWlNUP0tioisYcbApHC6+ylEM6e/lwBglstnjUxOOLgLgOq04fyFPDu7yD/OL/hkXUpTPWmWdfM6Z4qOqBgviWwpa5U8fH48n2e3pNB0pmom/NyoD9C56vKHP6ZuYRzo7gfzed3XfrX0McQ19IjZ+rKtM= 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 Wed, Feb 28, 2024 at 11:09:53AM -0800, Linus Torvalds wrote: > On Wed, 28 Feb 2024 at 10:18, Kent Overstreet wrote: > > > > I think we can keep that guarantee. > > > > The tricky case was -EFAULT from copy_from_user_nofault(), where we have > > to bail out, drop locks, re-fault in the user buffer - and redo the rest > > of the write, this time holding the inode lock. > > > > We can't guarantee that partial writes don't happen, but what we can do > > is restart the write from the beginning, so the partial write gets > > overwritten with a full atomic write. > > I think that's a solution that is actually much worse than the thing > it is trying to solve. > > Now a concurrent reader can actually see the data change twice or > more. Either because there's another writer that came in in between, > or because of threaded modifications to the source buffer in the first > writer. Yeah, that's a wrinkle. But that requires a three way race to observe; a race between a reader and multiple writers, and the reader doing multiple reads. The more concerning sitution to me would be if breaking write atomicity means that we end up with data in the file that doesn't correspond to an total ordering of writes; e.g. part of write a, then write b, then the rest of write a overlaying part of write b. Maybe that can't happen as long as writes are always happening in ascending folio order?