Re: linux-next: Boot hangs 3 minutes with device mapper on s390

[Mike Snitzer <snitzer@redhat.com>]

On Fri, Mar 01 2019 at  3:19pm -0500,
Mikulas Patocka <mpatocka@redhat.com> wrote:

> 
> 
> On Fri, 1 Mar 2019, Michael Holzheu wrote:
> 
> > Hi Mike,
> > 
> > On Fedora 29, the following "linux-next" commit introduced a regression on s390:
> > 
> >   commit 1efa3bb79d3de8ca1b7f6770313a1fc0bebe25c7
> >   Author: Mike Snitzer <snitzer@redhat.com>
> >   Date:   Fri Feb 22 11:23:01 2019 -0500
> > 
> >     dm: must allocate dm_noclone for stacked noclone devices
> >     
> >     Otherwise various lvm2 testsuite tests fail because the lower layers of
> >     the stacked noclone device aren't updated to allocate a new 'struct
> >     dm_clone' that reflects the upper layer bio that was issued to it.
> >     
> >     Fixes: 97a89458020b38 ("dm: improve noclone bio support")
> >     Reported-by: Mikulas Patocka <mpatocka@redhat.com>
> >     Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> 
> Should we just drop 97a89458020b388b910160c4f4aa5e24318d2460 and 
> 1efa3bb79d3de8ca1b7f6770313a1fc0bebe25c7?

No.

> 97a89458020b388b910160c4f4aa5e24318d2460 claims to be an improvement, but 
> it broke the tests twice.

This report from Michael needs proper review and triage.

It literally makes _zero_ sense that all 5 mpath devices are suffering
from a 3 minute boot stall (rooted in udev action) when I'm pretty
certain they are using request-based multipath for 4 of the 5 devices.
The 5th likely having a dm-linear ontop of request-based multipath.
And I've tested stacking bio-based linear on request-based multipath.

Mike