Re: [PATCH] can: j1939: fix potential race condition in BAM segmentation

["Hölzl, Alexander" <alexander.hoelzl@gmx.net>]

Hello,
Am 01.10.2026 um 12:57 schrieb Marc Kleine-Budde:
> On 01.10.2026 12:42:21, Markus Koeniger wrote:
>> I really appreciate your solution to schedule the TX timer for a BAM
>> transfer after receiving the looped-back frame.
>
Glad that I could help.

>> We use external CAN controllers in our system, which introduce some
>> jitter into the transmit path. As a result, messages were sent from
>> time to time too quickly and violated the 50 ms minimum interval. Your
>> patch solves this problem.
>>
>> Tested-by: Markus Koeniger markus.koeniger@liebherr.com
> 
> Thanks for testing, however I'm not sure if we can get this patch
> upstream if sashiko complains about it.
>
I wasn't planning on letting this patch stall. Next week I'll try to 
address sashiko comment's as well as the other patch I still have open.

Additionally while I'm at it I just wanted to ask, is it intended 
behavior that the kernel implementation strictly serializes all J1939 
sessions. E.g when sending a segmented message directed to destination 
address A it is not possible to have a second session open targeting 
destination address B. According to the standard this is allowed and not
being able to do so can result in very low performance in some 
use-cases. This especially true if one of the sessions is a BAM session 
transmitting a longer message, as there are 50ms pauses between each frame.

> regards,
> Marc
> 

regards,
Alexander