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]
Date:	Thu, 14 Nov 2013 21:43:23 -0500
From:	Vlad Yasevich <vyasevich@...il.com>
To:	Michal Kubecek <mkubecek@...e.cz>
CC:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>,
	John Fastabend <john.r.fastabend@...el.com>
Subject: Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev()
 helper function

On 11/14/2013 10:57 AM, Michal Kubecek wrote:
> On Thu, Nov 14, 2013 at 10:03:19AM -0500, Vlad Yasevich wrote:
>> On 11/14/2013 09:00 AM, Michal Kubecek wrote:
>>> +#if IS_ENABLED(CONFIG_MACVLAN)
>>> +static inline struct net_device *
>>> +macvlan_dev_real_dev(const struct net_device *dev)
>>> +{
>>> +	struct macvlan_dev *macvlan = netdev_priv(dev);
>>> +
>>> +	return macvlan->lowerdev;
>>> +}
>>> +#else
>>> +static inline struct net_device *
>>> +macvlan_dev_real_dev(const struct net_device *dev)
>>> +{
>>> +	return NULL;
>>> +}
>>> +#endif
>>> +
>>
>> You may want to do the same here as was done for
>> vlan_dev_real_dev(). This function is not intended to be called
>> blindly and should always
>> be called after netif_is_macvlan().
>
> I'm not sure. It makes sense from the developer point of view: if we
> find an inconsistency which must be caused by a bug in kernel code, do
> panic so that the bug is found and fixed as soon as possible. However,
> I remember a discussion where the point was that BUG() and BUG_ON()
> should only be used if there is no way to recover. From this point of
> view, WARN or WARN_ONCE might be better choice - but I'm not strictly
> opposed to BUG().
>
>                                                         Michal Kubecek
>

If someone blindly calls macvlan_dev_real_dev() and macvlan module is 
enabled, but there is no macvlan device, you are going to get garbage 
and crash.  So crashing if module is disabled for the same case seems
perfectly reasonable.

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