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 X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63B18C636CB for ; Sat, 17 Jul 2021 15:02:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4D1B061159 for ; Sat, 17 Jul 2021 15:02:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234529AbhGQPFl (ORCPT ); Sat, 17 Jul 2021 11:05:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234897AbhGQPFe (ORCPT ); Sat, 17 Jul 2021 11:05:34 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D5D65C0613DD; Sat, 17 Jul 2021 08:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=7Xw1VcuTjgZ49t25zIRxicvryRU564jX2lY4pUY5o3A=; b=RyqOFqwmgDZXOtufkLpg6oCwEA juLFgW5sohegVkvt2PoNEwetF9INUp/TQwEtIfRYrlmd857WmaWVYc/IvC4oU+AGgmehR1Ggw3FPX nnU6+802ktykPsc9EROMcYW2QcUASskCnC+CDixXS6EPaGr6N+81kHUzTMRoPbAXNSk2FJtQY5vdA Qz1Ld4JR5SDFJFqKSyutbJYAhNP0sfjdT3Jyo6vM0jkv+WSGOjPg/xz3hk3X80TWCVjE+13HzSmFX 35qCT05yvpyQP8eLxR9prjIxoAxDWrf7h0mgtqdWrBvhMZ+Ant9h/e4UHRg7gmD8ZgcIk4iOVmjSU e4dvHlRw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m4low-005LrJ-Da; Sat, 17 Jul 2021 15:01:49 +0000 Date: Sat, 17 Jul 2021 16:01:38 +0100 From: Matthew Wilcox To: Andreas =?iso-8859-1?Q?Gr=FCnbacher?= , Christoph Hellwig , linux-erofs@lists.ozlabs.org, Linux FS-devel Mailing List , LKML , "Darrick J. Wong" , Chao Yu , Liu Bo , Joseph Qi , Liu Jiang Subject: Re: [PATCH 1/2] iomap: support tail packing inline read Message-ID: References: <20210716050724.225041-1-hsiangkao@linux.alibaba.com> <20210716050724.225041-2-hsiangkao@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 17, 2021 at 09:38:18PM +0800, Gao Xiang wrote: > Sorry about some late. I've revised a version based on Christoph's > version and Matthew's thought above. I've preliminary checked with > EROFS, if it does make sense, please kindly help check on the gfs2 > side as well.. I don't understand how this bit works: > struct page *page = ctx->cur_page; > - struct iomap_page *iop; > + struct iomap_page *iop = NULL; > bool same_page = false, is_contig = false; > loff_t orig_pos = pos; > unsigned poff, plen; > sector_t sector; > > - if (iomap->type == IOMAP_INLINE) { > - WARN_ON_ONCE(pos); > - iomap_read_inline_data(inode, page, iomap); > - return PAGE_SIZE; > - } > + if (iomap->type == IOMAP_INLINE && !pos) > + WARN_ON_ONCE(to_iomap_page(page) != NULL); > + else > + iop = iomap_page_create(inode, page); Imagine you have a file with bytes 0-2047 in an extent which is !INLINE and bytes 2048-2051 in the INLINE extent. When you read the page, first you create an iop for the !INLINE extent. Then this function is called again for the INLINE extent and you'll hit the WARN_ON_ONCE. No?