All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Patrick McHardy <kaber@trash.net>,
	John Fastabend <john.r.fastabend@intel.com>
Subject: Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
Date: Thu, 14 Nov 2013 21:43:23 -0500	[thread overview]
Message-ID: <52858A4B.7000902@gmail.com> (raw)
In-Reply-To: <20131114155756.GA4161@lion.mk-sys.cz>

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

  parent reply	other threads:[~2013-11-15  2:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-14 14:00 [PATCH net v2 0/2] macvlan: disable LRO on lowerdev instead of a macvlan Michal Kubecek
2013-11-14 14:00 ` [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function Michal Kubecek
2013-11-14 15:03   ` Vlad Yasevich
2013-11-14 15:57     ` Michal Kubecek
2013-11-14 22:03       ` David Miller
2013-11-15  5:26         ` Michal Kubecek
2013-11-15  2:43       ` Vlad Yasevich [this message]
2013-11-14 14:00 ` [PATCH net v2 2/2] macvlan: disable LRO on lower device instead of macvlan Michal Kubecek

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=52858A4B.7000902@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=davem@davemloft.net \
    --cc=john.r.fastabend@intel.com \
    --cc=kaber@trash.net \
    --cc=mkubecek@suse.cz \
    --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.