Message ID | 1115586887.187161.1677658022188.JavaMail.zimbra@nod.at |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp3503837wrd; Wed, 1 Mar 2023 00:18:45 -0800 (PST) X-Google-Smtp-Source: AK7set9Sl8sRIel3QPqfnWFuP2gehLP8Ph0dCvUxreXtAbVVvyhvwCyCkRi3DpCXDlKCEF7SGqNE X-Received: by 2002:a05:6402:110e:b0:4af:59c0:5a30 with SMTP id u14-20020a056402110e00b004af59c05a30mr5315717edv.38.1677658725716; Wed, 01 Mar 2023 00:18:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677658725; cv=none; d=google.com; s=arc-20160816; b=to/M9eJAYrggC2HWiYNpOrtcsUJwm3gBSqd2VsnaIdVpUwQUx32dQSiD6x47Pm35yy rtjjDqK3Dc7HjXJXLKOz2MQV0oAU2xYHFtMjtxbrF74TVxiYtWuNJ7SnMVoe8Ek+RFgT H/ly8FjYsXbSsRSYExbj/uDV9PL9cNH7178dZWKO6DlYqjOGfF9qXmkqO/lH3MdoiRjl r+zl6tcQCiQsfGdU0IHGiVPDVBfKOMsIDL/cxpTrdBsNpl9j8yN0VDeB7fFDXUW2VsRU u441OlUph1jz2mi69CQn4zPYaVrlCYTxKsGW+biy3qcGw4J4G4OG3BXNDuJrm3ZLYV8k jcsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:thread-topic:thread-index :content-transfer-encoding:mime-version:subject:message-id:cc:to :from:date; bh=fzwt0kay8QrQKdMGUxpJWvBuFsugn1zqoqtIUqK531w=; b=0BZHPlCBBWcbsYVVX4bH+Dxx/aThmlObbs8obj2baVcp4hne8B0C0teYr/maxgyf+T 65L+9N6gGueVDldS/byPoPphNTH34480xgjnCy7M0oBRFH2bIvyjUlaBPwO4yrE2bR1L Io+c9SMVteA4pv8jg/op0ECRloVKiuBzlbIkFiNE6lAyzlBS6ZNffjJpZXtvm7IcCtMP ZSNELNCT+RN5jJDRR6ejsr8m154Y4TMUtwrQLwbKF+OVxIqFPFjn1Crn2yUTWtV9NsL8 vikzBuXtxhs7csG+S9UFtJ73WJNDAkWa2N6pvB63a2HYSL7ong6+ewCbkGRRy3R70D+E XWMA== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t25-20020aa7d4d9000000b004bc6a0b0e0esi1036360edr.549.2023.03.01.00.18.23; Wed, 01 Mar 2023 00:18:45 -0800 (PST) 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 S229788AbjCAIHH convert rfc822-to-8bit (ORCPT <rfc822;dipsyhu@gmail.com> + 99 others); Wed, 1 Mar 2023 03:07:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229752AbjCAIHF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Mar 2023 03:07:05 -0500 Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CDFF437545 for <linux-kernel@vger.kernel.org>; Wed, 1 Mar 2023 00:07:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id A9A0B6382EFF; Wed, 1 Mar 2023 09:07:02 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JJYUEG33GHQY; Wed, 1 Mar 2023 09:07:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 5042C6382EFB; Wed, 1 Mar 2023 09:07:02 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wTWnOLs0gHPD; Wed, 1 Mar 2023 09:07:02 +0100 (CET) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 3819A605DED8; Wed, 1 Mar 2023 09:07:02 +0100 (CET) Date: Wed, 1 Mar 2023 09:07:02 +0100 (CET) From: Richard Weinberger <richard@nod.at> To: torvalds <torvalds@linux-foundation.org> Cc: linux-mtd <linux-mtd@lists.infradead.org>, linux-kernel <linux-kernel@vger.kernel.org> Message-ID: <1115586887.187161.1677658022188.JavaMail.zimbra@nod.at> Subject: [GIT PULL] JFFS2, UBI and UBIFS updates for v6.3-rc1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [195.201.40.130] X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF97 (Linux)/8.8.12_GA_3809) Thread-Index: roGm/tvZ5HdHDuKdZoGvK25uWKzwXw== Thread-Topic: JFFS2, UBI and UBIFS updates for v6.3-rc1 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,PDS_BAD_THREAD_QP_64, SPF_HELO_NONE,T_SPF_PERMERROR 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759152675751075045?= X-GMAIL-MSGID: =?utf-8?q?1759152675751075045?= |
Series |
[GIT,PULL] JFFS2, UBI and UBIFS updates for v6.3-rc1
|
|
Pull-request
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git tags/ubifs-for-linus-6.3-rc1Message
Richard Weinberger
March 1, 2023, 8:07 a.m. UTC
Linus, The following changes since commit 2241ab53cbb5cdb08a6b2d4688feb13971058f65: Linux 6.2-rc5 (2023-01-21 16:27:01 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git tags/ubifs-for-linus-6.3-rc1 for you to fetch changes up to 8fcf2d012c8641c18adcd139dba6a1e556338d36: ubi: block: Fix a possible use-after-free bug in ubiblock_create() (2023-02-14 15:17:55 +0100) ---------------------------------------------------------------- This pull request contains updates for JFFS2, UBI and UBIFS JFFS2: - Fix memory corruption in error path - Spelling and coding style fixes UBI: - Switch to BLK_MQ_F_BLOCKING in ubiblock - Wire up partent device (for sysfs) - Multiple UAF bugfixes - Fix for an infinite loop in WL error path UBIFS: - Fix for multiple memory leaks in error paths - Fixes for wrong space accounting - Minor cleanups - Spelling and coding style fixes ---------------------------------------------------------------- Christoph Hellwig (1): ubi: block: set BLK_MQ_F_BLOCKING Daniel Golle (2): mtd: ubi: wire-up parent MTD device mtd: ubi: block: wire-up device parent George Kennedy (1): ubi: ensure that VID header offset + VID header size <= alloc, size Harshit Mogalapalli (1): ubi: block: Fix a possible use-after-free bug in ubiblock_create() Jiapeng Chong (1): UBI: Fastmap: Fix kernel-doc Li Hua (1): ubifs: Fix build errors as symbol undefined Li Zetao (3): ubi: Fix use-after-free when volume resizing failed ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume() ubifs: Fix memory leak in alloc_wbufs() Liu Shixin (1): ubifs: Fix memory leak in ubifs_sysfs_init() Mårten Lindahl (1): ubi: block: Reduce warning print to info for static volumes Randy Dunlap (1): ubi: use correct names in function kernel-doc comments Thomas Weißschuh (1): ubifs: make kobj_type structures constant Yang Li (2): ubifs: Fix some kernel-doc comments ubifs: Fix kernel-doc Yang Yingliang (1): ubi: Fix possible null-ptr-deref in ubi_free_volume() Yifei Liu (1): jffs2: correct logic when creating a hole in jffs2_write_begin Yu Zhe (1): jffs2: fix spelling mistake "neccecary"->"necessary" Zhang Xiaoxu (2): jffs2: Use function instead of macro when initialize compressors jffs2: Fix list_del corruption if compressors initialized failed ZhaoLong Wang (2): ubi: fastmap: Add fastmap control support for module parameter ubi: Fix permission display of the debugfs files Zhihao Cheng (13): ubifs: Rectify space budget for ubifs_symlink() if symlink is encrypted ubifs: Rectify space budget for ubifs_xrename() ubifs: Add comments and debug info for ubifs_xrename() ubifs: Fix wrong dirty space budget for dirty inode ubifs: do_rename: Fix wrong space budget when target inode's nlink > 1 ubifs: Reserve one leb for each journal head while doing budget ubifs: Re-statistic cleaned znode count if commit failed ubifs: dirty_cow_znode: Fix memleak in error handling path ubifs: ubifs_writepage: Mark page dirty after writing inode failed ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process ubi: fastmap: Fix missed fm_anchor PEB in wear-leveling after disabling fastmap ubi: Fix UAF wear-leveling entry in eraseblk_count_seq_show() ubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed drivers/mtd/ubi/block.c | 109 ++++++++++++++----------------------------- drivers/mtd/ubi/build.c | 32 +++++++++++-- drivers/mtd/ubi/debug.c | 19 ++++---- drivers/mtd/ubi/eba.c | 2 +- drivers/mtd/ubi/fastmap-wl.c | 12 +++-- drivers/mtd/ubi/fastmap.c | 2 +- drivers/mtd/ubi/kapi.c | 1 + drivers/mtd/ubi/misc.c | 2 +- drivers/mtd/ubi/vmt.c | 18 +++---- drivers/mtd/ubi/wl.c | 27 +++++++++-- fs/jffs2/compr.c | 50 +++++++++++--------- fs/jffs2/compr.h | 26 ++++++++--- fs/jffs2/file.c | 15 +++--- fs/jffs2/fs.c | 2 +- fs/ubifs/budget.c | 9 ++-- fs/ubifs/dir.c | 18 ++++++- fs/ubifs/file.c | 31 ++++++++---- fs/ubifs/io.c | 6 +-- fs/ubifs/journal.c | 8 +++- fs/ubifs/super.c | 17 +++++-- fs/ubifs/sysfs.c | 6 ++- fs/ubifs/tnc.c | 24 +++++++++- fs/ubifs/ubifs.h | 5 ++ include/linux/mtd/ubi.h | 1 + 24 files changed, 274 insertions(+), 168 deletions(-)
Comments
The pull request you sent on Wed, 1 Mar 2023 09:07:02 +0100 (CET):
> git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git tags/ubifs-for-linus-6.3-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e31b283a58dfe50ab1641d8fd2ead9b62f9ab256
Thank you!
On Fri, Mar 10, 2023 at 4:19 AM Daniel Palmer <daniel@0x0f.com> wrote: > > > Christoph Hellwig (1): > > ubi: block: set BLK_MQ_F_BLOCKING > > This seems to be causing one of my machines to lock up during boot. > It's using a squashfs root that is on a ubiblock that is located on an SPI NAND. Hmm. That commit 91cc8fbcc8c7 ("ubi: block: set BLK_MQ_F_BLOCKING") is odd. Christoph - you removed the blk_mq_start_request(req); ... blk_mq_end_request(req, errno_to_blk_status(ret)); from the workqueue function, but while you added the blk_mq_start_request() into ubiblock_read(), the 'end_request()' is missing. So I suspect the IO has completed, but the change means that nobody was informed about said completion, so now trying to mount an ext4 filesystem on it hangs on the read. But I don't actually know this code, that was just from looking at the commit that breaks. Christoph? Daniel used your infradead address, I don't know if it all goes into the same pile, but let's use your regular one. And I can't see Daniel's message on lore.kernel.org at all, for whatever reason, Linus
----- Ursprüngliche Mail ----- >> This seems to be causing one of my machines to lock up during boot. >> It's using a squashfs root that is on a ubiblock that is located on an SPI NAND. > > Hmm. That commit 91cc8fbcc8c7 ("ubi: block: set BLK_MQ_F_BLOCKING") is odd. > > Christoph - you removed the > > blk_mq_start_request(req); > ... > blk_mq_end_request(req, errno_to_blk_status(ret)); > > from the workqueue function, but while you added the > blk_mq_start_request() into ubiblock_read(), the 'end_request()' is > missing. > > So I suspect the IO has completed, but the change means that nobody > was informed about said completion, so now trying to mount an ext4 > filesystem on it hangs on the read. > > But I don't actually know this code, that was just from looking at the > commit that breaks. > > Christoph? Daniel used your infradead address, I don't know if it all > goes into the same pile, but let's use your regular one. And I can't > see Daniel's message on lore.kernel.org at all, for whatever reason, > Indeed, I'm able to reproduce the problem and adding blk_mq_end_request() back fixes it. diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c index 1de87062c67b..3711d7f74600 100644 --- a/drivers/mtd/ubi/block.c +++ b/drivers/mtd/ubi/block.c @@ -221,7 +221,10 @@ static blk_status_t ubiblock_read(struct request *req) rq_for_each_segment(bvec, req, iter) flush_dcache_page(bvec.bv_page); - return errno_to_blk_status(ret); + + blk_mq_end_request(req, errno_to_blk_status(ret)); + + return BLK_STS_OK; } static int ubiblock_open(struct block_device *bdev, fmode_t mode) Thanks, //richard
On Fri, Mar 10, 2023 at 06:32:17PM +0100, Richard Weinberger wrote: > Indeed, I'm able to reproduce the problem and adding blk_mq_end_request() > back fixes it. Yes, that was my braino about failures from ->queue_req being handled by the block layer by doing completions, but successful I/O of course is not.