linux-kernel - Re: [dm-devel] Processes hung in "D" state in ext4, mm, md and dmcrypt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACVXFVM8rcGJu-f+6zOgY8t4KPPR0J=giYD5dnCLL8_XVo234w@mail.gmail.com>
Date:   Wed, 26 Jul 2023 23:29:51 +0800
From:   Ming Lei <tom.leiming@...il.com>
To:     David Howells <dhowells@...hat.com>,
        linux-block <linux-block@...r.kernel.org>
Cc:     "Theodore Ts'o" <tytso@....edu>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Song Liu <song@...nel.org>, Christoph Hellwig <hch@....de>,
        Alasdair Kergon <agk@...hat.com>, linux-raid@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        dm-devel@...hat.com, linux-ext4@...r.kernel.org,
        Ming Lei <ming.lei@...hat.com>
Subject: Re: [dm-devel] Processes hung in "D" state in ext4, mm, md and dmcrypt

On Wed, Jul 26, 2023 at 6:02 PM David Howells <dhowells@...hat.com> wrote:
>
> Hi,
>
> With 6.5-rc2 (6.5.0-0.rc2.20230721gitf7e3a1bafdea.20.fc39.x86_64), I'm seeing
> a bunch of processes getting stuck in the D state on my desktop after a few
> hours of reading email and compiling stuff.  It's happened every day this week
> so far and I managed to grab stack traces of the stuck processes this morning
> (see attached).
>
> There are two blockdevs involved below, /dev/md2 and /dev/md3.  md3 is a raid1
> array with two partitions with an ext4 partition on it.  md2 is similar but
> it's dm-crypted and ext4 is on top of that.
>
...

> ===117547===
>     PID TTY      STAT   TIME COMMAND
>  117547 ?        D      5:12 [kworker/u16:8+flush-9:3]
> [<0>] blk_mq_get_tag+0x11e/0x2b0
> [<0>] __blk_mq_alloc_requests+0x1bc/0x350
> [<0>] blk_mq_submit_bio+0x2c7/0x680
> [<0>] __submit_bio+0x8b/0x170
> [<0>] submit_bio_noacct_nocheck+0x159/0x370
> [<0>] __block_write_full_folio+0x1e1/0x400
> [<0>] writepage_cb+0x1a/0x70
> [<0>] write_cache_pages+0x144/0x3b0
> [<0>] do_writepages+0x164/0x1e0
> [<0>] __writeback_single_inode+0x3d/0x360
> [<0>] writeback_sb_inodes+0x1ed/0x4b0
> [<0>] __writeback_inodes_wb+0x4c/0xf0
> [<0>] wb_writeback+0x298/0x310
> [<0>] wb_workfn+0x35b/0x510
> [<0>] process_one_work+0x1de/0x3f0
> [<0>] worker_thread+0x51/0x390
> [<0>] kthread+0xe5/0x120
> [<0>] ret_from_fork+0x31/0x50
> [<0>] ret_from_fork_asm+0x1b/0x30

BTW, -rc3 fixes one similar issue on the above code path, so please try -rc3.

106397376c03 sbitmap: fix batching wakeup

Thanks,
Ming Lei