All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roopa Prabhu <roopa@cumulusnetworks.com>
To: Hubert Sokolowski <hubert.sokolowski@intel.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
	vyasevic@redhat.com, John Fastabend <john.fastabend@gmail.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
Date: Fri, 19 Dec 2014 08:32:45 -0800	[thread overview]
Message-ID: <5494532D.4040203@cumulusnetworks.com> (raw)
In-Reply-To: <5494418B.1000004@intel.com>

On 12/19/14, 7:17 AM, Hubert Sokolowski wrote:
> On 18/12/14 22:32, Jamal Hadi Salim wrote:
>
>> Sorry for the latency (head-buried-in-sand in effect)
>> On 12/17/14 11:18, Hubert Sokolowski wrote:
>>> I have just prepared a patch where I dump uc/mc for bridge devices
>>> by looking at (dev->priv_flags & IFF_EBRIDGE), so I have same results
>>> as without my changes. This should satisfy Jamal and Roopa.
>>> I could send it as v3 of my patch along with the results if you are
>>> interested.
>> Please do. If you satisfy Vlad's goals then we are all happy.
> Posted as v3, please review.
> There is still open question I asked sometime ago but never got explained.
> It is about the new filter_dev parameter that was added to ndo_fdb_dump:
>          int                     (*ndo_fdb_dump)(struct sk_buff *skb,
>                                                  struct netlink_callback *cb,
>                                                  struct net_device *dev,
>                                                  struct net_device *filter_dev,
>                                                  int idx);
>
> When we call this function for a device, dev pointer is passed as the filter_dev:
>                  if (dev->netdev_ops->ndo_fdb_dump)
>                          idx = dev->netdev_ops->ndo_fdb_dump(skb, cb, bdev, dev,
>                                                              idx);
seems like these calls should be fixed. bdev is really dev in this case. 
And filter_dev should be null.
>
> This is not an issue for a bridge device and a device that is not enslaved
> in a bridge because bdev == dev, but this can be dangerous in other cases.
> Let's assume QLogic NIC has a master device, in this case bdev != dev.
> Now look what is happening, dev is passed as filter_dev to:
> static int qlcnic_fdb_dump(struct sk_buff *skb, struct netlink_callback *ncb,
>                          struct net_device *netdev,
>                          struct net_device *filter_dev, int idx)
> {
>          struct qlcnic_adapter *adapter = netdev_priv(netdev);
> ...
>
> netdev_priv(netdev) returns a pointer to private struct of the bridge,but the driver
> is expecting it's own private stuff.
>
> Should we fix the driver and assume filter_dev is /me and dev is our master
> or the parameters were reversed and should be passed as (skb, cb, dev, bdev, idx) ?
> Is this something for another patch/discussion?
>
> regards,
> Hubert
>

  reply	other threads:[~2014-12-19 16:32 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10 19:37 [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined Hubert Sokolowski
2014-12-11  4:32 ` David Miller
2014-12-11 11:49   ` Jamal Hadi Salim
2014-12-11 16:51     ` Hubert Sokolowski
2014-12-11  7:31 ` Roopa Prabhu
2014-12-11 16:39   ` Hubert Sokolowski
2014-12-11 18:47     ` Arad, Ronen
2014-12-11 17:06   ` Hubert Sokolowski
2014-12-11 17:32     ` Roopa Prabhu
2014-12-11 20:40       ` Jamal Hadi Salim
2014-12-12 11:38       ` Hubert Sokolowski
2014-12-12 11:54         ` Jamal Hadi Salim
2014-12-12 13:36           ` Hubert Sokolowski
2014-12-12 14:35             ` Jamal Hadi Salim
2014-12-12 20:05               ` John Fastabend
2014-12-15 14:29                 ` Jamal Hadi Salim
2014-12-16  0:45                   ` John Fastabend
2014-12-16 13:06                     ` Jamal Hadi Salim
2014-12-16 14:35                       ` Hubert Sokolowski
2014-12-16 16:35                       ` John Fastabend
2014-12-16 17:21                         ` Samudrala, Sridhar
2014-12-16 19:30                           ` Roopa Prabhu
2014-12-16 20:11                             ` Samudrala, Sridhar
2014-12-17  5:54                               ` Roopa Prabhu
2014-12-21 14:27                         ` SRIOV as bridge " Jamal Hadi Salim
     [not found]                           ` <443500166.23675449.1419179623398.JavaMail.zimbra@cumulusnetworks.com>
2014-12-21 16:33                             ` Shrijeet Mukherjee
2014-12-21 19:08                           ` Roopa Prabhu
2014-12-21 19:19                             ` Jamal Hadi Salim
2014-12-21 19:36                               ` Roopa Prabhu
2014-12-21 20:06                                 ` Jamal Hadi Salim
2014-12-21 20:46                                   ` Roopa Prabhu
2014-12-22  3:13                                     ` Jamal Hadi Salim
2014-12-22  6:24                                       ` Roopa Prabhu
2014-12-22 12:10                                         ` Jamal Hadi Salim
2014-12-22 13:04                                           ` Jamal Hadi Salim
2014-12-21 19:52                             ` John Fastabend
2014-12-22  2:59                               ` Jamal Hadi Salim
2014-12-21 14:46                         ` SRIOV fdb and modes WAS(Re: " Jamal Hadi Salim
2014-12-17  5:51                       ` Roopa Prabhu
2014-12-17 15:39                     ` Vlad Yasevich
2014-12-17 16:18                       ` Hubert Sokolowski
2014-12-18 22:32                         ` Jamal Hadi Salim
2014-12-19 15:17                           ` Hubert Sokolowski
2014-12-19 16:32                             ` Roopa Prabhu [this message]
2015-01-05 12:56                               ` Hubert Sokolowski

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=5494532D.4040203@cumulusnetworks.com \
    --to=roopa@cumulusnetworks.com \
    --cc=hubert.sokolowski@intel.com \
    --cc=jhs@mojatatu.com \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevic@redhat.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.