Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3901524pxv; Mon, 19 Jul 2021 11:31:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6ePTaZ97ZRQlfkItf4uenxs5j209FzgB9odDJCEeoDsKWo2VWbXaFsmNbC6G2dB0Opgvv X-Received: by 2002:a05:6402:100c:: with SMTP id c12mr6763536edu.326.1626719371808; Mon, 19 Jul 2021 11:29:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626719371; cv=none; d=google.com; s=arc-20160816; b=UQhSaun0icGWyO5CQzS8VJhKM6XGZVwBROCs/LGq4XT/YZPeKpgJPewCeeYqa26EAx PRwFLHXoif7bD+S+vO+smjggzp0EJ+pBBaPy4OuDZbNmQtx8qKuKntAJqanFn79MpIpT EbTe8Xi4K91Xl7eyYzSgs9nwpUEaggKMkA+BmBm9fB3ghMT3XHWia5XE7rr3jP+TDzCv Mcr/iY1a2KDjHjVIwdDAYBokEb27vi1zogxbnirD/FjuJdx90xj3G9TcYPhrXCewX4Cn rvMKX41Ab7DTZwr9kqhnxqV0yYPfCiv8BdNWDBAT8LBiUaMiSG4U6oBs+vAJUt7puN8Q ebXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:mail-followup-to:message-id:subject:cc:to:from:date; bh=F5gkO7Odbzq2mpm3A2936+ByuoLM52k8i0ecO+KcGX4=; b=alKt6rUnpDhdzfaBdMscfT7E+1RT/qZAb55v4Ixdi0RfXIskaxgDwTHc+8dcCSCRPv ztJf3FXJQ0lgKb6aQz6cV2yUuBD3rCJ4YsQk97H/jNLtFA6ywmRMkvyHKNAygPlvabw9 CP+o+bshL/HSNgUnO0P2imTaEeax9gOK8+GlPLmcOIR6V+Qp+RCWLh33vPXvUVew59JB FexBBie/mX/8LXhRsvDDDVvTCHqAhXPVXq9bOdAEnUJtlnru6zRwosOhvResT7n/oWyK 4lEZlDRJp+qHfCBMAkNLooDAG/DWTQP0J1MRZBB+6inSPU7njty11QROaKGp5Zlhx5mf xo2g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j11si22426209ejj.109.2021.07.19.11.29.08; Mon, 19 Jul 2021 11:29:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382183AbhGSRjJ (ORCPT + 99 others); Mon, 19 Jul 2021 13:39:09 -0400 Received: from out30-131.freemail.mail.aliyun.com ([115.124.30.131]:42244 "EHLO out30-131.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347041AbhGSQFA (ORCPT ); Mon, 19 Jul 2021 12:05:00 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R271e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0UgJZ4D3_1626713130; Received: from B-P7TQMD6M-0146.local(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0UgJZ4D3_1626713130) by smtp.aliyun-inc.com(127.0.0.1); Tue, 20 Jul 2021 00:45:32 +0800 Date: Tue, 20 Jul 2021 00:45:30 +0800 From: Gao Xiang To: Matthew Wilcox Cc: Christoph Hellwig , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, LKML , "Darrick J . Wong" , Andreas Gruenbacher Subject: Re: [PATCH v3] iomap: support tail packing inline read Message-ID: Mail-Followup-To: Matthew Wilcox , Christoph Hellwig , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, LKML , "Darrick J . Wong" , Andreas Gruenbacher References: <20210719144747.189634-1-hsiangkao@linux.alibaba.com> <20210719151310.GA22355@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 19, 2021 at 05:31:10PM +0100, Matthew Wilcox wrote: > On Tue, Jul 20, 2021 at 12:11:49AM +0800, Gao Xiang wrote: > > On Mon, Jul 19, 2021 at 05:13:10PM +0200, Christoph Hellwig wrote: > > > On Mon, Jul 19, 2021 at 04:02:30PM +0100, Matthew Wilcox wrote: > > > > > + if (iomap->type == IOMAP_INLINE) { > > > > > + iomap_read_inline_data(inode, page, iomap, pos); > > > > > + plen = PAGE_SIZE - poff; > > > > > + goto done; > > > > > + } > > > > > > > > This is going to break Andreas' case that he just patched to work. > > > > GFS2 needs for there to _not_ be an iop for inline data. That's > > > > why I said we need to sort out when to create an iop before moving > > > > the IOMAP_INLINE case below the creation of the iop. > > > > > > > > If we're not going to do that first, then I recommend leaving the > > > > IOMAP_INLINE case where it is and changing it to ... > > > > > > > > if (iomap->type == IOMAP_INLINE) > > > > return iomap_read_inline_data(inode, page, iomap, pos); > > > > > > > > ... and have iomap_read_inline_data() return the number of bytes that > > > > it copied + zeroed (ie PAGE_SIZE - poff). > > > > > > Returning the bytes is much cleaner anyway. But we still need to deal > > > with the sub-page uptodate status in one form or another. > > > > There is another iomap_read_inline_data() caller as in: > > +static int iomap_write_begin_inline(struct inode *inode, loff_t pos, > > + struct page *page, struct iomap *srcmap) > > +{ > > + /* needs more work for the tailpacking case, disable for now */ > > + if (WARN_ON_ONCE(pos != 0)) > > + return -EIO; > > + if (PageUptodate(page)) > > + return 0; > > + iomap_read_inline_data(inode, page, srcmap, pos); > > + return 0; > > +} > > > > I'd like to avoid it as (void)iomap_read_inline_data(...). That's why it > > left as void return type. > > You don't need to cast away the return value in C. Well, I don't check the current behavior of this, but see: http://c-faq.com/style/voidcasts.html Anyway, that's minor and easy to update if really needed. I'd like to check if it works first... Thanks, Gao Xiang