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
| ||
|
Date: Mon, 2 May 2022 20:24:53 +0200 From: Andrew Lunn <andrew@...n.ch> To: Francesco Dolcini <francesco.dolcini@...adex.com> Cc: netdev@...r.kernel.org, Andy Duan <fugang.duan@....com>, Joakim Zhang <qiangqing.zhang@....com>, Heiner Kallweit <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>, Fabio Estevam <festevam@...il.com>, Tim Harvey <tharvey@...eworks.com>, Chris Healy <cphealy@...il.com> Subject: Re: FEC MDIO read timeout on linkup > writing to this register could trigger a FEC_ENET_MII interrupt actually > creating a race condition with fec_enet_mdio_read() that is called on > link change also. Another point to consider: static int fec_enet_mdio_wait(struct fec_enet_private *fep) { uint ievent; int ret; ret = readl_poll_timeout_atomic(fep->hwp + FEC_IEVENT, ievent, ievent & FEC_ENET_MII, 2, 30000); if (!ret) writel(FEC_ENET_MII, fep->hwp + FEC_IEVENT); return ret; } An unexpected interrupt will make this exit too early, and the read will get invalid data. An unexpected interrupt would not cause a timeout here, which is what you are reporting. Andrew
Powered by blists - more mailing lists