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 D2DA5C433F5 for ; Mon, 17 Jan 2022 09:57:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 484BD6B0071; Mon, 17 Jan 2022 04:57:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 435086B0073; Mon, 17 Jan 2022 04:57:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 323466B0074; Mon, 17 Jan 2022 04:57:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0142.hostedemail.com [216.40.44.142]) by kanga.kvack.org (Postfix) with ESMTP id 211616B0071 for ; Mon, 17 Jan 2022 04:57:48 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CF510824C429 for ; Mon, 17 Jan 2022 09:57:47 +0000 (UTC) X-FDA: 79039327374.04.381E6FB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 44377180007 for ; Mon, 17 Jan 2022 09:57:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1642413466; 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; bh=0ko6OUF03NtREbd4Ba6uZksPkCXStJRahIx6FjvF3q4=; b=TA8V1DPeqGcEES7H3aKLsuK2yYnEyJIoVrIrzZxRkj5oQyu19uKGFQBYWcXRWfTySC77+9 XjS4Pkc1XbpHZcI7sS0Ha4pHLhvtK72yhWaVL9hrctuEaHOMcv+sWj0KWlEOvUdzHniXOG JFgvZ/u1hRPcPUKUdnQZeE0SaLkZWqg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-300-In4HevWtNs-JnAKOIck5mg-1; Mon, 17 Jan 2022 04:57:42 -0500 X-MC-Unique: In4HevWtNs-JnAKOIck5mg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B59F7100C663; Mon, 17 Jan 2022 09:57:38 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.165]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1D7227B9E5; Mon, 17 Jan 2022 09:57:17 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells To: Alexander Viro , Linus Torvalds cc: dhowells@redhat.com, Anna Schumaker , Dave Wysochanski , Dominique Martinet , Jeff Layton , Latchesar Ionkov , Marc Dionne , Matthew Wilcox , Omar Sandoval , Shyam Prasad N , Steve French , Trond Myklebust , Peter Zijlstra , ceph-devel@vger.kernel.org, linux-afs@lists.infradead.org, linux-cachefs@redhat.com, linux-cifs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Out of order read() completion and buffer filling beyond returned amount MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2752207.1642413437.1@warthog.procyon.org.uk> Date: Mon, 17 Jan 2022 09:57:17 +0000 Message-ID: <2752208.1642413437@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TA8V1DPe; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of dhowells@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=dhowells@redhat.com X-Stat-Signature: e86st674ydcnntnzsezxxeytstf7iqe9 X-Rspamd-Queue-Id: 44377180007 X-Rspamd-Server: rspam12 X-HE-Tag: 1642413467-709672 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: Hi Al, Linus, Do you have an opinion on whether it's permissible for a filesystem to write into the read() buffer beyond the amount it claims to return, though still within the specified size of the buffer? I'm working on common DIO routines for 9p, afs, ceph and cifs in netfs lib, and I can see that at least three of those four filesystems either can or must split a read, possibly being required to distribute across multiple servers. If a filesystem was to emit multiple read RPCs in parallel, there is the possibility that they would complete out of order - particularly if they go to multiple servers. Would it be a violation of the way the read() family of syscalls work to write the data into the buffers out of order, and then abandon the extra data written at the end if one of the RPCs returned a short read? We would have clobbered some of the buffer that we haven't said we've modified. For buffered reads, it's not a problem as we can fill the pagecache out of order with no issue. David