From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
To: "Banerjee, Debabrata" <dbanerje@akamai.com>,
Patrick McHardy <kaber@trash.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH] macvlan: Support interface operstate properly
Date: Wed, 6 Apr 2016 23:42:03 +0200 [thread overview]
Message-ID: <570582AB.3040702@cumulusnetworks.com> (raw)
In-Reply-To: <53A6C2CA-9C49-4F85-97F6-DD60276AFCC2@akamai.com>
On 04/06/2016 11:26 PM, Banerjee, Debabrata wrote:
> On 4/6/16, 5:03 PM, "Nikolay Aleksandrov" <nikolay@cumulusnetworks.com> wrote:
>
>
>> On 04/06/2016 10:30 PM, Debabrata Banerjee wrote:
>>> Set appropriate macvlan interface status based on lower device and our
>>> status. Can be up, down, or lowerlayerdown.
>>>
>>> Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
>>>
>>
>> May I ask what is exactly that you're fixing here ? I recently had to make macvlan's
>> operstates more accurate and I haven't experienced any wrong behaviour since commit
>> de7d244d0a35 ("macvlan: make operstate and carrier more accurate").
>
> Yes I saw the other patch, it's an improvement from when I started working on this.
>
>
>> Also it's the linkwatch's job to take care for the proper operstate, we can use
>> netif_stacked_transfer_operstate to help it, but I don't think directly setting
>> operstate is a good idea.
>
> This patch was modeled after __hsr_set_operstate(). But I agree there's probably
> better ways to do it. I'm not sure why netif_stacked_transfer_operstate() doesn't do
> it itself, although in the case of a layered device, my patch actually uses the other
> possible state, which is lowerlayerdown. Without the patch operstate goes directly to
> down.
>
>>
>> One more thing - you cannot use netdev_state_change() under the write_lock as it
>> may sleep.
>
> You're right, I can resubmit moving the call out of the critical section, if the patch
> will be taken.
>
I don't know if it'll be taken, but you can submit v2 for review. I'll review and
test it tomorrow as it's late here and I'm tired. :-)
Since this is not a bug fix, I'd suggest to target net-next and you
don't have to CC linux-kernel@vger.kernel.org.
Thanks for the explanation, I misread part of the patch at first and was confused,
but I got the idea now.
Cheers,
Nik
next prev parent reply other threads:[~2016-04-06 21:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 20:30 [PATCH] macvlan: Support interface operstate properly Debabrata Banerjee
2016-04-06 21:03 ` Nikolay Aleksandrov
2016-04-06 21:26 ` Banerjee, Debabrata
2016-04-06 21:42 ` Nikolay Aleksandrov [this message]
2016-04-06 21:27 ` Nikolay Aleksandrov
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=570582AB.3040702@cumulusnetworks.com \
--to=nikolay@cumulusnetworks.com \
--cc=dbanerje@akamai.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 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.