Re: Weekly net upstream? - Re: [PATCH] vxcan: fix Kconfig description stating no local echo provided

Oliver Hartkopp <[email protected]> Thu, 16 Jul 2026 08:17:53 +0200
Newsgroups org.kernel.vger.linux-can
Message-ID <[email protected]>
Hi Marc,

just in the case you didn't see my (hopefully really) final bcm patch set:

https://lore.kernel.org/linux-can/[email protected]/

Best regards,
Oliver

On 14.07.26 12:01, Oliver Hartkopp wrote:
> 
> 
> On 14.07.26 10:51, Marc Kleine-Budde wrote:
>> On 14.07.2026 08:55:32, Oliver Hartkopp wrote:
>>> I would be glad if you could upstream this patch together with the now
>>> sashiko-approved fixes for can-bcm and can-isotp:
>>>
>>> https://lore.kernel.org/linux-can/20260712-isotp-fixes- 
>>> [email protected]/
>>
>> If I understand you correctly, you say that the issue sashiko claims to
>> be in patch 3 (mid:[email protected]):
>>
>>>> [High] Lockless state transition in the timeout handler creates a
>>>> race condition that causes timeout errors to be silently dropped or
>>>> misattributed, leading sendmsg() to erroneously return success for
>>>> timed-out transfers.
>>
>> is a preexisting problem?
> 
> Yes. Always broken for years but nobody ever complained as the pattern 
> that would lead to this problem is not used.
> 
> The core issues with concurrent execution UFA and probable stalls are 
> fixed within the patch set. Fixing the in rare cases wrong (and unused) 
> error attribution would be a huge effort.
> 
> So it would be something for can-next or wont-fix.
> 
>>
>>> https://lore.kernel.org/linux-can/20260709-bcm_fixes- 
>>> [email protected]/
>>
>> Can you clarify these claims:
>>
>> https://lore.kernel.org/all/[email protected]/
> 
> Fixed in patch 9.
> 
>> https://lore.kernel.org/all/[email protected]/
> 
> Oh, this was really an open point that I have overlooked.
> 
> Will send a V13 asap.
> 
> Best regards,
> Oliver
>