[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6f541d66-f52e-13e0-bfe9-91918af11503@hartkopp.net>
Date: Wed, 11 May 2022 15:24:00 +0200
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>,
Wolfgang Grandegger <wg@...ndegger.com>,
Devid Antonio Filoni <devid.filoni@...uetechnologies.com>,
kernel@...gutronix.de, linux-can@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
David Jander <david@...tonic.nl>
Subject: Re: [PATCH 1/1] can: skb: add and set local_origin flag
On 5/11/22 15:05, Marc Kleine-Budde wrote:
> On 11.05.2022 14:38:32, Oliver Hartkopp wrote:
>> I'm a bit unsure why we should not stick with the simple skb->sk
>> handling?
>
> Another use where skb->sk breaks is sending CAN frames with SO_TXTIME
> with the sched_etf.
>
> I have a patched version of cangen that uses SO_TXTIME. It attaches a
> time to transmit to a CAN frame when sending it. If you send 10 frames,
> each 100ms after the other and then exit the program, the first CAN
> frames show up as TX'ed while the others (after closing the socket) show
> up as RX'ed CAN frames in candump.
Hm, this could be an argument for the origin flag.
But I'm more scared about your described behaviour. What happens if the
socket is still open?
There obviously must be some instance removing the sk reference, right??
Regards,
Oliver
Powered by blists - more mailing lists