linux-kernel - Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to

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]

Date: Tue, 21 May 2024 16:26:32 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Linux regressions mailing list <regressions@...ts.linux.dev>,
 Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Laura Nao <laura.nao@...labora.com>, mika.westerberg@...ux.intel.com,
 linus.walleij@...aro.org, brgl@...ev.pl, kernel@...labora.com,
 linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
 linux-acpi@...r.kernel.org,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 "kernelci.org bot" <bot@...nelci.org>
Subject: Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to
 acpi_can_fallback_to_crs()

On 21.05.24 16:00, Andy Shevchenko wrote:
> On Tue, May 21, 2024 at 12:01:17PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 13.05.24 12:02, Andy Shevchenko wrote:
>>> On Mon, May 13, 2024 at 11:56:10AM +0200, Laura Nao wrote:
>>>> Following the relocation of the function call outside of
>>>> __acpi_find_gpio(), move the ACPI device NULL check to
>>>> acpi_can_fallback_to_crs().
>>>
>>> Thank you, I'll add this to my tree as we have already the release happened.
>>> I will be available after v6.10-rc1 is out.
>>
>> Hmm, what exactly do you mean with that? It sounds as you only want to
>> add this to the tree once -rc1 is out -- which seems likely at this
>> point, as that patch is not yet in -next. If that's the case allow me to
>> ask: why?
> 
> Because:
> 
> - that's the policy of Linux Next (do not include what's not supposed to be
>   merged during merge window), Cc'ed to Stephen to clarify, it might be that
>   I'm mistaken
> 
> - the process of how we maintain the branches is to have them based on top of
>   rc1 (rarely on other rcX and never on an arbitrary commit from vanilla

Something like that is what I feared. And yes, some of that is true. But
the patch in this thread contains a Fixes: tag for commit 49c02f6e901c
which was merged during this merge window -- and that patch thus ideally
should (ideally after some testing in -next) be merge during the merge
window as well, to ensure the problem does not even hit -rc1.

That's something a lot of subsystem master all the time. The scheduler
for example:

https://git.kernel.org/torvalds/c/6e5a0c30b616bfff6926ecca5d88e3d06e6bf79a
https://git.kernel.org/torvalds/c/8dde191aabba42e9c16c8d9c853a72a062db27ee

Other subsystems (perf, x86, net) do this, too. Not sure how they
exactly do that with git; I think some (most?) have a dedicated -fixes
branch (based on master and fast-forwarded after Linus merged from it)
for that is also included in next in parallel to their "for-next"
branch.  Stephen will know for sure.

Ciao, Thorsten