On Fri, Nov 24, 2023 at 04:11:35PM +0000, Greg Kroah-Hartman wrote: > On Wed, Nov 22, 2023 at 10:36:23AM -0300, Luis Claudio R. Goncalves wrote: > > On Tue, Nov 21, 2023 at 10:01:25PM -0300, Luis Claudio R. Goncalves wrote: > > > Hello RT-list! > > > > > > I'm pleased to announce the 5.10.201-rt98 stable release. > > > > > > This release is just an update to the new stable 5.10.201 > > > version and no RT changes have been made. > > > > > > You can get this release via the git tree at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > > > > branch: v5.10-rt > > > Head SHA1: 3a93f0a0d49dd0db4c6876ca9a7369350e64320e > > > > Greg KH, > > > > While testing v5.10.201-rt98 I stumbled over this warning: > > > > [ 1000.312397] run blktests nvme/005 at 2023-11-21 21:46:30 > > ... > > [ 1000.500478] workqueue: WQ_MEM_RECLAIM nvmet_tcp_wq:nvmet_tcp_io_work [nvmet_tcp] is flushing !WQ_MEM_RECLAIM events:0x0 > > [ 1000.500490] WARNING: CPU: 0 PID: 6 at kernel/workqueue.c:2620 check_flush_dependency+0x11f/0x140 > > > > That seems to be fixed by: > > > > 533d2e8b4d5e4 nvmet-tcp: fix lockdep complaint on nvmet_tcp_wq flush during queue teardown > > (and depending on what else is backported) > > ddd2b8de9f85b nvmet: fix workqueue MEM_RECLAIM flushing dependency > > > > Is this something that can be added to your v5.10 queue or should I carry > > this fix on v5.10-rt in the meantime? > > That's odd, as this commit is already in the 5.10.138 release, so how > can we apply it again? I am really sorry for the confusion on my side. Either myself of the CI I used mixed up the test branches and ended up using older code. And I missed that when reviewing the results. > confused, Sorry again. I owe you a (root?) beer next LPC. > greg k-h Best regards, Luis
