diff options
author | Neil Horman <nhorman@tuxdriver.com> | 2013-02-05 08:05:43 +0000 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2013-02-06 15:45:03 -0500 |
commit | ca99ca14c95ae49fb4c9cd3abf5f84d11a7e8a61 (patch) | |
tree | 889b44125a7d9471424fc58537ba7e19aec20a2c /include/linux/netpoll.h | |
parent | f458c647ea5cdd956f8055a4178072be460559f1 (diff) | |
download | linux-3.10-ca99ca14c95ae49fb4c9cd3abf5f84d11a7e8a61.tar.gz linux-3.10-ca99ca14c95ae49fb4c9cd3abf5f84d11a7e8a61.tar.bz2 linux-3.10-ca99ca14c95ae49fb4c9cd3abf5f84d11a7e8a61.zip |
netpoll: protect napi_poll and poll_controller during dev_[open|close]
Ivan Vercera was recently backporting commit
9c13cb8bb477a83b9a3c9e5a5478a4e21294a760 to a RHEL kernel, and I noticed that,
while this patch protects the tg3 driver from having its ndo_poll_controller
routine called during device initalization, it does nothing for the driver
during shutdown. I.e. it would be entirely possible to have the
ndo_poll_controller method (or subsequently the ndo_poll) routine called for a
driver in the netpoll path on CPU A while in parallel on CPU B, the ndo_close or
ndo_open routine could be called. Given that the two latter routines tend to
initizlize and free many data structures that the former two rely on, the result
can easily be data corruption or various other crashes. Furthermore, it seems
that this is potentially a problem with all net drivers that support netpoll,
and so this should ideally be fixed in a common path.
As Ben H Pointed out to me, we can't preform dev_open/dev_close in atomic
context, so I've come up with this solution. We can use a mutex to sleep in
open/close paths and just do a mutex_trylock in the napi poll path and abandon
the poll attempt if we're locked, as we'll just retry the poll on the next send
anyway.
I've tested this here by flooding netconsole with messages on a system whos nic
driver I modfied to periodically return NETDEV_TX_BUSY, so that the netpoll tx
workqueue would be forced to send frames and poll the device. While this was
going on I rapidly ifdown/up'ed the interface and watched for any problems.
I've not found any.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Ivan Vecera <ivecera@redhat.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Ben Hutchings <bhutchings@solarflare.com>
CC: Francois Romieu <romieu@fr.zoreil.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/linux/netpoll.h')
-rw-r--r-- | include/linux/netpoll.h | 11 |
1 files changed, 10 insertions, 1 deletions
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h index f54c3bb6a22..ab856d507b7 100644 --- a/include/linux/netpoll.h +++ b/include/linux/netpoll.h @@ -38,8 +38,9 @@ struct netpoll { struct netpoll_info { atomic_t refcnt; - int rx_flags; + unsigned long rx_flags; spinlock_t rx_lock; + struct mutex dev_lock; struct list_head rx_np; /* netpolls that registered an rx_hook */ struct sk_buff_head neigh_tx; /* list of neigh requests to reply to */ @@ -51,6 +52,14 @@ struct netpoll_info { struct rcu_head rcu; }; +#ifdef CONFIG_NETPOLL +extern int netpoll_rx_disable(struct net_device *dev); +extern void netpoll_rx_enable(struct net_device *dev); +#else +static inline int netpoll_rx_disable(struct net_device *dev) { return 0; } +static inline void netpoll_rx_enable(struct net_device *dev) { return; } +#endif + void netpoll_send_udp(struct netpoll *np, const char *msg, int len); void netpoll_print_options(struct netpoll *np); int netpoll_parse_options(struct netpoll *np, char *opt); |