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 :)
thanks,
greg k-h
