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: <568D6188.4090705@stressinduktion.org>
Date:	Wed, 6 Jan 2016 19:48:40 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Jesse Gross <jesse@...nel.org>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/2] geneve: break dependency to network drivers

On 06.01.2016 19:00, Jesse Gross wrote:
> On Wed, Jan 6, 2016 at 7:41 AM, Hannes Frederic Sowa
> <hannes@...essinduktion.org> wrote:
>> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
>> index 24b077a32c1c9c..548925d1571cb1 100644
>> --- a/drivers/net/geneve.c
>> +++ b/drivers/net/geneve.c
>> +static int geneve_notifier(struct notifier_block *unused,
>> +                          unsigned long event, void *ptr)
>> +{
>> +       struct net_device *dev = netdev_notifier_info_to_dev(ptr);
>> +
>> +       switch (event) {
>> +       case NETDEV_REFRESH_OFFLOAD_VXLAN:
>> +               geneve_notify_refresh_netdev(dev);
>
> Presumably this should be NETDEV_REFRESH_OFFLOAD_GENEVE, not VXLAN.
> However, rather than having a notifier for each protocol, it seems
> like it might be cleaner to just have a single one that triggers for
> all protocols and drivers that don't have the corresponding NDO
> wouldn't get called, similar to what happens when the port gets added
> in the first place.

Ah, thanks for noticing the typo.

The reason why I went with several types is that I didn't want to change 
the behavior and wasn't sure if driver tested with reoccurring offload 
refreshes to the driver. What you described was my first patch but 
because I couldn't see if that works for all drivers I went this way.

>> diff --git a/include/net/geneve.h b/include/net/geneve.h
>> index e6c23dc765f7ec..36245115143652 100644
>> --- a/include/net/geneve.h
>> +++ b/include/net/geneve.h
> [...]
>>   static inline void geneve_get_rx_port(struct net_device *netdev)
>>   {
>> +       call_netdevice_notifiers(NETDEV_REFRESH_OFFLOAD_GENEVE, netdev);
>>   }
>
> Unfortunately, I don't think that we can assume that RTNL is held
> here. It actually is for the drivers that implement Geneve at this
> point but not in all cases for VXLAN. For example, ixgbe refreshes the
> offloads in a service task in addition to when it is opened. There's
> only a couple instances of things like this, so I guess it's probably
> not too hard to through and make sure that we hold RTNL in those
> cases.

Hmm, I am tempted to switch over to the netevent atomic notifier chain 
and install those events there. It does not need rtnl lock at all, so we 
can preserve the current semantics. What do you think?

Thanks,
Hannes

--
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