lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEP_g=9Fpb9KOeqeeK_dbCdec8TvHm-iUZ4V_MWj1Mc21Qa9OQ@mail.gmail.com>
Date:	Tue, 25 Aug 2015 09:50:32 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Pravin Shelar <pshelar@...ira.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 net-next 5/8] geneve: Add support to collect tunnel metadata.

On Mon, Aug 24, 2015 at 7:15 PM, Pravin Shelar <pshelar@...ira.com> wrote:
> On Mon, Aug 24, 2015 at 6:42 PM, Jesse Gross <jesse@...ira.com> wrote:
>> On Mon, Aug 24, 2015 at 10:43 AM, Pravin B Shelar <pshelar@...ira.com> wrote:
>>> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
>>> index 0a6d974..c05bc13 100644
>>> --- a/drivers/net/geneve.c
>>> +++ b/drivers/net/geneve.c
>>> @@ -141,10 +190,15 @@ drop:
>>>  /* Setup stats when device is created */
>>>  static int geneve_init(struct net_device *dev)
>>>  {
>>> +       struct geneve_dev *geneve = netdev_priv(dev);
>>> +
>>>         dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats);
>>>         if (!dev->tstats)
>>>                 return -ENOMEM;
>>>
>>> +       if (geneve->collect_md)
>>> +               dev->features |= NETIF_F_NETNS_LOCAL;
>>
>> I was going back and forth on whether this is the right thing to do.
>> Is it any weirder to allow this than to move a normal tunnel device
>> across namespaces?
>
> Moving this device means moving all tunnels backed by this device
> rather than specific tunnel device. Thats why it does not look right
> to move such device.

I agree it seems weird in general. There were two things that made me wonder:
 * It doesn't appear that VXLAN or GRE do this.
 * The use case for moving a single tunnel to a different namespace is
to have the device and socket live in different places. I guess
conceptually this could apply to collect_md devices as well. (Maybe to
have harder isolation between inside and outside the tunnel?)

I'm not really sure what the best answer is but at least we should be
consistent across tunnel types.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ