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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC59DC433EF for ; Thu, 16 Dec 2021 16:47:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239736AbhLPQru (ORCPT ); Thu, 16 Dec 2021 11:47:50 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:39897 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239675AbhLPQrt (ORCPT ); Thu, 16 Dec 2021 11:47:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639673268; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H4QQrv5yHw8uvREotMjEQW9H2R0fBtaao4kUBQhmBFY=; b=auNVdRF6pboxYXCb3pvPQEgy0GMZY3rfdCfGDmZMFrzS8bfjsFn2PbRxfgNb8R2uQQm5On Yn5nER/+JUaqi+P6UOihpGnhVkDh/7Wajsy2hD1xiqz2ZRSBO/EC1Qg6jdIRZRNV3cgxEQ WZIfrufsTtL29eQDEIog7r1okVL7llE= 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-263-6-Ukhu7bM6ieiGRqMNkqew-1; Thu, 16 Dec 2021 11:47:42 -0500 X-MC-Unique: 6-Ukhu7bM6ieiGRqMNkqew-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 75392801ADC; Thu, 16 Dec 2021 16:47:39 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.122]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8E6B51037F51; Thu, 16 Dec 2021 16:47:33 +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 In-Reply-To: References: <163967073889.1823006.12237147297060239168.stgit@warthog.procyon.org.uk> <163967169723.1823006.2868573008412053995.stgit@warthog.procyon.org.uk> To: Linus Torvalds , "Matthew Wilcox (Oracle)" Cc: dhowells@redhat.com, linux-cachefs@redhat.com, Jeff Layton , Marc Dionne , linux-afs@lists.infradead.org, Trond Myklebust , Anna Schumaker , Steve French , Dominique Martinet , Alexander Viro , Omar Sandoval , JeffleXu , "open list:NFS, SUNRPC, AND..." , CIFS , ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-fsdevel , Linux Kernel Mailing List Subject: Re: [PATCH v3 56/68] afs: Handle len being extending over page end in write_begin/write_end MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1828148.1639673252.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Dec 2021 16:47:32 +0000 Message-ID: <1828149.1639673252@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds wrote: > > With transparent huge pages, in the future, write_begin() and write_en= d() > > may be passed a length parameter that, in combination with the offset = into > > the page, exceeds the length of that page. This allows > > grab_cache_page_write_begin() to better choose the size of THP to allo= cate. > = > I still think this is a fundamental bug in the caller. That > "explanation" is weak, and the whole concept smells like week-old fish > to me. You really should ask Willy about this as it's multipage folio-related. AIUI, because the page/folio may be allocated inside ->write_begin(), generic_perform_write() tells the filesystem how much it has been asked to write and then the folio allocation can be made to fit that. However, at this time, ->write_begin() and ->write_end() have a page point= er (or pointer-to-pointer), not a folio pointer, in their signature, so the filesystem has to convert between them. I'm working on write helpers for netfslib that absorb this out of the filesystems that use it into its own take on generic_perform_write(), ther= eby eliminating the need for ->write_begin and ->write_end. I have this kind = of working for afs and 9p at the moment and am looking at ceph, but there's a= way to go yet. I believe iomap does the same for block-based filesystems that= use it (such as xfs). I think Willy's aim is to get rid of ->write_begin and ->write_end entirel= y. David