linux-kernel - Re: drivers/gpu/drm/bridge/samsung-dsim.c link error

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] [day] [month] [year] [list]

Message-ID: <CANp29Y6_VcgQAHERdaXUqBZahfFkJ=ksvjVVeMkZz88Xxjz1jw@mail.gmail.com>
Date:   Fri, 4 Aug 2023 12:19:44 +0200
From:   Aleksandr Nogikh <nogikh@...gle.com>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     Adam Ford <aford173@...il.com>, l.stach@...gutronix.de,
        inki.dae@...sung.com, jagan@...rulasolutions.com,
        m.szyprowski@...sung.com, airlied@...il.com, daniel@...ll.ch,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        syzkaller@...glegroups.com, dvyukov@...gle.com
Subject: Re: drivers/gpu/drm/bridge/samsung-dsim.c link error

On Fri, Aug 4, 2023 at 4:47 AM Randy Dunlap <rdunlap@...radead.org> wrote:
>
> On 8/3/23 19:42, Adam Ford wrote:
> > On Thu, Aug 3, 2023 at 9:37 PM Randy Dunlap <rdunlap@...radead.org> wrote:
> >>
> >> On 8/3/23 19:26, Adam Ford wrote:
> >>> Where/how was the .config generated?
> >>>
> >>
> >> Aleksandr posted a link to the config file above.
> >
> > I get that, but I am not sure how this was generated.
> >
>
> Nor am I. Alexsandr can hopefully tell us.

We take a defconfig and apply a number of modifications on top of it
(*). Some configs are enabled (e.g. various sanitizers), some are
disabled (e.g. a number of heavy subsystems are disabled for instances
that run on qemu w/o hardware acceleration).

We rely heavily on olddefconfig to detect inconsistencies during
config generation (we regenerate them manually once in a while and the
tool makes sure our changes do not contradict KConfigs) and to
automatically correct inconsistencies when a kernel is being
(re-)built (there's no other way -- something constantly changes in
the mainline tree and it's impossible to keep track of it all
manually).

In this particular case, we indeed disabled CONFIG_GENERIC_PHY, but
left other dependent configs enabled and `make olddefconfig` could
unfortunately neither help us detect the problem nor resolve it during
the build :(

(*) FWIW here's a doc for reference:
https://github.com/google/syzkaller/blob/master/dashboard/config/linux/README.md

>
> >>
> >>> Are you building linux-next or something else?  The .config file
> >>> generated when I build the arm64 defconfig  show both enabled:
> >>
> >> linux-next.
> >>
> >>
> >>> $ grep GENERIC_PHY .config
> >>> CONFIG_GENERIC_PHY=y
> >>> CONFIG_GENERIC_PHY_MIPI_DPHY=y
> >>>
> >>
> >> Yes, this is not a defconfig file.
> >
> > I know, but it is a .config file that is generated from make defconfig
> > ARCH=arm64
> >>
>
> Not necessarily. It could be generated by 'make randconfig'.
>
> >>>
> >>>> but yes, selecting GENERIC_PHY (needed in 3 places) does fix the warnings
> >>>> and build error.  2 instance in drm/bridge/Kconfig and one in
> >>>> drm/bridge/cadence/Kconfig (found by inspection).
> >>>>
> >>>> I had no problem replicating the kconfig warnings and build error.
> >>>
> >>> If you can replicate the problem, I'd suggest submitting a patch.
> >>
> >> Sure, I'll do that.
> >
> > Great!  thanks.

I see the patch has already been sent. Thank you very much!

> >
> > adam
> >>
> >> --
> >> ~Randy
>
> --
> ~Randy