Message ID | 1115586887.187161.1677658022188.JavaMail.zimbra@nod.at |
---|---|
State | Not Applicable |
Delegated to: | Richard Weinberger |
Headers | show |
Series | [GIT,PULL] JFFS2, UBI and UBIFS updates for v6.3-rc1 | expand |
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.