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: Tue, 20 Mar 2007 06:54:55 -0400 From: Chris Madden <chris@...lexsecurity.com> To: hadi@...erus.ca CC: Patrick McHardy <kaber@...sh.net>, David Miller <davem@...emloft.net>, netdev@...r.kernel.org, tgraf@...g.ch Subject: Re: Oops in filter add Thanks for all your replies! One thing I did notice in examining tc_ctl_tfilter was that there is something like: qdisc_lock_tree(dev); tp->next = *back; *back = tp; qdisc_unlock_tree(dev); And then proceed to the data structure down below with: err = tp->ops->change(tp, cl, t->tcm_handle, tca, &fh); Simply reordering these seems to ameliorate the problem greatly. I don't know if this is a generic solution or something specific to the basic filter only. Chris Madden jamal wrote: > On Tue, 2007-20-03 at 08:29 +0100, Patrick McHardy wrote: > >> jamal wrote: >> >>> On Tue, 2007-20-03 at 07:58 +0100, Patrick McHardy wrote: >>> >>> Ok. It certainly used to matter in the old days. >>> >> Actually it has never been used anywhere else but in ing_filter, >> it was introduced together with the TC actions. >> >> > > You are correct. I looked at old 2.4 and all i saw was: > > ---------- > /* > revisit later: Use a private since lock dev->queue_lock is also > used on the egress (might slow things for an iota) > */ > > if (dev->qdisc_ingress) { > spin_lock(&dev->queue_lock); > if ((q = dev->qdisc_ingress) != NULL) > fwres = q->enqueue(skb, q); > spin_unlock(&dev->queue_lock); > } > ------ > > So the resolution (as Dave points out) was wrong. In any case, restoring > queue_lock for now would slow things but will remove the race. > > >> I'll try, but no promises, I'm a bit behind with various things myself. >> > > I will ping you in a few days and if you havent done anything i will > take it up. > I am almost tempted to make the ingress filters to not have any > dependencies on egress whatsoever. It will create more locks but > will make the datapath faster. Actions can still be shared, but thats > lesser of an overhead. > > cheers, > jamal > > - 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