netdev - Re: [PATCH] Use a spinlock to guard `fep->ptp_clk

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]

Message-ID: <Yw+LUq3dii2q1FKQ@lunn.ch>
Date:   Wed, 31 Aug 2022 18:24:50 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Csókás Bence <csokas.bence@...lan.hu>
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 Wed, Aug 31, 2022 at 04:21:47PM +0200, Csókás Bence wrote:
> 
> 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.

checkpatch does not have the smarts to detect this. And it is a netdev
only thing.

> 
> > >   	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.

Those using real time will probably disagree.

There is also a different between not being able to sleep, and not
being able to process an interrupt for some other hardware. You got a
report about taking a mutex in atomic context. That just means you
cannot sleep, probably because a spinlock is held. That is very
different to not being able to handle interrupts. You only need
spin_lock_irqsave() if the interrupt handler also needs the same spin
lock to protect it from a thread using the spin lock.

     Andrew