netdev - Re: [RFC] dev->refcnt long term holder

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, 17 Nov 2009 00:30:19 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	shemminger@...tta.com, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org
Subject: Re: [RFC] dev->refcnt long term holder

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Mon, 16 Nov 2009 20:54:29 +0100

> I was hoping a fast path, but anyway, a linkwatch_forget_dev(dev) is
> probably better, (in case "ip link del" closely follows an "ip link
> add / up")
> 
> I'll post something when tested.

Let's face it, linkwatch has been a thorn in our sides for a long
time.  A non-stop source of problems.

I suspect that here in this VLAN case you care about, the work can
even be done synchronously.

I'm trying to remember why we added this asynchronous link state event
processing monster.  It probably has something to do with needing a
sleepable context.  What's amusing is that linkwatch has repeatably
caused RTNL deadlock issues over the years. :-)

If it is purely an issue of doing link state processing outside of
HW irq context:

1) PHY events in most drivers are handled in softirq (NAPI ->poll())
   or a workqueue of some sort these days.  If we can make all of
   the link state management softirq safe (it probably is, except
   for perhaps RTNL), these case can be done synchronously always.

2) The remaining cases are device probe, open, and close.  None of
   which execute in HW irq context, they can sleep, and they hold
   RTNL already.

I'm sure there are a few drivers which still can invoke
netif_carrier_*() in HW interrupt context, but we can create a tiny
workqueue helper or something like that for them.  It won't be the
main way to invoke carrier state changes, just a compatability item.

Anyways, just some food for thought.
--
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