On Fri, May 11, 2007 at 02:12:25PM -0700, Andrew Morton wrote: > On Fri, 11 May 2007 14:03:09 -0700 (PDT) > David Miller <[EMAIL PROTECTED]> wrote: > > > From: Jeff Garzik <[EMAIL PROTECTED]> > > Date: Fri, 11 May 2007 16:57:19 -0400 > > > > > applied > > > > I was under the impression that this patch didn't actually fix the > > problem yet? I might be thinking about something else... > > yeah, sorry, it seems that the discussion is ongoing. Please drop the > patch. I did. >
After sending this patch I was a little confused, when next lockdep warning report appeared, and I thought - since this is not enough, this patch could be dumped. But now I changed my mind: there are really many possibilities of strange connections between locks taken from vlans, ppp (with pppoe), multicasts etc. - that every one possibility less is a gain here. As I wrote earlier, one of main reasons of such a situation is calling dev_queue_xmit() in a nested way, with xmit locks of previous layers held (as e.g. pppoe after ppp_generic). On the other hand, changing this may be not enough to, because some locks are seen by lockdep as one: e.g. eth & ppp netdevs, or vlan's lock on eth vs. vlan's lock on ppp. So, now I think this patch should stay (it simply says the truth to lockdep - there are two, functionally independent kinds of ppp channels with independent locks), because it does no harm (AFAIK), and there is really at least one type of lockdep report less. I also think that my two next patches (for vlan and ppp_generic), are useful and should be applied even, if they are not enough with this, quite complex configuration. Of course, later, if somebody will find better solution, they could be removed, but now, by not using them, some real locking problems may be hidden because of the way lockdep works (or stops to work), and there is no reason to frighten users with these current, false warnings too. Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
