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

[Hölzl, Alexander]

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@xxxxxxxxxxxx
> > >
> > > 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.