Linux >= 4.2 dm_any_congested bug due to bad data from vfs/mm? [was: Bug in dm_any_congested?]

From: Mike Snitzer
Date: Tue Nov 10 2015 - 12:27:48 EST

[Cc'ing LKML and linux-fsdevel to cast a wider net and raise awareness]

On Tue, Nov 10 2015 at 10:02am -0500,
BoÅtjan Åkufca @ <bostjan@xxxxxxx> wrote:

> On 10 November 2015 at 15:39, Zdenek Kabelac <zkabelac@xxxxxxxxxx> wrote:
> > Dne 10.11.2015 v 14:14 BoÅtjan Åkufca @ napsal(a):
> >>
> >> Hi all,
> >>
> >> HW is a bit dated, but had no problems with it up to now, and SW raid
> >> is used here. Kernel was 4.2.4.
> >>
> >> Is this the right mlist for such bug?
> >
> >
> > Hi
> >
> > Yes the issue is known - but source is not fully known.
> > I've opened public BZ:
> > There is some potential fix - but unclear what it solves:
> >
> So 4.1.13 is ok in this respect, or is this unknown ATM?
> Does it depend on underlying storage at all, or not? MD does not seem
> to be listed in stack trace.

We don't yet have a reliable reproducer. So if your test proves to
reliably reproduce the issue for you then we may be able to make much
quicker progress.

While the bug manifests as a crash in dm_any_congested (either NULL
pointer or GPF) it _seems_ that the problem is further up the stack in
the vfs and/or mm (by passing garbage into dm_any_congested via call to
queue->backing_dev_info.congested_fn). But all possibilities are still
on the table... again not much to go on yet.

Please feel free to test using the 4.4 stable@ commit Zdenek referenced
(but I'm skeptical it'll fix this issue if you aren't reactivating
volumes or anything):

Also, you're welcome to update this BZ as you collect additional info:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at