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
| ||
|
Date: Mon, 03 Aug 2009 21:19:05 -0700 (PDT) From: David Miller <davem@...emloft.net> To: mpm@...enic.com Cc: bhutchings@...arflare.com, herbert@...dor.apana.org.au, netdev@...r.kernel.org, mcarlson@...adcom.com Subject: Re: netpoll + xmit_lock == deadlock From: Matt Mackall <mpm@...enic.com> Date: Mon, 03 Aug 2009 14:59:41 -0500 > First, I don't think we can solve the problem of 'reliably deliver > printks inside the TX path'. If the driver needs to printk here, odds > are good that sending isn't possible. Agreed. > So I think we should be clear up front that the solution we're looking > for is 'don't crash the box when trying to printk from the tx path'. > > I think the most straightforward, driver-agnostic way to do this > is to have netpoll wrap a driver's TX entrypoint such that recursion is > disabled while in that path. This might actually simplify netpoll's > internal locking ugliness. Something like: > > int netpoll_xmit_wrapper(struct sk_buff *skb, struct net_device *dev) > { > struct netpoll_info *npinfo = dev->npinfo; > int ret; > > npinfo->recurse += 1; /* add appropriate locking */ > ret = npinfo->orig_tx(skb, dev); > npinfo->recurse -= 1; > > return ret; > } Looks workable. Probably we even hold the netpoll lock here so no additional protection would even be needed. -- 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
Powered by blists - more mailing lists