linux-kernel - Re: [PATCH] PCI/VGA: Make the vga_is_firmware

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: <20230804163811.GA144900@bhelgaas>
Date:   Fri, 4 Aug 2023 11:38:11 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     suijingfeng <suijingfeng@...ngson.cn>
Cc:     kernel test robot <lkp@...el.com>, linux-pci@...r.kernel.org,
        llvm@...ts.linux.dev, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, loongson-kernel@...ts.loongnix.cn,
        oe-kbuild-all@...ts.linux.dev, bhelgaas@...gle.com
Subject: Re: [PATCH] PCI/VGA: Make the vga_is_firmware_default()
 arch-independent

On Fri, Aug 04, 2023 at 11:11:12AM +0800, suijingfeng wrote:
> On 2023/8/3 20:25, kernel test robot wrote:
> > Hi Sui,
> > 
> > kernel test robot noticed the following build errors:
> > 
> > [auto build test ERROR on pci/next]
> > [also build test ERROR on pci/for-linus linus/master v6.5-rc4 next-20230803]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > 
> > url:    https://github.com/intel-lab-lkp/linux/commits/Sui-Jingfeng/PCI-VGA-Make-the-vga_is_firmware_default-arch-independent/20230803-161838
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
> > patch link:    https://lore.kernel.org/r/20230803081758.968742-1-suijingfeng%40loongson.cn
> > patch subject: [PATCH] PCI/VGA: Make the vga_is_firmware_default() arch-independent
> > config: arm64-randconfig-r026-20230731 (https://download.01.org/0day-ci/archive/20230803/202308032022.yiZngbbk-lkp@intel.com/config)
> > compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
> > reproduce: (https://download.01.org/0day-ci/archive/20230803/202308032022.yiZngbbk-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@...el.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202308032022.yiZngbbk-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> > > > ld.lld: error: undefined symbol: screen_info
> >     >>> referenced by vgaarb.c:86 (drivers/pci/vgaarb.c:86)
> >     >>>               drivers/pci/vgaarb.o:(vga_arb_firmware_fb_addr_tracker) in archive vmlinux.a
> >     >>> referenced by vgaarb.c:86 (drivers/pci/vgaarb.c:86)
> >     >>>               drivers/pci/vgaarb.o:(vga_arb_firmware_fb_addr_tracker) in archive vmlinux.a
> >     >>> referenced by vgaarb.c:88 (drivers/pci/vgaarb.c:88)
> >     >>>               drivers/pci/vgaarb.o:(vga_arb_firmware_fb_addr_tracker) in archive vmlinux.a
> >     >>> referenced 3 more times
> > 
> This is a more like arch-specific problem, It will be pain at many places on platforms
> that do not export the screen_info symbol. Not only here.
> 
> I have already explained that screen_info is arch-dependent many times, but no one cares about me.
> By using (looking at) screen_info, vgaarb gets infected, and becomes arch-dependent as well.
> vgaarb deals with VGA class (pdev->class == 0x0300XX) devices only, This makes it device-dependent.
> Hence, It only works correctly for a small set of PCIe devices on x86.

This build error report is from an automated service; there's nothing
personal about it and the automated service isn't going to respond to
you.

The build issue is just something that will have to be resolved before
we can consider merging the patch.

Any explanation needs to go in the commit logs for the relevant
patches.

> arch-dependent, device-dependent, subsystem-dependent (part of it rely on ACPI) and
> loading order dependent, those dependent itself are the problems.
> It results in various undefined (uncertain) behaviors on non-x86 architectures.
> 
> Even on x86, some platform choose to relay on the firmware to solve the multiple GPU coexist problem.
> so it is also firmware-dependent.
> 
> This patch solves part of the above problems listed, target at the *device level*, as early as possible.
> while they still a few problems could be only solved at the *driver level*.
> For an example, The display controller in Intel N2000 and d2000 series don't has a dedicated VRAM bar.
> they use the "stolen memory", which is carve out by somebody (either bios or kernel?).
> 
>