netdev - Re: [PATCH net 4/4] sh_eth: Fix serialisation of interrupt disable with interrupt & NAPI handlers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1421939177.1222.298.camel@xylophone.i.decadent.org.uk>
Date:	Thu, 22 Jan 2015 15:06:17 +0000
From:	Ben Hutchings <ben.hutchings@...ethink.co.uk>
To:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Cc:	"David S.Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-kernel@...ts.codethink.co.uk,
	Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@...esas.com>,
	Mitsuhiro Kimura <mitsuhiro.kimura.kc@...esas.com>,
	Hisashi Nakamura <hisashi.nakamura.ak@...esas.com>,
	Yoshihiro Kaneko <ykaneko0929@...il.com>
Subject: Re: [PATCH net 4/4] sh_eth: Fix serialisation of interrupt disable
 with interrupt & NAPI handlers

On Thu, 2015-01-22 at 16:50 +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 1/22/2015 3:44 PM, Ben Hutchings wrote:
> 
> > In order to stop the RX path accessing the RX ring while it's being
> > stopped or resized, we clear the interrupt mask (EESIPR) and then call
> > free_irq() or synchronise_irq().  This is insufficient because the
> > interrupt handler or NAPI poller may set EESIPR again after we clear
> > it.
> 
>     Hm, how come the interrupt handler gets called when we have disabled all 
> interrupts?

It may be running on another processor and racing with the function that
clears EESIPR.

> Is it unmaskable EESR.ECI interrupt? BTW, I'm not seeing where the 
> interrupt handler enables interrupts again; only NAPI poller does that AFAIK.

Normally it only clears EESR_RX_CHECK, but as it cannot atomically clear
a single bit of EESIPR this can result in setting other bits.

> > Also, in sh_eth_set_ringparam() we currently don't disable NAPI
> > polling at all.
> 
> > I could easily trigger a crash by running the loop:
> 
> >     while ethtool -G eth0 rx 128 && ethtool -G eth0 rx 64; do echo -n .; done
> 
>     Oh, never done any 'ethtool' tests...

You should also be able to trigger this by bringing the device up and
down, but you have to wait for the PHY to bring the link up before any
packets will be received in between.  Thus each cycle takes longer.

[...]
> > diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
> > index 7bfaf1c..259d03f 100644
> > --- a/drivers/net/ethernet/renesas/sh_eth.h
> > +++ b/drivers/net/ethernet/renesas/sh_eth.h
> > @@ -513,6 +513,7 @@ struct sh_eth_private {
> >   	u32 rx_buf_sz;			/* Based on MTU+slack. */
> >   	int edmac_endian;
> >   	struct napi_struct napi;
> > +	bool irq_enabled;
> >   	/* MII transceiver section. */
> >   	u32 phy_id;			/* PHY ID */
> >   	struct mii_bus *mii_bus;	/* MDIO bus control */
> 
>     In order to conserve space, I'd have added that field after 
> 'vlan_num_ids', just before the 1-bit fields...

I don't think it's worth micro-optimising the size of a per-device
structure.

Ben.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html