All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arvid Brodin <arvid.brodin@xdin.com>
To: David Miller <davem@davemloft.net>
Cc: <netdev@vger.kernel.org>, <shemminger@vyatta.com>,
	<joe@perches.com>, <jboticario@gmail.com>,
	<balferreira@googlemail.com>
Subject: Re: [PATCH v3] net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)
Date: Tue, 3 Sep 2013 17:30:58 +0200	[thread overview]
Message-ID: <522600B2.8090507@xdin.com> (raw)
In-Reply-To: <20130830.155415.1756229438072680437.davem@davemloft.net>

On 2013-08-30 21:54, David Miller wrote:
> From: Arvid Brodin <arvid.brodin@xdin.com>
> Date: Wed, 21 Aug 2013 20:20:17 +0200
> 
>> This is a patch against net-next (2013-08-21).
> 
> First of all, your email client corrupted the patch, chopping up long lines
> and making whitespace changes to the content of the patch.  Please fix this
> before resubmitting, and do so by first sending a test patch to yourself
> and making sure you can apply the patch you receive in that email.  Do not
> use attachments to deal with this issue.

Sorry about that - I forgot to disable Format=Flowed... :(


>> +	if (dev->operstate != transition) {
>> +		write_lock_bh(&dev_base_lock);
>> +		dev->operstate = transition;
>> +		write_unlock_bh(&dev_base_lock);
>> +		netdev_state_change(dev);
>> +	}
> 
> This is racy.  And it appears that set_operstate() in net/core/rtnetlink.c
> has the same bug, I guess that's what you used as a guide.
> 
> Any "test and set" sequence must be guarded completely by the lock, it
> doesn't make any sense to only guard the change of the value.

I never did understand the purpose of the locking done in set_operstate(). Will fix.

Also, Stephen Hemminger told me to use rtnl_mutex instead, but when I pointed
to net/core/rtnetlink.c and asked if he was sure, I did not get a reply. This 
function - __hsr_set_operstate() - is only called from a notifier_call function, 
so rtnl_mutex is already held here. Do I even need additional locking?


(According to ULNI* pp 171 Stephen is right and net/core/rtnetlink.c is wrong...)

* ULNI = Understanding Linux Network Internals

-- 
Arvid Brodin | Consultant (Linux)
XDIN AB | Knarrarnäsgatan 7 | SE-164 40 Kista | Sweden | xdin.com

      reply	other threads:[~2013-09-03 15:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-21 18:20 [PATCH v3] net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0) Arvid Brodin
2013-08-21 19:01 ` Joe Perches
2013-08-21 19:05   ` Sergei Shtylyov
2013-08-21 19:38     ` Joe Perches
2013-08-30 19:54 ` David Miller
2013-09-03 15:30   ` Arvid Brodin [this message]

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=522600B2.8090507@xdin.com \
    --to=arvid.brodin@xdin.com \
    --cc=balferreira@googlemail.com \
    --cc=davem@davemloft.net \
    --cc=jboticario@gmail.com \
    --cc=joe@perches.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.