Re: [PATCH] Fix J1939 implementation not handling holds correctly

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

Hi thank you for your review!
I've sent another patch addressing all the points related to the first 
version of the patch.

On 5/6/26 15:21, Oleksij Rempel wrote:
> On Tue, May 05, 2026 at 12:18:33AM +0200, Alexander Hölzl wrote:
>> The J1939 protocol allows the receiver of directed segemented messages
>> to hold the data transfer. The kernel implementation did not handle hold
>> messages correctly was not able to resume from a hold.
>> Additionally the incorrect timeout for a held open connection was
>> changed to 1050ms.
>> Some simple tests for the general protocol behavior have been added.
>>
>> This is just an initial draft I'm just looking for some feedback
>> if the general setup is acceptable.
>>
>> Also I still have some points I'm not sure about.
>> 1. There is no check for the reception of a CTS during an ongoing data
>>     transfer. According to the standard it is illegal, but I dont think
>>     the implementation cares about it. J1939_XTP_ABORT_GENERIC is never
>>     referenced and the previous check I removed only really prevented
>>     consecutive CTS which are legal if they are holds. Should I add a
>>     check for this? This seems to be a slightly different problem so I
>>     did not address it.
> 
> Current I do not have opinion about this. As long as it is in a separate
> patch with enough explanation and tests - I'm OK.
Ok, I'll think about it and send a patch.>
>> 2. Should userspace be notified about holds? I don't think the standard
>>     gives a maximum 'hold open time' so in theory it could be held
>>     indefinetly. This might be a situation a user could be intrested in
>>     even though it is rather theoretical.
> 
> Yes, it will be good to have a user space feedback. But, it would block
> resources. Will we get difference scenarios where we still have an open
> session which is blocking other transfers?
> 
Hm I'm not quite sure if I understand your question, but a J1939 session 
is identified by source and destination address. A hold is only relevant 
for a single unicast session, so receiving hols will only block this 
specific session. As the kernel will never send holds itself this is 
only relevant for tx-sessions. So the only thing which could happen, is 
that a receiver prevents a unicast tx-session from completing by sending 
nonstop holds.
This should not impact other sessions but it will prevent this specific 
session from completing and therefore restarting another tx RTS/CTS 
session to the same destination.

The other points I addressed in the v2 patch.

...

> 
> Best Regards,
> Oleksij

Best Regards and have a nice weekend!

Alexander