On Wed, Jun 24, 2020 at 01:11:54PM +0200, Christian Borntraeger wrote: > > > On 23.06.20 16:23, Christian Borntraeger wrote: > > > > > > On 23.06.20 16:11, Christian Borntraeger wrote: > >> Jens Markwardt reported a regression in the linux-next runs. with "umh: fix > >> processed error when UMH_WAIT_PROC is used" (from linux-next) a linux bridge > >> with an KVM guests no longer activates : > >> > >> without patch > >> # ip addr show dev virbr1 > >> 6: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 > >> link/ether 52:54:00:1e:3f:c0 brd ff:ff:ff:ff:ff:ff > >> inet 192.168.254.254/24 brd 192.168.254.255 scope global virbr1 > >> valid_lft forever preferred_lft forever > >> > >> with this patch the bridge stays DOWN with NO-CARRIER > >> > >> # ip addr show dev virbr1 > >> 6: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 > >> link/ether 52:54:00:1e:3f:c0 brd ff:ff:ff:ff:ff:ff > >> inet 192.168.254.254/24 brd 192.168.254.255 scope global virbr1 > >> valid_lft forever preferred_lft forever > >> > >> This was bisected in linux-next. Reverting from linux-next also fixes the issue. > >> > >> Any idea? > > > > FWIW, s390 is big endian. Maybe some of the shifts inn the __KW* macros are wrong. > > Does anyone have an idea why "umh: fix processed error when UMH_WAIT_PROC is used" breaks the > linux-bridge on s390? glibc for instance defines __WEXITSTATUS in only one location: bits/waitstatus.h and it does not special case it per architecture, so at this point I'd have to say we have to look somewhere else for why this is happening. The commmit which caused this is issuing a correct error code down the pipeline, nothing more. I'll make taking a look at this a priority right now. Let us see what I come up with today. Luis
