lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 1 Mar 2021 18:38:03 +0100 (CET)
From:   Dario Binacchi <dariobin@...ero.it>
To:     Marc Kleine-Budde <mkl@...gutronix.de>
Cc:     linux-kernel@...r.kernel.org,
        Federico Vaga <federico.vaga@...il.com>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        Vincent Mailhol <mailhol.vincent@...adoo.fr>,
        YueHaibing <yuehaibing@...wei.com>,
        Zhang Qilong <zhangqilong3@...wei.com>,
        linux-can@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v2 3/6] can: c_can: fix control interface used by
 c_can_do_tx


> Il 01/03/2021 12:36 Marc Kleine-Budde <mkl@...gutronix.de> ha scritto:
> 
>  
> On 28.02.2021 11:35:31, Dario Binacchi wrote:
> > > On 25.02.2021 22:51:52, Dario Binacchi wrote:
> > > > According to commit 640916db2bf7 ("can: c_can: Make it SMP safe") let RX use
> > > > IF1 (i.e. IF_RX) and TX use IF2 (i.e. IF_TX).
> > > 
> > > Is this a fix?
> > > 
> > 
> > I think that If I consider what is described in the 640916db2bf7
> > commit, using the IF_RX interface in a tx routine is wrong.
> 
> Yes, IF_RX is used in c_can_do_tx(), but that's called from
> c_can_poll(), which runs ins NAPI.

Yes, you are right. I was misled by the name of the function.

> 
> As far as I understand 640916db2bf7 ("can: c_can: Make it SMP safe")
> fixes the race condition that c_can_poll() and c_can_start_xmit() both
> access the same IF. See again the patch description:
> 
> | The hardware has two message control interfaces, but the code only uses the
> | first one. So on SMP the following can be observed:
> | 
> | CPU0            CPU1
> | rx_poll()
> |   write IF1     xmit()
> |                 write IF1
> |   write IF1
> 
> It's not 100% accurate, as the race condition is not just
> c_can_do_rx_poll() against the c_can_start_xmit(), but the whole
> c_can_poll() against c_can_start_xmit().
> 
> If you think my analysis is correct, please update the patch and add a
> comment to clarify why IF_RX is used instead of changing it to IF_TX.

I agree with you, I'll do it.

Thanks and regards,
Dario

> 
> regards,
> Marc
> 
> -- 
> Pengutronix e.K.                 | Marc Kleine-Budde           |
> Embedded Linux                   | https://www.pengutronix.de  |
> Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ