linux-kernel - Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin

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: <878s1qer35.wl-maz@kernel.org>
Date:   Wed, 28 Jul 2021 10:16:14 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Guillaume Tucker <guillaume.tucker@...labora.com>
Cc:     Robin Murphy <robin.murphy@....com>, kernelci-results@...ups.io,
        Johan Jonker <jbx6244@...il.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Maciej Matuszczyk <maccraft123mc@...il.com>,
        Jacob Chen <jacob2.chen@...k-chips.com>,
        Sandy Huang <hjc@...k-chips.com>, linux-kernel@...r.kernel.org,
        Chen-Yu Tsai <wens@...e.org>,
        Cameron Nemo <cnemo@...anota.com>, devicetree@...r.kernel.org,
        Elaine Zhang <zhangqing@...k-chips.com>,
        Helen Koike <helen.koike@...labora.com>,
        Shunqian Zheng <zhengsq@...k-chips.com>,
        Ezequiel Garcia <ezequiel@...labora.com>,
        Rob Herring <robh+dt@...nel.org>,
        Yifeng Zhao <yifeng.zhao@...k-chips.com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org,
        Collabora Kernel ML <kernel@...labora.com>
Subject: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin

On Wed, 28 Jul 2021 09:59:49 +0100,
Guillaume Tucker <guillaume.tucker@...labora.com> wrote:
> 
> On 28/07/2021 09:39, Robin Murphy wrote:
> > Hi Guillaume,
> > 
> > Not sure what I did to get CC'd on this, but since I'm here...
> 
> You were listed by get_maintainer.pl for the patch found by the
> bisection:
> 
>   Robin Murphy <robin.murphy@....com> (authored:1/8=12%,added_lines:9/71=13%,removed_lines:16/41=39%,added_lines:11/45=24%,removed_lines:18/32=56%,authored:1/12=8%,added_lines:22/83=27%,removed_lines:29/69=42%)
> 
> Maybe the logic to automatically build the list of recipients
> could look at those stats and apply some threshold if too many
> people get listed because of small contributions to some files.
> It's not a common issue though, usually the recipients are all
> pretty relevant.
> 
> > On 2021-07-28 07:04, Guillaume Tucker wrote:
> >> Please see the bisection report below about usb2phy failing to
> >> probe on rk3399-gru-kevin.
> >>
> >> Reports aren't automatically sent to the public while we're
> >> trialing new bisection features on kernelci.org but this one
> >> looks valid.
> >>
> >> The bisection was run in the Renesas tree but the same regression
> >> is present in mainline for both usb2phy0 and usb2phy1 devices:
> >>
> >>    https://linux.kernelci.org/test/plan/id/6100af012344eef9b85018f3/
> >>    https://linux.kernelci.org/test/case/id/6100af012344eef9b85018fa/
> >>
> >> I don't see any errors in the logs, it looks like the driver is
> >> just not probing.
> > 
> > What's the actual testcase for "rockchip-usb2phy0-probed"? If it's looking for a hard-coded path like "/sys/bus/platform/devices/ff770000.syscon:usb2-phy@...0/driver" then it can be expected to fail, since changing the node name is reflected in the device name.
> 
> Dang, you're right.  This is the test case:
> 
>   https://github.com/kernelci/bootrr/blob/main/boards/google%2Ckevin#L119
> 
> assert_driver_present rockchip-usb2phy-driver-present rockchip-usb2phy
> assert_device_present rockchip-usb2phy0-probed rockchip-usb2phy ff770000.syscon:usb2-phy@...0
> assert_device_present rockchip-usb2phy1-probed rockchip-usb2phy ff770000.syscon:usb2-phy@...0
> 
> Now that needs a conditional depending on the kernel version.  Or
> we could try to make it more dynamic rather than with hard-coded
> paths, but doing that has its own set of issues too.

And this shows once more that DT churn has consequences: it breaks a
userspace ABI. Changing userspace visible paths for the sake of
keeping a build-time checker quiet seems counter-productive. My
preference would be to just revert this patch, and instead have an
annotation acknowledging the deviation from the 'standard' and keeping
the checker at bay.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.