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
| ||
|
Message-ID: <79e46d59-436c-ca82-cad4-15c3cb13b1cf@prolan.hu> Date: Wed, 31 Aug 2022 16:21:47 +0200 From: Csókás Bence <csokas.bence@...lan.hu> To: Andrew Lunn <andrew@...n.ch> CC: <netdev@...r.kernel.org>, Richard Cochran <richardcochran@...il.com>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, <kernel@...gutronix.de>, Marc Kleine-Budde <mkl@...gutronix.de> Subject: Re: [PATCH] Use a spinlock to guard `fep->ptp_clk_on` On 2022. 08. 31. 16:03, Andrew Lunn wrote: >> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c >> index b0d60f898249..98d8f8d6034e 100644 >> --- a/drivers/net/ethernet/freescale/fec_main.c >> +++ b/drivers/net/ethernet/freescale/fec_main.c >> @@ -2029,6 +2029,7 @@ static int fec_enet_clk_enable(struct net_device *ndev, bool enable) >> { >> struct fec_enet_private *fep = netdev_priv(ndev); >> int ret; >> + unsigned long flags; > > Please keep to reverse christmas tree checkpatch didn't tell me that was a requirement... Easy to fix though. > >> if (enable) { >> ret = clk_prepare_enable(fep->clk_enet_out); >> @@ -2036,15 +2037,15 @@ static int fec_enet_clk_enable(struct net_device *ndev, bool enable) >> return ret; >> >> if (fep->clk_ptp) { >> - mutex_lock(&fep->ptp_clk_mutex); >> + spin_lock_irqsave(&fep->ptp_clk_lock, flags); > > Is the ptp hardware accessed in interrupt context? If not, you can use > a plain spinlock, not _irqsave.. `fec_suspend()` calls `fec_enet_clk_enable()`, which may be a non-preemptible context, I'm not sure how the PM subsystem's internals work... Besides, with the way this driver is built, function call dependencies all over the place, I think it's better safe than sorry. I don't think there is any disadvantage (besides maybe a few lost cycles) of using _irqsave in regular process context anyways. Bence
Powered by blists - more mailing lists