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] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 7 Jan 2020 19:08:42 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Matteo Ghidoni <matteo.ghidoni@...abb.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Li Yang <leoyang.li@....com>
Cc:     "sux@...lof.de" <sux@...lof.de>, linuxppc-dev@...ts.ozlabs.org
Subject: Re: Freescale network device not activated on mpc8360 (kmeter1 board)

On 07.01.2020 14:05, Matteo Ghidoni wrote:
>  Hi all,
> 
> With the introduction of the following patch, we are facing an issue with the activation of the Freescale network device (ucc_geth driver) on our kmeter1 board based on a MPC8360:

+Li as ucc_geth maintainer

Can you describe the symptoms of the issue?

> 
> commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c
> Author: Heiner Kallweit <hkallweit1@...il.com>
> Date:   Tue Sep 18 21:55:36 2018 +0200
> 
>     net: linkwatch: add check for netdevice being present to linkwatch_do_dev
> 
> Based on my observations, just before trying to activate the device through linkwatch_event, the controller wants to adjust the MAC configuration and in order to achieve this it detaches the device. This avoids the activation of the net device.
> 
It sounds a little bit odd to rely on an asynchronous linkwatch event here.
Can you give a call trace?

The driver is quite old and maybe some parts need to be improved. The referenced change is more than a year old
and I'm not aware of any other problem with it. So it seems the change isn't wrong.

> This is already happening with older versions (I checked with the v4.14.162) and also there the situation is the same, but without the additional check in the if condition the device is activated.
> 
> I am currently working with the v5.4.8 kernel version, but the behavior remains the same also with the latest v5.5-rc4.
> 
> Any idea how to solve this? Any help is appreciated.
> 
> Regards,
> Matteo
> 
Heiner

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ