On 8/10/23 7:41 AM, Greg KH wrote:
> On Thu, Aug 10, 2023 at 07:18:27AM -0600, Jens Axboe wrote:
>> On 8/9/23 10:53 PM, Greg KH wrote:
>>> On Wed, Aug 09, 2023 at 04:08:52PM -0600, Jens Axboe wrote:
>>>> On 8/9/23 6:56 AM, Sweet Tea Dorminy wrote:
>>>>> blk_crypto_profile_init() calls lockdep_register_key(), which warns and
>>>>> does not register if the provided memory is a static object.
>>>>> blk-crypto-fallback currently has a static blk_crypto_profile and calls
>>>>> blk_crypto_profile_init() thereupon, resulting in the warning and
>>>>> failure to register.
>>>>>
>>>>> Fortunately it is simple enough to use a dynamically allocated profile
>>>>> and make lockdep function correctly.
>>>>>
>>>>> Fixes: 2fb48d88e77f ("blk-crypto: use dynamic lock class for blk_crypto_profile::lock")
>>>>> Cc: stable@xxxxxxxxxxxxxxx
>>>>> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx>
>>>>
>>>> The offending commit went into 6.5, so there should be no need for a
>>>> stable tag on this one. But I can edit that while applying, waiting on
>>>> Eric to ack it.
>>>
>>> That commit has been backported to stable releases, so it would be nice
>>> to keep it there so our tools automatically pick it up properly. Once
>>> the authorship name is fixed up of course.
>>
>> But that stable tag should not be necessary? If stable has backported a
>> commit, surely it'll pick a commit that has that in Fixes? Otherwise
>> that seems broken and implies that people need to potentially check
>> every commit for a stable presence.
>>
>> I can keep the tag, just a bit puzzled as to why that would be
>> necessary.
>
> It's not necessary, no, our scripts will pick it out and get it merged
> eventually. But if you know it's needed to start with, it's always nice
> to add it if possible, saves me the extra work :)
OK, makes sense.
--
Jens Axboe
