Re: LOR with netisr changes



On Tuesday 28 November 2006 14:41, Sam Leffler wrote:
Robert Watson wrote:

On Wed, 29 Nov 2006, Munehiro Matsuda wrote:

JFYI, I got following LOR started after the netisr changes:

In general, device driver locks should not be held over entry to the
network stack. However, things get a bit tricky in the 802.11 code due
to lock sharing, I believe, so it could be a bit more tricky to fix that.

It's just a bug in the driver. Driver locks should be dropped when
packets get passed up the stack. This issue was pointed out before iwi
ever was committed but since nothing immediately comes back via the
bridge (or similar) it's been ignored.

How about this:

Index: if_iwi.c
===================================================================
RCS file: /usr/cvs/src/sys/dev/iwi/if_iwi.c,v
retrieving revision 1.42
diff -u -r1.42 if_iwi.c
--- if_iwi.c 7 Nov 2006 19:03:42 -0000 1.42
+++ if_iwi.c 29 Nov 2006 17:38:12 -0000
@@ -1310,6 +1310,7 @@

bpf_mtap2(sc->sc_drvbpf, tap, sc->sc_rxtap_len, m);
}
+ IWI_UNLOCK(sc);

ni = ieee80211_find_rxnode(ic, mtod(m, struct ieee80211_frame_min *));

@@ -1319,6 +1320,7 @@
/* node is no longer needed */
ieee80211_free_node(ni);

+ IWI_LOCK(sc);
if (sc->sc_softled) {
/*
* Blink for any data frame. Otherwise do a

(I'm unsure if the net82011 layer protects 'ic' or if the driver is supposed
to do that.)

--
John Baldwin
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: LOR with netisr changes
    ... device driver locks should not be held over entry to the ... network stack. ... to lock sharing, I believe, so it could be a bit more tricky to fix that. ...
    (freebsd-current)
  • Re: LOR with netisr changes
    ... On Wed, 29 Nov 2006, Munehiro Matsuda wrote: ... device driver locks should not be held over entry to the network stack. ... However, things get a bit tricky in the 802.11 code due to lock sharing, I believe, so it could be a bit more tricky to fix that. ...
    (freebsd-current)