Re: [PATCH bpf-next v8 3/6] locking/local_lock: Introduce localtry_lock_t

[Vlastimil Babka <vbabka@suse.cz>]

On 2/14/25 19:32, Alexei Starovoitov wrote:
>>         ({                                                      \
>>                 localtry_lock_t *lt;                            \
>> @@ -275,12 +293,10 @@ do {                                                              \
>>  #define __localtry_unlock_irq(lock)                    __local_unlock(lock)
>>  #define __localtry_unlock_irqrestore(lock, flags)      __local_unlock_irqrestore(lock, flags)
>>
>> -#define __localtry_trylock_irqsave(lock, flags)                        \
>> +#define __localtry_trylock(lock)                               \
>>         ({                                                      \
>>                 int __locked;                                   \
>>                                                                 \
>> -               typecheck(unsigned long, flags);                \
>> -               flags = 0;                                      \
>>                 if (in_nmi() | in_hardirq()) {                  \
>>                         __locked = 0;                           \
>>                 } else {                                        \
>> @@ -292,4 +308,11 @@ do {                                                               \
>>                 __locked;                                       \
>>         })
>>
>> +#define __localtry_trylock_irqsave(lock, flags)                        \
>> +       ({                                                      \
>> +               typecheck(unsigned long, flags);                \
>> +               flags = 0;                                      \
>> +               __localtry_trylock(lock);                       \
>> +       })
>> +
> 
> All makes sense to me.
> 
> Since respin is needed, I can fold the above fix/feature and
> push it into a branch with stable sha-s that we both can
> use as a base ?

I doubt sheaves will be included in 6.15 so it's fine enough for me if you
fold this and perhaps order the result as patch 1?

> Or you can push just this one patch into a stable branch and I can pull it
> and apply the rest on top.

Ideally we'd have PeterZ blessing before we get to stable commit id's...

Thanks.