On Sun, Apr 22, 2012 at 3:23 AM, David Miller <davem@xxxxxxxxxxxxx> wrote: > From: Ming Lei <tom.leiming@xxxxxxxxx> > Date: Sat, 21 Apr 2012 09:49:51 +0800 > >> I see the problem, so looks skb_queue_walk_safe is not safe. >> I don' know why the 2nd ' tmp = skb->next' in skb_queue_walk_safe >> is needed and it may become unsafe if skb is freed during current loop. > > I can't see what the problem is, skb_queue_walk_safe() is perfect > and does exactly what it advertises to do. > > If 'skb' is unlinked inside of an skb_queue_walk_safe() loop, that's > fine, because we won't touch 'skb' in the loop iteration tail code. > > Instead, before the loop contents, we pre-fetch skb->next into 'tmp' > and then at the end we move 'skb' forward by simply assigning 'tmp'. In this case, the problem is, 'tmp = skb->next' can be moved out of rxq/txq, and even be freed. Then in next loop cycle, 'skb = tmp' will refer to a freed skb. You know, in current code stack, unlink_urbs() releases q->lock in each loop, this gives chance to urb complete handler to call defer_bh() and cause the problem. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
