On 4/8/24 5:00 PM, Vlastimil Babka wrote:
> On 4/8/24 2:57 PM, Greg Kroah-Hartman wrote:
>> 6.8-stable review patch. If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Peter Collingbourne <pcc@xxxxxxxxxx>
>>
>> [ Upstream commit a6c1d9cb9a68bfa4512248419c4f4d880d19fe90 ]
>>
>> Commit 3ee34eabac2a ("lib/stackdepot: fix first entry having a 0-handle")
>> changed the meaning of the pool_index field to mean "the pool index plus
>> 1". This made the code accessing this field less self-documenting, as
>> well as causing debuggers such as drgn to not be able to easily remain
>> compatible with both old and new kernels, because they typically do that
>> by testing for presence of the new field. Because stackdepot is a
>> debugging tool, we should make sure that it is debugger friendly.
>> Therefore, give the field a different name to improve readability as well
>> as enabling debugger backwards compatibility.
>>
>> This is needed in 6.9, which would otherwise become an odd release with
>> the new semantics and old name so debuggers wouldn't recognize the new
>> semantics there.
>
> This got me curious so I did check what's going on, so mentioning the result
> here others don't need to repeat that.
>
>> Fixes: 3ee34eabac2a ("lib/stackdepot: fix first entry having a 0-handle")
>
> It's because this was backported to 6.8.2 despite:
>
>> This bug has been lurking since the very beginning of stackdepot, but no
>> one really cared as it seems. Because of that I am not adding a Fixes
>> tag.
Nevermind, it was backported as
Stable-dep-of: dc24559472a6 ("lib/stackdepot: off by one in
depot_fetch_stack()")
https://lore.kernel.org/all/20240324223455.1342824-513-sashal@xxxxxxxxxx/
