Hi Oleksij, On Tue, 2022-05-10 at 06:34 +0200, Oleksij Rempel wrote: > Hi Devid, > > On Mon, May 09, 2022 at 07:07:44PM +0200, Devid Antonio Filoni wrote: > > Hello, > > > > If candump -x is used to dump CAN bus traffic on an interface while a J1939 > > socket is sending multi-packet messages, then the DAT and CTL frames > > show up as RX instead of TX. > > > > This patch series sets to generated struct sk_buff the owning struct sock > > pointer so that the MSG_DONTROUTE flag can be set by recv functions. > > > > I'm not sure that j1939_session_skb_get is needed, I think that session->sk > > could be directly passed as can_skb_set_owner parameter. This patch > > is based on j1939_simple_txnext function which uses j1939_session_skb_get. > > I can provide an additional patch to remove the calls to > > j1939_session_skb_get function if you think they are not needed. > > Thank you for your patches. By testing it I noticed that there is a memory > leak in current kernel and it seems to be even worse after this patches. > Found by this test: > https://github.com/linux-can/can-tests/blob/master/j1939/run_all.sh#L13 > > > Can you please investigate it (or wait until I get time to do it). > > Regards, > Oleksij > I checked the test you linked and I can see that the number of the instances of the can_j1939 module increases on each j1939_ac_100k_dual_can.sh test execution (then the script exits), however this doesn't seem to be worse with my patches, I have the same results with the original kernel. Did you execute a particular test to verify that the memory leak is worse with my patches? I tried to take a look at all code that I changed in my patches but the used ref counters seem to be handled correctly in called functions. I suspected that the issue may be caused by the ref counter increased in can_skb_set_owner() function but, even if I remove that call from the j1939_simple_txnext() function in original kernel, I can still reproduce the memory leak. I think the issue is somewhere else, I'll try to give another look but I can't assure nothing. Best Regards, Devid
