netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: Patrick McHardy <kaber@trash.net>
Cc: Chuck Ebbert <cebbert@redhat.com>, Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] Re: Nested VLAN causes recursive locking error
Date: Mon, 31 Dec 2007 18:45:55 +0100	[thread overview]
Message-ID: <20071231174555.GA3097@ami.dom.local> (raw)
In-Reply-To: <477904F1.6090403@trash.net>

On Mon, Dec 31, 2007 at 04:04:17PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
>> diff -Nurp linux-2.6.24-rc5-/net/8021q/vlan.c linux-2.6.24-rc5+/net/8021q/vlan.c
>> --- linux-2.6.24-rc5-/net/8021q/vlan.c	2007-12-17 13:29:19.000000000 +0100
>> +++ linux-2.6.24-rc5+/net/8021q/vlan.c	2007-12-20 14:21:02.000000000 +0100
>> @@ -307,12 +307,15 @@ int unregister_vlan_device(struct net_de
>>  	return ret;
>>  }
>>  +#ifdef CONFIG_LOCKDEP
>>  /*
>>   * vlan network devices have devices nesting below it, and are a special
>>   * "super class" of normal network devices; split their locks off into a
>>   * separate class since they always nest.
>>   */
>>  static struct lock_class_key vlan_netdev_xmit_lock_key;
>> +static int subclass; /* vlan nesting vlan */
>> +#endif
>>   static const struct header_ops vlan_header_ops = {
>>  	.create	 = vlan_dev_hard_header,
>> @@ -349,7 +352,14 @@ static int vlan_dev_init(struct net_devi
>>  		dev->hard_start_xmit = vlan_dev_hard_start_xmit;
>>  	}
>>  -	lockdep_set_class(&dev->_xmit_lock, &vlan_netdev_xmit_lock_key);
>> +#ifdef CONFIG_LOCKDEP
>> +	if ((real_dev->priv_flags & IFF_802_1Q_VLAN) &&
>> +	    subclass < MAX_LOCKDEP_SUBCLASSES - 1)
>> +		subclass++;
>> +
>
> That will increment the subclass globally, but it should actually just
> use real_dev->subclass + 1. Otherwise we'll permenently fail after
> registering 8 nested devices and unregistering them again.
>

Very good point! (As usual...) Actually, this shouldn't fail but work
with this one, last subclass only, so similarly like now, without this
patch.

Patric, currently I'm not sure this patch is very necessary... Since
I don't use vlans, I don't know how much it's real or theoretical
only problem. Probably the easiest solution would be limiting this
to two subclasses - any nested vlan gets second. Otherwise, it seems
there is some place needed to store these subclasses or use some
unofficial checks on lockdep's structures?

So, if you think this is useful and have better idea how this should
be done, I would be very glad if you re-do this your way (plus there
should be no problem with testing). Otherwise, give me some hint...

Thanks & Happy New Year!
Jarek P.

  reply	other threads:[~2007-12-31 17:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-18 23:03 Nested VLAN causes recursive locking error Chuck Ebbert
2007-12-20 13:52 ` [PATCH] " Jarek Poplawski
2007-12-31 15:04   ` Patrick McHardy
2007-12-31 17:45     ` Jarek Poplawski [this message]
2007-12-31 17:54       ` Jarek Poplawski
2007-12-31 21:59       ` Jarek Poplawski
2008-01-02 16:40   ` Benny Amorsen
2008-01-02 23:41     ` [PATCH take2] " Jarek Poplawski
2008-01-10 15:31       ` Patrick McHardy
2008-01-10 21:08         ` Jarek Poplawski
2008-01-10 21:33           ` Jarek Poplawski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071231174555.GA3097@ami.dom.local \
    --to=jarkao2@gmail.com \
    --cc=cebbert@redhat.com \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).