On Wed, Nov 06, 2019 at 02:29:29PM +0100, Clément VIEL wrote: > Hi Oleksij > > > > Hi Clément, > > > > On Wed, Nov 06, 2019 at 10:32:48AM +0100, Clément VIEL wrote: > > > Hi all, > > > > > > I am currently using a very old version of the j1939 stack. It was > > > forked in 2014 and now running on a custom 3.10.17 kernel. We are > > > experiencing a lot of synchronization problem that cause kernel > > > panics. > > > Doing diffs with the mainline version shows that the whole stack has > > > changed a lot, I noticed, this first mail concerning j1939 on this > > > mailing list is from 2018. > > > My question is very simple. Did synchronization problems were > > > encountered and corrected before the j1939 entered the mainline ? > > > > What do you mean with synchronization problem? Do you have a tests case > > for your issue? > > By synchronization I mean that in the old version of j1939 it seems > that the some functions > and pointers are not fully protected by locks whereas in the mainline > version it seems that there are more > locking. > > I give you an example. In the mainline version, there is a function > named j1939_ecu_get_by_name that calls ecu_find_by_name_locked > whereas in our version there just a function named j1939_ecu_find_by_name. > > In the mailine, there is a lot of lock protection that lacks in our version. > > I do not have test case because its a client that feeds us with these > kernel panics and they cannot tell what manipulation they did. > > I hope its more clear now. In the latest stack the resource management was mostly reworked. In my tests setups I was not able to reproduce any j1939_ecu_find_by_name related issues any more. On other hand google started to tests this stack with syzbot and found lots new bugs. In any case, I would recommend you to update the kernel. Some fixed issues were not directly in j1939. Drivers and CAN framework need fixes as well. UAPI was changed and you application will need some rework. Since this UAPI is upstream now, we should keep it compatible with coming kernel versions. So, you should be safe now by using it. Regards, Oleksij -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
