NAK: ACK/Cmnt: [SRU][J, F:linux-bluefield][PATCH 0/1] Stop allowing RCU_SOFTIRQ in idle

[Bodong Wang]

Hi Tim,

I'm totally lost on how to have this submitted.

Stefan told me it should be submitted like below:

[SRU J,F:linux-bluefield][PATCH 0/1] ...
+- [SRU J:linux-bluefield][PATCH 1/1] ...
+- [SRU F:linux-bluefield][PATCH 1/1] ...

I'm not sure how could one cover letter has two patch 1/1. Why can't we just apply the patch directly with each repo? Also, note that, same patch has conflict on F but not on J.

-----Original Message-----
From: Tim Gardner <tim.gardner at canonical.com> 
Sent: Thursday, December 8, 2022 1:43 PM
To: Bodong Wang <bodong at nvidia.com>; kernel-team at lists.ubuntu.com
Cc: Vladimir Sokolovsky <vlad at nvidia.com>
Subject: NAK: ACK/Cmnt: [SRU][J, F:linux-bluefield][PATCH 0/1] Stop allowing RCU_SOFTIRQ in idle

On 12/8/22 12:40 PM, Tim Gardner wrote:
> On 12/7/22 2:29 PM, Bodong Wang wrote:
>> RCU_SOFTIRQ used to be special in that it could be raised on purpose 
>> within the idle path to prevent from stopping the tick. Some code 
>> still prevents from unnecessary warnings related to this specific 
>> behaviour while entering in dynticks-idle mode.
>>
>> However the nohz layout has changed quite a bit in ten years, and the 
>> removal of CONFIG_RCU_FAST_NO_HZ has been the final straw to this 
>> safe-conduct. Now the RCU_SOFTIRQ vector is expected to be raised 
>> from sane places.
>>
>> This patch is applicable for both J and F.
>>
>> Frederic Weisbecker (1):
>>    tick/rcu: Stop allowing RCU_SOFTIRQ in idle
>>
>>   include/linux/interrupt.h |  8 ++++++-
>>   kernel/time/tick-sched.c  | 50 
>> +++++++++++++++++++++++++++++++--------
>>   2 files changed, 47 insertions(+), 11 deletions(-)
>>
> Acked-by: Tim Gardner <tim.gardner at canonical.com>
> 
> I'll assume that '[SRU][F:linux-bluefield][PATCH 1/1]' applies to 
> Jammy as well, as is implied by '[SRU][J, F:linux-bluefield][PATCH 0/1]' ?
> 

Never mind, I see that the Jammy patch is outside this email tread. 
Please resubmit while making sure both patches are in the same thread. 
Otherwise managing patch states becomes quite tedious.

--
-----------
Tim Gardner
Canonical, Inc