All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shannon Nelson <shannon.nelson@oracle.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, steffen.klassert@secunet.com
Subject: Re: [PATCH net] macvlan: filter out xfrm feature flags
Date: Thu, 8 Mar 2018 15:34:02 -0800	[thread overview]
Message-ID: <1a5020a8-015e-474c-0ec0-8f594e38a7b5@oracle.com> (raw)
In-Reply-To: <20180308.123310.406604126920910381.davem@davemloft.net>

On 3/8/2018 9:33 AM, David Miller wrote:
> From: Shannon Nelson <shannon.nelson@oracle.com>
> Date: Tue,  6 Mar 2018 14:57:08 -0800
> 
>> This isn't broken for vlans because they use a separate features
>> connection (vlan_features) for inheriting features.  This is
>> fine, but I don't think trying to add something like this to
>> every driver for every new upperdev is a good idea - I think
>> the upperdev should try to protect itself.
> 
> I think this fix is correct.
> 
> But for how many upperdevs are we going to duplicate code like this,
> and how many subtle differences and in fact bugs will result from all
> of that duplication?
> 
> I think we really need something common for these upperdev drivers
> to use.  Maybe just a macro defining feature bits to trim in this
> situation.
> 
> Thanks.

Thanks, Dave.  Yes, this could use something a little more generic, 
something that would catch any future "dangerous" bits.

I'm not sure we can come up with a generic mask to be used by everyone, 
as each upper and lower dev has their own feature support levels.  But 
we might come up with a better example for others to follow.

Rather than calling out specific non-supported bits, we can probably 
just build a mask from bits that we already know are supported, 
something like this:
	features &= (ALWAYS_ON_FEATURES | MACVLAN_FEATURES);

which would take care of NETIF_F_NETNS_LOCAL, the ESP flags, and 
anything else that wasn't already specifically called for.  I'll repost 
with this and see what folks think.

sln

      reply	other threads:[~2018-03-08 23:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-06 22:57 [PATCH net] macvlan: filter out xfrm feature flags Shannon Nelson
2018-03-08 17:33 ` David Miller
2018-03-08 23:34   ` Shannon Nelson [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=1a5020a8-015e-474c-0ec0-8f594e38a7b5@oracle.com \
    --to=shannon.nelson@oracle.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.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.