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

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

Am 01.10.2026 um 13:37 schrieb Oleksij Rempel:
> Hi,
> 
> On Thu, Oct 01, 2026 at 01:18:27PM +0200, Hölzl, Alexander wrote:
>> 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.
> 
> Nice, thx.
> 
> I'm working right now on  j1939 selftests for core functionality. Hope
> it will be ready this week. If not, next week i'll be in Prag on E-OSS
> conference...
> 
Ah that's good to know. In the CTS hold patch  I've also implemented 
some tests (https://lkml.org/lkml/2026/7/7/85) but I guess they'll 
mostly be superfluous then?>> 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.
> 
> Is it not working with a separate socket? If I remember it correctly,
> this behavior should be supported if two sockets send to separate
> addresses. Withing one socket, frames should be serialized.
> 
I've never tried it with multiple sockets but if you say so I'm sure 
it'll work :). For my use case specifically this quite inconvenient 
behavior but I guess I might be abusing the stack a little bit :).
I've written a patch which allows interleaved tx-sessions per socket but 
if the kernel behaves as designed then that's probably not something 
which I should try to get into the mainline.