Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1813922rwd; Mon, 15 May 2023 03:30:49 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5sBE5xehx5E5o4tbVEpgem2VPmEAykQuTtzdN3WNyYh5tqQg3Hx22c7xWV/tgJ/8GSw+js X-Received: by 2002:a17:90a:31c6:b0:24d:ec21:b83c with SMTP id j6-20020a17090a31c600b0024dec21b83cmr33084208pjf.16.1684146648761; Mon, 15 May 2023 03:30:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684146648; cv=none; d=google.com; s=arc-20160816; b=PAdwGaydqIvwPUQw+a/dWe8dRtnZItZHUxHGA8FqnMOR0lg3+KfXbX1ExJx9rNkNAQ tWmChV42jvBYShH2dJqfSSA5h9DO/iXldllZeuG/9DqmMq2Kh1ewYvjg9DMOMcXrJh+w o4bX0jzQLipDI6Ue5gTGKYuRR/NBTg22iUwuP3tv6JxYSAjUjtgoKQYm1bny82o626oR KBznd7Dtm3w0/bnUUCc9pBbMgr4bJ1EHoBo5F7VnOgwO6wVhD5y1JoHTiOAaPwOL6TAq f66hFMnxsLX+EXtVKoNacMkAOcQXi4tZpJICKKsStccS6B2UTEvLdunUBjMBqKj/TuSg 2Eng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=2RAP3jxoJNCVQpwnfVSLjVMTuXEAq8t+TgQ/+B4O40A=; b=qWEYPELWzBRY/5EpbNE2l9ABWH/KOvVA8d7zr4esuczXH47zHa1OtqzEdDiqxXOyQl TOmOvNOxQ2uruI/r06MmXg04gbF0Nuv1/XNXZRWTpV5FY1mfpWWB75b9yZpTXf0Oj0sH lg8VvWHInvWw+XddaBB8XlUsKNiV7I1d6MUWh22PhCs11gFkhAFT25fCibkC7wM6Sdrz ndB+OLL2Ww+wA6grVVdYONPh98/XKxjjQxWIGAknGdrQtBmFndi9FQKGdwDbpJhO9TQR G/ooVajDKq9py7T03NlcyN70jHjTdNddP1bWcOpS5c/qD4BZCFUeK6J3hggXZjUNAeJh 5acA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l190-20020a6388c7000000b0053425a86ef8si1459160pgd.569.2023.05.15.03.30.35; Mon, 15 May 2023 03:30:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229963AbjEOKFU (ORCPT + 99 others); Mon, 15 May 2023 06:05:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240626AbjEOKEk (ORCPT ); Mon, 15 May 2023 06:04:40 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 360132D69 for ; Mon, 15 May 2023 03:03:56 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id D93A668BEB; Mon, 15 May 2023 12:03:52 +0200 (CEST) Date: Mon, 15 May 2023 12:03:52 +0200 From: Christoph Hellwig To: Vincent Whitchurch Cc: Phillip Lougher , Andrew Morton , Philippe Liard , hch@lst.de, linux-kernel@vger.kernel.org, squashfs-devel@lists.sourceforge.net, kernel@axis.com Subject: Re: [PATCH v2] squashfs: cache partial compressed blocks Message-ID: <20230515100352.GA24402@lst.de> References: <20230510-squashfs-cache-v2-1-42a501a17569@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230510-squashfs-cache-v2-1-42a501a17569@axis.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 12, 2023 at 03:18:05PM +0200, Vincent Whitchurch wrote: > +static int squashfs_bio_read_cached(struct bio *fullbio, struct address_space *cache_mapping, > + u64 index, int length, u64 read_start, u64 read_end, > + int page_count) Please avoid the unreadable formatting and do something like: static int squashfs_bio_read_cached(struct bio *fullbio, struct address_space *cache_mapping, u64 index, int length, u64 read_start, u64 read_end, int page_count) > + if (!bio || idx != prev_io_idx + 1) { > + unsigned int remaining_pages; > + unsigned int this_nr_pages; > + > +submit_and_retry: > + remaining_pages = page_count - idx; > + this_nr_pages = min(remaining_pages, BIO_MAX_VECS); > + bio = blk_next_bio(bio, bdev, this_nr_pages, REQ_OP_READ, > + GFP_NOIO); > + bio->bi_iter.bi_sector = fullbio->bi_iter.bi_sector + > + idx * (PAGE_SIZE / SECTOR_SIZE); > + } > + > + retlen = bio_add_page(bio, bv->bv_page, bv->bv_len, bv->bv_offset); > + if (retlen != bv->bv_len) > + goto submit_and_retry; Adding data payload to a bio while passing full bio_vec is usually a sign that instead you should do a (partial) clone of the bio instead. I think this is such a case. > static int squashfs_bio_read(struct super_block *sb, u64 index, int length, > struct bio **biop, int *block_offset) > { > struct squashfs_sb_info *msblk = sb->s_fs_info; > + struct inode *cache_inode = msblk->cache_inode; > + struct address_space *cache_mapping = cache_inode ? cache_inode->i_mapping : NULL; Unless I'm badly misreading the squashfs_fill_super changes, cache_inode can't ever be NULL here or anywhere else in the I/O code.