linux-kernel - Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"

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: <f8cbb12c-590b-28a3-e3e9-d3fb0d7e3c90@gmx.com>
Date:   Sat, 1 Oct 2022 10:47:55 +0000
From:   "Artem S. Tashkinov" <aros@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Thorsten Leemhuis <linux@...mhuis.info>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        workflows@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        ksummit@...ts.linux.dev
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"



On 10/1/22 10:39, Greg KH wrote:
> On Sat, Oct 01, 2022 at 10:30:22AM +0000, Artem S. Tashkinov wrote:
>> Here are two other issues which absolutely suck in terms of dealing with
>> the kernel.
>>
>> - 1 -
>>
>> I have a 20+ years experience in IT and some kernel issues are just
>> baffling in terms of trying to understand what to do about them.
>>
>> Here's an example: https://bugzilla.kernel.org/show_bug.cgi?id=216274
>>
>> What should I do about that? Who's responsible for this? Who should I CC?
>
> Input subsystem.

It's great you've replied immediately, what about hundreds or even
thousands of other bug reports where people have no clue who has to be
CC'ed?

>
>> Here's what I'm getting with Linux 5.19.12:
>>
>> platform wdat_wdt: failed to claim resource 5: [mem
>> 0x00000000-0xffffffff7fffffff]
>
> $ find . | grep wdat_wdt
> ./drivers/watchdog/wdat_wdt.c
> $ ./scripts/get_maintainer.pl --file ./drivers/watchdog/wdat_wdt.c
> Wim Van Sebroeck <wim@...ux-watchdog.org> (maintainer:WATCHDOG DEVICE DRIVERS)
> Guenter Roeck <linux@...ck-us.net> (maintainer:WATCHDOG DEVICE DRIVERS)
> linux-watchdog@...r.kernel.org (open list:WATCHDOG DEVICE DRIVERS)
> linux-kernel@...r.kernel.org (open list)
>
>> ACPI: watchdog: Device creation failed: -16
>> ACPI BIOS Error (bug): Could not resolve symbol
>> [\_SB.PCI0.XHC.RHUB.TPLD], AE_NOT_FOUND (20220331/psargs-330)
>> ACPI Error: Aborting method \_SB.UBTC.CR01._PLD due to previous error
>> (AE_NOT_FOUND) (20220331/psparse-529)
>
> Send to ACPI list as described in the MAINTAINERS file.

The more important question is whether I should even bother anyone in
the first place.

And it's not just ACPI, what about "platform wdat_wdt: failed to claim
resource 5", "platform MSFT0101:00: failed to claim resource 1",
"lis3lv02d: unknown sensor type 0x0"?

I know you can probably identify the related components in a few
seconds, but I'm quite sure you won't be doing that for every bug report.

Should this be addressed?

Best regards,
Artem