* Re: [PATCH net-next] tun/macvtap: use consume_skb() instead of kfree_skb() in tun/macvtap_do_read()
From: Jason Wang @ 2014-11-26 6:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, linux-kernel, mst
In-Reply-To: <1416983160.29427.52.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/26/2014 02:26 PM, Eric Dumazet wrote:
> On Wed, 2014-11-26 at 14:08 +0800, Jason Wang wrote:
>> To be more friendly with drop monitor, we should use comsume_skb() instead
>> of kfree_skb() in tun/macvtap_do_read(). Otherwise, the packets will be
>> marked as dropped.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/net/macvtap.c | 2 +-
>> drivers/net/tun.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>> index 42a80d3..74d1b23 100644
>> --- a/drivers/net/macvtap.c
>> +++ b/drivers/net/macvtap.c
>> @@ -862,7 +862,7 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
>> }
>> iov_iter_init(&iter, READ, iv, segs, len);
>> ret = macvtap_put_user(q, skb, &iter);
>> - kfree_skb(skb);
>> + consume_skb(skb);
>> break;
>> }
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index ac53a73..d7edeaf 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1363,7 +1363,7 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
>>
>> iov_iter_init(&iter, READ, iv, segs, len);
>> ret = tun_put_user(tun, tfile, skb, &iter);
>> - kfree_skb(skb);
>> + consume_skb(skb);
>>
>> return ret;
>> }
>
> These patches keep going on, but they are wrong.
>
> If you care about drop monitor, then you want to not hide drops but
> precisely report them.
>
> Surely tun_put_user() can return an error, and then packet _is_ dropped.
True, I miss this. Will post V2. Thanks
^ permalink raw reply
* Re: [PATCH net-next v4] ipvlan: Initial check-in of the IPVLAN driver.
From: Toshiaki Makita @ 2014-11-26 6:41 UTC (permalink / raw)
To: Mahesh Bandewar, netdev
Cc: Eric Dumazet, Maciej Zenczykowski, Laurent Chavey, Tim Hockin,
David Miller, Brandon Philips, Pavel Emelianov
In-Reply-To: <1416812866-13401-1-git-send-email-maheshb@google.com>
Hi Mahesh,
I found that deleting the last ipvlan device triggers WARN_ON() in
rtmsg_ifinfo().
ipvlan_nl_fillinfo() seems to return -EINVAL in that case.
> +static int ipvlan_nl_fillinfo(struct sk_buff *skb,
> + const struct net_device *dev)
> +{
> + struct ipvl_dev *ipvlan = netdev_priv(dev);
> + struct ipvl_port *port = ipvlan_port_get_rtnl(ipvlan->phy_dev);
> + int ret = -EINVAL;
> +
> + if (!port)
> + goto err;
> +
> + ret = -EMSGSIZE;
> + if (nla_put_u16(skb, IFLA_IPVLAN_MODE, port->mode))
> + goto err;
> +
> + return 0;
> +
> +err:
> + return ret;
> +}
rollback_registered_many() calls rtmsg_ifinfo() after calling ndo_uninit().
ndo_uninit() (ipvlan_uninit() -> ipvlan_port_destroy() ->
netdev_rx_handler_unregister()) sets rx_handler_data into NULL.
So, we cannot dereference "port" in ipvlan_nl_fillinfo().
Maybe "mode" should belong to struct ipvl_dev?
Thanks,
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH 1/2] virito: introduce methods of fixing device features
From: Jason Wang @ 2014-11-26 7:09 UTC (permalink / raw)
To: Rusty Russell; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <87sih9xv5u.fsf@rustcorp.com.au>
----- Original Message -----
> Jason Wang <jasowang@redhat.com> writes:
> > Buggy host may advertised buggy host features (a usual case is that host
> > advertise a feature whose dependencies were missed). In this case, driver
> > should detect and disable the buggy features by itself.
>
> Sorry, I've been focussing elsewhere.
>
> I would really prefer that drivers offer a "feature_depends" table,
> which can indicate that feature A depends on feature B, and have the
> core iterate, complain and fixup as necessary.
>
> Is that expressive enough, or do we need more?
>
> Thanks,
> Rusty.
I suggested something like this in https://lkml.org/lkml/2014/11/19/132, but
Michael does not like it ...
^ permalink raw reply
* Re: Multiple DSA switch on shared MII
From: Rajib Karmakar @ 2014-11-26 7:33 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <CAGVrzcaG_uYpmmgC252ObHJ9Cmt91-BUtB3uOfPJHV6RhkRU1Q@mail.gmail.com>
Hello Florian,
Thanks for your reply.
On Wed, Nov 26, 2014 at 10:52 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> 2014-11-25 20:52 GMT-08:00 Rajib Karmakar <rajibkit@gmail.com>:
>> Hello,
>>
>> I am developing a DSA driver for Marvell 6172 and need to create 2 dsa
>> switch chip (one for WAN and one for LAN).
>
> This is not typically how it is designed to work, you would register
> one dsa switch chip with the ports assignment in this data structure.
> Right now, DSA does not support a dual Ethernet MAC configuration,
> although you could probably do per-port VLAN membership and create two
> default VLANs to allow that.
>
>>
>> My device has 2 MACs and one shared mii_bus. I have added two
>> dsa_platform_data structures and registered them but cannot probe as
>> dsa_probe tries mdio_register() on the same bus and fails.
>>
>> Is it possible to create two DSA switch on same (shared) mii?
>
> Not in its current form, and I am not exactly sure how we would support that.
Yes, not with the current DSA implementation, but I can manage to
solve this by a small (ugly) patch - renamed the slave mii bus as
"<master_bus->id>:<pd->sw_addr>:<platform_device->id>" instead of
"<master_bus->id>:<pd->sw_addr>". Though I am not yet sure enough if
this could have any negative impact or not.
Comments please.
>
>>
>> Regards,
>> Rajib
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Florian
----
diff -rup org/net/dsa/dsa.c mod/net/dsa/dsa.c
--- org/net/dsa/dsa.c
+++ mod/net/dsa/dsa.c
@@ -68,7 +68,7 @@ dsa_switch_probe(struct mii_bus *bus, in
/* basic switch operations **************************************************/
static struct dsa_switch *
-dsa_switch_setup(struct dsa_switch_tree *dst, int index,
+dsa_switch_setup(struct dsa_switch_tree *dst, int index, int id,
struct device *parent, struct mii_bus *bus)
{
struct dsa_chip_data *pd = dst->pd->chip + index;
@@ -156,7 +156,7 @@ dsa_switch_setup(struct dsa_switch_tree
ret = -ENOMEM;
goto out;
}
- dsa_slave_mii_bus_init(ds);
+ dsa_slave_mii_bus_init(ds, id);
ret = mdiobus_register(ds->slave_mii_bus);
if (ret < 0)
@@ -349,7 +349,7 @@ static int dsa_probe(struct platform_dev
continue;
}
- ds = dsa_switch_setup(dst, i, &pdev->dev, bus);
+ ds = dsa_switch_setup(dst, i, pdev->id, &pdev->dev, bus);
if (IS_ERR(ds)) {
printk(KERN_ERR "%s[%d]: couldn't create dsa switch "
"instance (error %ld)\n", dev->name, i,
diff -rup org/net/dsa/dsa_priv.h mod/net/dsa/dsa_priv.h
--- org/net/dsa/dsa_priv.h
+++ mod/net/dsa/dsa_priv.h
@@ -163,7 +163,7 @@ void register_switch_driver(struct dsa_s
void unregister_switch_driver(struct dsa_switch_driver *type);
/* slave.c */
-void dsa_slave_mii_bus_init(struct dsa_switch *ds);
+void dsa_slave_mii_bus_init(struct dsa_switch *ds, int id);
struct net_device *dsa_slave_create(struct dsa_switch *ds,
struct device *parent,
int port, char *name);
diff -rup org/net/dsa/slave.c mod/net/dsa/slave.c
--- org/net/dsa/slave.c
+++ mod/net/dsa/slave.c
@@ -35,14 +35,14 @@ static int dsa_slave_phy_write(struct mi
return 0;
}
-void dsa_slave_mii_bus_init(struct dsa_switch *ds)
+void dsa_slave_mii_bus_init(struct dsa_switch *ds, int id)
{
ds->slave_mii_bus->priv = (void *)ds;
ds->slave_mii_bus->name = "dsa slave smi";
ds->slave_mii_bus->read = dsa_slave_phy_read;
ds->slave_mii_bus->write = dsa_slave_phy_write;
- snprintf(ds->slave_mii_bus->id, MII_BUS_ID_SIZE, "%s:%.2x",
- ds->master_mii_bus->id, ds->pd->sw_addr);
+ snprintf(ds->slave_mii_bus->id, MII_BUS_ID_SIZE, "%s:%.2x:%.1x",
+ ds->master_mii_bus->id, ds->pd->sw_addr, id);
ds->slave_mii_bus->parent = &ds->master_mii_bus->dev;
}
^ permalink raw reply
* RE: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Arad, Ronen @ 2014-11-26 7:35 UTC (permalink / raw)
To: netdev@vger.kernel.org
>@@ -2312,7 +2313,7 @@ errout:
> int ndo_dflt_fdb_add(struct ndmsg *ndm,
> struct nlattr *tb[],
> struct net_device *dev,
>- const unsigned char *addr,
>+ const unsigned char *addr, u16 vid,
> u16 flags)
> {
> int err = -EINVAL;
>@@ -2409,7 +2439,7 @@ out:
> int ndo_dflt_fdb_del(struct ndmsg *ndm,
> struct nlattr *tb[],
> struct net_device *dev,
>- const unsigned char *addr)
>+ const unsigned char *addr, u16 vid)
> {
> int err = -EINVAL;
What is the expected role of vid in ndo_dflt_fdb_add/ndo_dflt_fdb_del?
It is ignored in both functions.
Will the vid be passed to dev_uc_add/dev_uc_add_excl/dev_uc_del and similar dev_mc_xxx functions?
Will the device address lists become VLAN-aware?
^ permalink raw reply
* RE: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Arad, Ronen @ 2014-11-26 7:37 UTC (permalink / raw)
To: netdev@vger.kernel.org
> >>>
> >>> Is there any case where this fdb entry gets re-used and is no
> >>> longer added by an external learning? Should we clear this flag somewhere?
> >>
> >> Once the FDB entry is marked "added_by_external_learn" it stays
> >> marked as such until removed by aging cleanup process (or flushed
> >> due to interface down, etc). If aged out (and now deleted), the
> >> FDB entry may come back either by SW learn or by HW learn. If SW
> >> learn comes first, and then HW learn, HW learn will override and
> >> mark the existing FDB entry "added_by_external_learn". So there is
> >> take-over by HW but no give-back to SW. And there is no explicit
> >> clearing of the mark short of deleting the FDB entry. The mark is
> >> mostly for letting user's know which FDB entries where learned by
> >> HW and synced to the bridge's FDB.
> >
> > Thanks, makes sense now. This is probably obvious in this context,
> > but maybe it would not hurt to come up with a documentation that
> > describe the offload API, FDB entry lifetime and HW/SW ownership etc...
>
> I have an updated Documentation/networking/switchdev.txt that covers
> the swdev APIs and usage and notes, but Jiri is being stingy with it.
> Will get this out, either in v4 or follow-on patches. There is enough
> going on just with L2 offload that we're going to need some good
> documentation to guide implementers.
> --
To control the lifetime of an externally learned FDB entry, the bridge shall provide an API for the switch driver to update the freshness of externally learned entries. Otherwise, the bridge aging will age entries which are currently or frequently used by the HW.
Is this covered in the updated document?
Is this functionality planned for v4?
^ permalink raw reply
* Re: [PATCH v2 net-next 3/3] tuntap: reduce the size of tun_struct by using flex array.
From: Pankaj Gupta @ 2014-11-26 7:40 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, netdev, jasowang, dgibson, vfalico, edumazet,
vyasevic, hkchu, xemul, therbert, bhutchings, xii, stephen, jiri,
sergei shtylyov, Michael S. Tsirkin
In-Reply-To: <20141125.132717.122094133335261929.davem@davemloft.net>
>
> From: Pankaj Gupta <pagupta@redhat.com>
> Date: Tue, 25 Nov 2014 00:04:04 +0530
>
> > This patch switches to flex array to implement the flow caches, it brings
> > several advantages:
> >
> > - Reduce the size of the tun_struct structure, which allows us to increase
> > the
> > upper limit of queues in future.
> > - Avoid higher order memory allocation. It will be useful when switching to
> > pure hashing in flow cache which may demand a larger size array in
> > future.
> >
> > After this patch, the size of tun_struct on x86_64 reduced from 8512 to
> > 328
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> > Reviewed-by: David Gibson <dgibson@redhat.com>
>
> I see no reason to use flex arrays for this, you are preallocaing the
> memory so if anything flex array is adding an unnecessary level of
> redirection for every access in return for no real gains.
>
> Just allocate the thing normally using kzalloc() or whatever.
I agree. Will do the changes and submit v3.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH net-next V2] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
From: Jason Wang @ 2014-11-26 7:43 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: mst, Jason Wang, Eric Dumazet
To be more friendly with drop monitor, we should only call kfree_skb() when
the packets were dropped and use consume_skb() in other cases.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Changes from V1:
- check the return value of tun/macvtap_put_user()
---
drivers/net/macvtap.c | 5 ++++-
drivers/net/tun.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 42a80d3..c171ab6 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -862,7 +862,10 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
}
iov_iter_init(&iter, READ, iv, segs, len);
ret = macvtap_put_user(q, skb, &iter);
- kfree_skb(skb);
+ if (ret < 0)
+ kfree_skb(skb);
+ else
+ consume_skb(skb);
break;
}
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ac53a73..a21c130 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1363,7 +1363,10 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
iov_iter_init(&iter, READ, iv, segs, len);
ret = tun_put_user(tun, tfile, skb, &iter);
- kfree_skb(skb);
+ if (ret < 0)
+ kfree_skb(skb);
+ else
+ consume_skb(skb);
return ret;
}
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Jiri Pirko @ 2014-11-26 7:54 UTC (permalink / raw)
To: Thomas Graf
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <20141125221417.GF3912@casper.infradead.org>
Tue, Nov 25, 2014 at 11:14:17PM CET, tgraf@suug.ch wrote:
>On 11/25/14 at 11:28am, Jiri Pirko wrote:
>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass simple
>> u16 vid to drivers from there.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>I'm slightly confused ;-)
>
>We both argued that parsing Netlink attributes in the drivers is wrong.
>What happened to the plan of renaming ndo_fdb_ to ndo_neigh_ and
>introducing a non-Netlink in-kernel API for advanced usage by swdev?
Well the thing is that at the moment, it is not needed to call ndo_fdb_*
from inside the kernel. So the whole plan does not have to happen now.
Plus I saw the patches (Scott sent me) and I believe that they are
unnecessary complex. We can do this later if needed. Now, I would like
to stick with what we have so far, keep things simple.
^ permalink raw reply
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Jiri Pirko @ 2014-11-26 8:16 UTC (permalink / raw)
To: Scott Feldman
Cc: Florian Fainelli, Netdev, David S. Miller, nhorman@tuxdriver.com,
Andy Gospodarek, Thomas Graf, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim, Roopa Prabhu,
John Linville
In-Reply-To: <CAE4R7bCcB+HHDtULEdYA9uZUOtNJYL7edQQtfjh74wKQxxy-Lw@mail.gmail.com>
Wed, Nov 26, 2014 at 03:40:59AM CET, sfeldma@gmail.com wrote:
>On Tue, Nov 25, 2014 at 4:34 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 25/11/14 18:03, Scott Feldman wrote:
>>> On Tue, Nov 25, 2014 at 12:44 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>> On 25/11/14 02:28, Jiri Pirko wrote:
>>>>> From: Scott Feldman <sfeldma@gmail.com>
>>>>>
>>>>> When the swdev device learns a new mac/vlan on a port, it sends some async
>>>>> notification to the driver and the driver installs an FDB in the device.
>>>>> To give a holistic system view, the learned mac/vlan should be reflected
>>>>> in the bridge's FBD table, so the user, using normal iproute2 cmds, can view
>>>>> what is currently learned by the device. This API on the bridge driver gives
>>>>> a way for the swdev driver to install an FBD entry in the bridge FBD table.
>>>>> (And remove one).
>>>>>
>>>>> This is equivalent to the device running these cmds:
>>>>>
>>>>> bridge fdb [add|del] <mac> dev <dev> vid <vlan id> master
>>>>>
>>>>> This patch needs some extra eyeballs for review, in paricular around the
>>>>> locking and contexts.
>>>>>
>>>>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>>>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>>>> ---
>>>>
>>>> [snip]
>>>>
>>>>> + head = &br->hash[br_mac_hash(addr, vid)];
>>>>> + fdb = fdb_find(head, addr, vid);
>>>>> + if (!fdb) {
>>>>> + fdb = fdb_create(head, p, addr, vid);
>>>>> + if (!fdb) {
>>>>> + err = -ENOMEM;
>>>>> + goto err_unlock;
>>>>> + }
>>>>> + fdb->added_by_external_learn = 1;
>>>>> + fdb_notify(br, fdb, RTM_NEWNEIGH);
>>>>> + } else if (fdb->added_by_external_learn) {
>>>>> + /* Refresh entry */
>>>>> + fdb->updated = fdb->used = jiffies;
>>>>> + } else if (!fdb->added_by_user) {
>>>>> + /* Take over SW learned entry */
>>>>> + fdb->added_by_external_learn = 1;
>>>>> + fdb->updated = jiffies;
>>>>> + fdb_notify(br, fdb, RTM_NEWNEIGH);
>>>>> + }
>>>>
>>>> Is there any case where this fdb entry gets re-used and is no longer
>>>> added by an external learning? Should we clear this flag somewhere?
>>>
>>> Once the FDB entry is marked "added_by_external_learn" it stays marked
>>> as such until removed by aging cleanup process (or flushed due to
>>> interface down, etc). If aged out (and now deleted), the FDB entry
>>> may come back either by SW learn or by HW learn. If SW learn comes
>>> first, and then HW learn, HW learn will override and mark the existing
>>> FDB entry "added_by_external_learn". So there is take-over by HW but
>>> no give-back to SW. And there is no explicit clearing of the mark
>>> short of deleting the FDB entry. The mark is mostly for letting
>>> user's know which FDB entries where learned by HW and synced to the
>>> bridge's FDB.
>>
>> Thanks, makes sense now. This is probably obvious in this context, but
>> maybe it would not hurt to come up with a documentation that describe
>> the offload API, FDB entry lifetime and HW/SW ownership etc...
>
>I have an updated Documentation/networking/switchdev.txt that covers
>the swdev APIs and usage and notes, but Jiri is being stingy with it.
The doc update you mention includes also fib offload which we are not
pushing now. I have that patches in queue.
>Will get this out, either in v4 or follow-on patches. There is enough
>going on just with L2 offload that we're going to need some good
>documentation to guide implementers.
^ permalink raw reply
* Re: [PATCH 3/4] GMAC: dts: add gmac info for rk3288
From: Heiko Stübner @ 2014-11-26 8:47 UTC (permalink / raw)
To: Roger
Cc: Sergei Shtylyov, peppe.cavallaro, netdev, linux-kernel,
linux-rockchip, kever.yang, mark.yao, eddie.cai
In-Reply-To: <54753FAD.8040908@rock-chips.com>
Am Mittwoch, 26. November 2014, 10:49:17 schrieb Roger:
> On 2014/11/25 22:39, Heiko Stübner wrote:
> > Am Dienstag, 25. November 2014, 16:40:59 schrieb Sergei Shtylyov:
> >> Hello.
> >>
> >> On 11/25/2014 12:08 PM, Roger Chen wrote:
> >>> add gmac info in rk3288.dtsi for GMAC driver
> >>>
> >>> Signed-off-by: Roger Chen <roger.chen@rock-chips.com>
> >>> ---
> >>>
> >>> arch/arm/boot/dts/rk3288.dtsi | 59
> >>> +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59
> >>> insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/rk3288.dtsi
> >>> b/arch/arm/boot/dts/rk3288.dtsi
> >>> index 0f50d5d..949675d 100644
> >>> --- a/arch/arm/boot/dts/rk3288.dtsi
> >>> +++ b/arch/arm/boot/dts/rk3288.dtsi
> >>
> >> [...]
> >>
> >>> @@ -490,6 +497,25 @@
> >>>
> >>> reg = <0xff740000 0x1000>;
> >>>
> >>> };
> >>>
> >>> + gmac: eth@ff290000 {
> >>>
> >> Please name the node "ethernet@ff290000" to comply with the ePAPR
> >>
> >> standard.
> >>
> >>> + compatible = "rockchip,rk3288-gmac";
> >>> + reg = <0xff290000 0x10000>;
> >>> + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>; /*irq=59*/
> >>> + interrupt-names = "macirq";
> >>> + rockchip,grf = <&grf>;
> >>> + clocks = <&cru SCLK_MAC>, <&cru SCLK_MAC_PLL>,
> >>> + <&cru SCLK_MAC_RX>, <&cru SCLK_MAC_TX>,
> >>> + <&cru SCLK_MACREF>, <&cru SCLK_MACREF_OUT>,
> >>> + <&cru ACLK_GMAC>, <&cru PCLK_GMAC>;
> >>> + clock-names = "stmmaceth", "clk_mac_pll",
> >>> + "mac_clk_rx", "mac_clk_tx",
> >>> + "clk_mac_ref", "clk_mac_refout",
> >>> + "aclk_mac", "pclk_mac";
> >>> + phy-mode = "rgmii";
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&rgmii_pin /*&rmii_pin*/>;
> >>>
> >> Hm, pinctrl props in a .dtsi file? Those are usually board
> >> dependent.
> >
> > yep, especially as there is a board-dependent selection needed of what to
> > use [rgmii or rmii] depending on the phy on the board.
>
> of course pinctrl props is redefined in the rk3288-evb-rk808.dts,
> IMO, pinctrl props in .dtsi is used to fit for the "phy-mode" prop as
> default. if pinctrl props should be removed, how about "phy-mode" prop?
yep, the phy-mode should also move to the board file - as it of course also
depends on the phy-chip used there.
^ permalink raw reply
* [PATCH] x86: bpf_jit_comp: simplify trivial boolean return
From: Quentin Lambert @ 2014-11-26 9:18 UTC (permalink / raw)
To: David S. Miller
Cc: Quentin Lambert, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, netdev, linux-kernel
Remove if then else statements preceding
boolean return. Occurences were found using
Coccinelle.
The semantic patch used was:
@@
expression expr;
@@
- if ( expr )
- return true;
- else
- return false;
+ return expr;
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
---
arch/x86/net/bpf_jit_comp.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 3f62734..1542f39 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -135,11 +135,9 @@ static const int reg2hex[] = {
*/
static inline bool is_ereg(u32 reg)
{
- if (reg == BPF_REG_5 || reg == AUX_REG ||
- (reg >= BPF_REG_7 && reg <= BPF_REG_9))
- return true;
- else
- return false;
+ return (reg == BPF_REG_5 ||
+ reg == AUX_REG ||
+ (reg >= BPF_REG_7 && reg <= BPF_REG_9));
}
/* add modifiers if 'reg' maps to x64 registers r8..r15 */
^ permalink raw reply related
* [PATCH net-next] macvlan: delay the header check for dodgy packets into lower device
From: Jason Wang @ 2014-11-26 9:21 UTC (permalink / raw)
To: kaber, netdev, linux-kernel; +Cc: mst, vyasevic, Jason Wang
We do header check twice for a dodgy packet. One is done before
macvlan_start_xmit(), another is done before lower device's
ndo_start_xmit(). The first one seems redundant so this patch tries to
delay header check until a packet reaches its lower device (or macvtap)
through always enabling NETIF_F_GSO_ROBUST for macvlan device.
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvlan.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index bfb0b6e..11d4b35 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -742,11 +742,12 @@ static struct lock_class_key macvlan_netdev_xmit_lock_key;
static struct lock_class_key macvlan_netdev_addr_lock_key;
#define ALWAYS_ON_FEATURES \
- (NETIF_F_SG | NETIF_F_GEN_CSUM | NETIF_F_GSO_SOFTWARE | NETIF_F_LLTX)
+ (NETIF_F_SG | NETIF_F_GEN_CSUM | NETIF_F_GSO_SOFTWARE | NETIF_F_LLTX | \
+ NETIF_F_GSO_ROBUST)
#define MACVLAN_FEATURES \
(NETIF_F_SG | NETIF_F_ALL_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
- NETIF_F_GSO | NETIF_F_TSO | NETIF_F_UFO | NETIF_F_GSO_ROBUST | \
+ NETIF_F_GSO | NETIF_F_TSO | NETIF_F_UFO | \
NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next v3 16/17] bridge: add brport flags to dflt bridge_getlink
From: Jiri Pirko @ 2014-11-26 9:25 UTC (permalink / raw)
To: Thomas Graf
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <20141125220753.GD3912@casper.infradead.org>
Tue, Nov 25, 2014 at 11:07:53PM CET, tgraf@suug.ch wrote:
>On 11/25/14 at 11:28am, Jiri Pirko wrote:
>> From: Scott Feldman <sfeldma@gmail.com>
>>
>> To allow brport device to return current brport flags set on port. Add
>> returned flags to nested IFLA_PROTINFO netlink msg built in dflt getlink.
>> With this change, netlink msg returned for bridge_getlink contains the port's
>> offloaded flag settings (the port's SELF settings).
>>
>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>Minor nit below. Otherwise:
>
>Acked-by: Thomas Graf <tgraf@suug.ch>
>
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index bd5e783..91e5368 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -2687,12 +2687,22 @@ static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
>> return skb->len;
>> }
>>
>> +static int brport_nla_put_flag(struct sk_buff *skb, u32 flags, u32 mask,
>> + unsigned int attrnum, unsigned int flag)
>> +{
>> + if (mask & flag)
>> + return nla_put_u8(skb, attrnum, !!(flags & flag));
>
>nla_put_flag()?
No, that is not the same. nla_put_flag works differently. The attr is
either present or not. But in this case, attr is always present and has
value of either 0 or 1.
>
^ permalink raw reply
* [PATCH v2] net: netfilter: Fix undefined reference to nf_nat_redirect_* functions
From: Andreas Ruprecht @ 2014-11-26 9:35 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Patrick McHardy, Jozsef Kadlecsik, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel, Andreas Ruprecht
In-Reply-To: <1416928034-10882-1-git-send-email-rupran@einserver.de>
In a configuration with CONFIG_NFT_NAT and
CONFIG_NETFILTER_XT_TARGET_REDIRECT enabled, undefined references to
nf_nat_redirect_ipv{4,6}() can occur, when the corresponding options
CONFIG_NF_NAT_REDIRECT_IPV4 or CONFIG_NF_NAT_REDIRECT_IPV6 are not
enabled.
net/built-in.o: In function `redirect_tg4':
xt_REDIRECT.c:(.text+0x6d001): undefined reference to `nf_nat_redirect_ipv4'
net/built-in.o: In function `redirect_tg6':
xt_REDIRECT.c:(.text+0x6d021): undefined reference to `nf_nat_redirect_ipv6'
This is because the file xt_REDIRECT.c is compiled when
CONFIG_NETFILTER_XT_TARGET_REDIRECT is enabled, which only depends
on CONFIG_NF_NAT. This option is invisible and can only be selected by
other Kconfig options. In this particular case, it is selected by
CONFIG_NFT_NAT.
This patch changes the dependency for CONFIG_NETFILTER_XT_TARGET_REDIRECT
to only make it visible if at least one of
{CONFIG_NF_NAT_REDIRECT_IPV4, CONFIG_NF_NAT_REDIRECT_IPV6} are enabled.
Additionally it is necessary to provide stubs for the
nf_nat_redirect_ipv{4,6} functions in case the header is included but
the corresponding Kconfig feature is not enabled.
Changes:
v2: Correct capitalization for CONFIG_NF_NAT_REDIRECT_IPV4 in comment.
Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
---
include/net/netfilter/ipv4/nf_nat_redirect.h | 14 ++++++++++++++
include/net/netfilter/ipv6/nf_nat_redirect.h | 13 +++++++++++++
net/netfilter/Kconfig | 2 +-
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/include/net/netfilter/ipv4/nf_nat_redirect.h b/include/net/netfilter/ipv4/nf_nat_redirect.h
index 19e1df3a0a4d..56a506dd55cc 100644
--- a/include/net/netfilter/ipv4/nf_nat_redirect.h
+++ b/include/net/netfilter/ipv4/nf_nat_redirect.h
@@ -1,9 +1,23 @@
#ifndef _NF_NAT_REDIRECT_IPV4_H_
#define _NF_NAT_REDIRECT_IPV4_H_
+#include <linux/netfilter.h>
+
+#ifdef CONFIG_NF_NAT_REDIRECT_IPV4
unsigned int
nf_nat_redirect_ipv4(struct sk_buff *skb,
const struct nf_nat_ipv4_multi_range_compat *mr,
unsigned int hooknum);
+#else /* CONFIG_NF_NAT_REDIRECT_IPV4 */
+
+unsigned int
+nf_nat_redirect_ipv4(struct sk_buff *skb,
+ const struct nf_nat_ipv4_multi_range_compat *mr,
+ unsigned int hooknum)
+{
+ return NF_ACCEPT;
+}
+#endif /* CONFIG_NF_NAT_REDIRECT_IPV4 */
+
#endif /* _NF_NAT_REDIRECT_IPV4_H_ */
diff --git a/include/net/netfilter/ipv6/nf_nat_redirect.h b/include/net/netfilter/ipv6/nf_nat_redirect.h
index 1ebdffc461cc..4db9351120ec 100644
--- a/include/net/netfilter/ipv6/nf_nat_redirect.h
+++ b/include/net/netfilter/ipv6/nf_nat_redirect.h
@@ -1,8 +1,21 @@
#ifndef _NF_NAT_REDIRECT_IPV6_H_
#define _NF_NAT_REDIRECT_IPV6_H_
+#include <linux/netfilter.h>
+
+#ifdef CONFIG_NF_NAT_REDIRECT_IPV6
unsigned int
nf_nat_redirect_ipv6(struct sk_buff *skb, const struct nf_nat_range *range,
unsigned int hooknum);
+#else /* CONFIG_NF_NAT_REDIRECT_IPV6 */
+
+unsigned int
+nf_nat_redirect_ipv6(struct sk_buff *skb, const struct nf_nat_range *range,
+ unsigned int hooknum)
+{
+ return NF_ACCEPT;
+}
+#endif /* CONFIG_NF_NAT_REDIRECT_IPV6 */
+
#endif /* _NF_NAT_REDIRECT_IPV6_H_ */
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index be8db270aa77..0972851cce03 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -844,7 +844,7 @@ config NETFILTER_XT_TARGET_RATEEST
config NETFILTER_XT_TARGET_REDIRECT
tristate "REDIRECT target support"
- depends on NF_NAT
+ depends on NF_NAT_IPV4 || NF_NAT_IPV6
select NF_NAT_REDIRECT_IPV4 if NF_NAT_IPV4
select NF_NAT_REDIRECT_IPV6 if NF_NAT_IPV6
---help---
--
1.9.1
^ permalink raw reply related
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Michael Tokarev @ 2014-11-26 9:52 UTC (permalink / raw)
To: Arend van Spriel
Cc: Maximilian Engelhardt, Rafał Miłecki, Seth Forshee,
brcm80211 development, linux-wireless@vger.kernel.org,
Network Development
In-Reply-To: <5471AC29.6040009@broadcom.com>
I'm sorry this took so long - I was AFK during weekend and had
to deal with a huge backlog after that. Now it is all sorted.
23.11.2014 12:43, Arend van Spriel wrote:
> On 19-11-14 22:00, Michael Tokarev wrote:
[]
> Well, it shows tx looks ok, but with download there is not much of that
> going on. At least no large packets. However, I did find some missing
> pieces related to bt-coex. Given that you device is a wifi-bt combo card
> that is likely an issue for you. One of the missing pieces looks in
> sprom for parameters and that is provided by bcma. However, it does not
> seem to extract bt-coex related stuff. So I have attached a patch based
> on 3.18-rc5 for bcma that dumps the sprom contents. Could you sent that
> content to me.
Here we go. I had to replace pr_debug with pr_err - haven't looked yet,
but the thing is that pr_debug isn't even being compiled into the kernel
here, all the messages are not present in the compiled modules.
[ 525.693474] bcma: bcmasprom:
[ 525.693528] bcma:
[ 525.693592] bcma: 2801
[ 525.693613] bcma: 0000
[ 525.693659] bcma: 1795
[ 525.693679] bcma: 103C
[ 525.693725] bcma: 0070
[ 525.693746] bcma: EDBE
[ 525.693791] bcma: 0000
[ 525.693811] bcma: 2BC4
[ 525.693856] bcma: 2A64
[ 525.693877] bcma: 2964
[ 525.693922] bcma:
[ 525.693938] bcma: 2C64
[ 525.693984] bcma: 3CE7
[ 525.694004] bcma: 46FF
[ 525.694049] bcma: 47FF
[ 525.694070] bcma: 0C00
[ 525.694115] bcma: 0820
[ 525.694136] bcma: 0030
[ 525.694181] bcma: 1002
[ 525.694202] bcma: 9F28
[ 525.694247] bcma: 5D44
[ 525.694267] bcma:
[ 525.694329] bcma: 8080
[ 525.694349] bcma: 1D8F
[ 525.694395] bcma: 0032
[ 525.694415] bcma: 0100
[ 525.694461] bcma: DF00
[ 525.694481] bcma: 71F5
[ 525.694526] bcma: 8400
[ 525.694547] bcma: 0083
[ 525.694592] bcma: 8500
[ 525.694613] bcma: 2010
[ 525.694658] bcma:
[ 525.694674] bcma: 0001
[ 525.694719] bcma: 0000
[ 525.694740] bcma: 0000
[ 525.694785] bcma: 0000
[ 525.694805] bcma: 0000
[ 525.694850] bcma: 0000
[ 525.694871] bcma: 0000
[ 525.694916] bcma: 0000
[ 525.694937] bcma: 0000
[ 525.694982] bcma: 0000
[ 525.695002] bcma:
[ 525.695063] bcma: 0000
[ 525.695084] bcma: 0000
[ 525.695129] bcma: 1008
[ 525.695150] bcma: 0305
[ 525.695195] bcma: 0000
[ 525.695215] bcma: 0000
[ 525.695261] bcma: 0000
[ 525.695281] bcma: 0000
[ 525.695326] bcma: 4727
[ 525.695347] bcma: 8000
[ 525.695392] bcma:
[ 525.695409] bcma: 0002
[ 525.695454] bcma: 0000
[ 525.695474] bcma: 1800
[ 525.695520] bcma: 1800
[ 525.695561] bcma: 0000
[ 525.695610] bcma: 0000
[ 525.695631] bcma: 0000
[ 525.695677] bcma: 0000
[ 525.695698] bcma: 0000
[ 525.695746] bcma: 0000
[ 525.695766] bcma:
[ 525.695827] bcma: 0000
[ 525.695848] bcma: 0000
[ 525.695893] bcma: 0000
[ 525.695914] bcma: 0000
[ 525.695961] bcma: 5372
[ 525.695982] bcma: 1107
[ 525.696027] bcma: 2201
[ 525.696048] bcma: 0040
[ 525.696093] bcma: 0884
[ 525.696116] bcma: 0000
[ 525.696161] bcma:
[ 525.696178] bcma: E006
[ 525.696223] bcma: E659
[ 525.696244] bcma: 5F5A
[ 525.696290] bcma: 5856
[ 525.696310] bcma: 0001
[ 525.696356] bcma: FFFF
[ 525.696376] bcma: 83FF
[ 525.696422] bcma: FFFF
[ 525.696443] bcma: 0003
[ 525.696488] bcma: 0202
[ 525.696508] bcma:
[ 525.696570] bcma: FFFF
[ 525.696590] bcma: 0011
[ 525.698381] bcma: 017A
[ 525.698402] bcma: 0000
[ 525.700181] bcma: 0000
[ 525.700202] bcma: 0000
[ 525.701936] bcma: 0000
[ 525.701957] bcma: 0201
[ 525.703650] bcma: 0000
[ 525.703672] bcma: 7800
[ 525.705278] bcma:
[ 525.706808] bcma: 6410
[ 525.708296] bcma: E398
[ 525.708318] bcma: 0008
[ 525.709774] bcma: 0000
[ 525.709796] bcma: 0000
[ 525.711186] bcma: 0000
[ 525.711207] bcma: 0044
[ 525.712532] bcma: 2400
[ 525.712556] bcma: FCF7
[ 525.713867] bcma: 0089
[ 525.713888] bcma:
[ 525.716500] bcma: 0000
[ 525.716524] bcma: 0000
[ 525.717834] bcma: 0000
[ 525.717855] bcma: 0000
[ 525.719195] bcma: 0000
[ 525.719217] bcma: 0000
[ 525.720530] bcma: 0000
[ 525.720551] bcma: 0000
[ 525.721862] bcma: 0000
[ 525.721882] bcma: 0000
[ 525.723176] bcma:
[ 525.724400] bcma: 0000
[ 525.725678] bcma: 0000
[ 525.725699] bcma: 0048
[ 525.726996] bcma: FED2
[ 525.727017] bcma: 15D9
[ 525.728308] bcma: FAC6
[ 525.728329] bcma: 0000
[ 525.729642] bcma: 0000
[ 525.729664] bcma: 0000
[ 525.730958] bcma: 0000
[ 525.730978] bcma:
[ 525.733526] bcma: 0000
[ 525.733549] bcma: 0000
[ 525.734827] bcma: 0000
[ 525.734848] bcma: 0000
[ 525.736155] bcma: 0000
[ 525.736179] bcma: 0000
[ 525.737466] bcma: 0000
[ 525.737487] bcma: 0000
[ 525.738764] bcma: 0000
[ 525.738785] bcma: 0000
[ 525.740049] bcma:
[ 525.741240] bcma: 0000
[ 525.742501] bcma: 0000
[ 525.742522] bcma: 0000
[ 525.743806] bcma: 0000
[ 525.743827] bcma: 0000
[ 525.745111] bcma: 0000
[ 525.745132] bcma: 0000
[ 525.746433] bcma: 0000
[ 525.746456] bcma: 0000
[ 525.747725] bcma: 0000
[ 525.747746] bcma:
[ 525.750251] bcma: 0000
[ 525.750272] bcma: 0000
[ 525.751532] bcma: 0000
[ 525.751553] bcma: 0000
[ 525.752847] bcma: 0000
[ 525.752871] bcma: 0000
[ 525.754150] bcma: 0000
[ 525.754171] bcma: 0000
[ 525.755441] bcma: 0000
[ 525.755462] bcma: 0000
[ 525.756717] bcma:
[ 525.757900] bcma: 0000
[ 525.759148] bcma: 0000
[ 525.759170] bcma: 0000
[ 525.760436] bcma: 0000
[ 525.760457] bcma: 0000
[ 525.761720] bcma: 0000
[ 525.761741] bcma: 0000
[ 525.763023] bcma: 0000
[ 525.763047] bcma: 0000
[ 525.764301] bcma: 0000
[ 525.764321] bcma:
[ 525.766790] bcma: 0000
[ 525.766813] bcma: 1111
[ 525.768057] bcma: 1111
[ 525.768078] bcma: 0000
[ 525.769355] bcma: 0000
[ 525.769378] bcma: 0000
[ 525.770631] bcma: 0000
[ 525.770652] bcma: 0000
[ 525.771898] bcma: 0000
[ 525.771919] bcma: 2222
[ 525.773158] bcma:
[ 525.774325] bcma: 3222
[ 525.775540] bcma: 0000
[ 525.775561] bcma: 0000
[ 525.776816] bcma: 0000
[ 525.776840] bcma: 0000
[ 525.778089] bcma: 0000
[ 525.778110] bcma: 0000
[ 525.779355] bcma: 0000
[ 525.779380] bcma: 0000
[ 525.780600] bcma: 0000
[ 525.780621] bcma:
[ 525.783015] bcma: 0000
[ 525.783038] bcma: 0000
[ 525.784247] bcma: 0000
[ 525.784268] bcma: 0000
[ 525.785500] bcma: 0000
[ 525.785521] bcma: 0000
[ 525.786759] bcma: 0000
[ 525.786781] bcma: 0000
[ 525.787995] bcma: 0000
[ 525.788016] bcma: 0000
[ 525.789217] bcma:
[ 525.790337] bcma: 0000
[ 525.791505] bcma: 0000
[ 525.791525] bcma: 0000
[ 525.792740] bcma: 0000
[ 525.792765] bcma: 0000
[ 525.793965] bcma: 0000
[ 525.793986] bcma: 0000
[ 525.795168] bcma: 0000
[ 525.795189] bcma: 0000
[ 525.796375] bcma: 0000
[ 525.796399] bcma:
[ 525.798682] bcma: 0000
[ 525.798703] bcma: 0000
[ 525.799885] bcma: 0000
[ 525.799906] bcma: 0000
[ 525.801038] bcma: 0000
[ 525.801058] bcma: 0000
[ 525.802177] bcma: 0000
[ 525.802197] bcma: 0000
[ 525.803320] bcma: 0000
[ 525.803340] bcma: 0000
[ 525.804433] bcma:
[ 525.805460] bcma: 0000
[ 525.806547] bcma: 0000
[ 525.806567] bcma: 0000
[ 525.807671] bcma: 0000
[ 525.807691] bcma: 0000
[ 525.808777] bcma: 0000
[ 525.808796] bcma: 0000
[ 525.809899] bcma: 0000
[ 525.809919] bcma: 0000
[ 525.821789] bcma: bus0: Bus registered
Thanks,
/mjt
^ permalink raw reply
* [PATCH net] r8152: drop the tx packet with invalid length
From: Hayes Wang @ 2014-11-26 9:56 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Drop the tx packet which is more than the size of agg_buf_sz. When
creating a bridge with the device, we may get the tx packet with
TSO and the length is more than the gso_max_size which is set by
the driver through netif_set_gso_max_size(). Such packets couldn't
be transmitted and should be dropped directly.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c6554c7..ebdaff7 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1897,6 +1897,15 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb,
{
struct r8152 *tp = netdev_priv(netdev);
+ if ((skb->len + sizeof(struct tx_desc)) > agg_buf_sz) {
+ struct net_device_stats *stats = &netdev->stats;
+
+ dev_kfree_skb_any(skb);
+ stats->tx_dropped++;
+ WARN_ON_ONCE(1);
+ return NETDEV_TX_OK;
+ }
+
skb_tx_timestamp(skb);
skb_queue_tail(&tp->tx_queue, skb);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v2] net: netfilter: Fix undefined reference to nf_nat_redirect_* functions
From: Florian Westphal @ 2014-11-26 10:24 UTC (permalink / raw)
To: Andreas Ruprecht
Cc: Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <1416994537-1592-1-git-send-email-rupran@einserver.de>
Andreas Ruprecht <rupran@einserver.de> wrote:
> Additionally it is necessary to provide stubs for the
> nf_nat_redirect_ipv{4,6} functions in case the header is included but
> the corresponding Kconfig feature is not enabled.
Hmmm, not following.
Can you elaborate?
Under which circumstances do we have a call to nf_nat_redirect_ipv4()
(i.e., linker error) but can safely do a noop operation instead of the
requested nat redirect...?
^ permalink raw reply
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Jiri Pirko @ 2014-11-26 10:26 UTC (permalink / raw)
To: Scott Feldman
Cc: Thomas Graf, Andy Gospodarek, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim,
Florian Fainelli, Roopa Prabhu
In-Reply-To: <CAE4R7bApe59sT6G2oORWP=jOOy=h=Da=EQq98fzR1s+ESZOGFQ@mail.gmail.com>
Wed, Nov 26, 2014 at 02:48:04AM CET, sfeldma@gmail.com wrote:
>On Tue, Nov 25, 2014 at 12:36 PM, Thomas Graf <tgraf@suug.ch> wrote:
>> On 11/25/14 at 11:38am, Andy Gospodarek wrote:
>>> On Tue, Nov 25, 2014 at 11:28:40AM +0100, Jiri Pirko wrote:
>>> > From: Scott Feldman <sfeldma@gmail.com>
>>> >
>>> > When the swdev device learns a new mac/vlan on a port, it sends some async
>>> > notification to the driver and the driver installs an FDB in the device.
>>> > To give a holistic system view, the learned mac/vlan should be reflected
>>> > in the bridge's FBD table, so the user, using normal iproute2 cmds, can view
>>> > what is currently learned by the device. This API on the bridge driver gives
>>> > a way for the swdev driver to install an FBD entry in the bridge FBD table.
>>> > (And remove one).
>>> >
>>> > This is equivalent to the device running these cmds:
>>> >
>>> > bridge fdb [add|del] <mac> dev <dev> vid <vlan id> master
>>> >
>>> > This patch needs some extra eyeballs for review, in paricular around the
>>> > locking and contexts.
>>> >
>>> > Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>>> > Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>
>> I like the simplicity of this. That said, given we'll have multiple
>> users of swdev including OVS, shouldn't this be a notifier or a
>> callback that depends on who is controlling the device?
>
>I like the idea. When the switch port joins Linux bridge or OVS
>datapath, a callback is registered with the driver. That way the
>driver doesn't really care if the port is a bridge member or an OVS
>vport in a datapath. It's just passing up the FDB entry
>(port/mac/vlan) details to the container device. Can we hold this
>idea until this patchset sticks? I think once OVS support comes back
>into the swdev model would be the time to address this.
Yep, I agree this is a good idea and I also vote for implemeting this as
a follow-up. Thanks.
>
>>
>>> > + spin_lock(&br->hash_lock);
>>> (Since you asked to check locking...)
>>>
>>> Most of the other fdb_add/delete/insert/update calls take this with
>>> spin_lock_bh. Did you try this with lockdep enabled just to see if that
>>> is needed here? I suspect that anytime br->hash_lock is taken it will
>>> need to be with softirqs disabled from this point forward.
>>
>> At least br_fdb_update() seems to be called from BH context so I would
>> agree and argue the lock in br_fdb_cleanup() and br_fdb_update() need a
>> fix too. I'll send a patch.
^ permalink raw reply
* Re: [PATCH v2] net: netfilter: Fix undefined reference to nf_nat_redirect_* functions
From: Andreas Ruprecht @ 2014-11-26 10:33 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20141126102402.GA24801@breakpoint.cc>
Sure.
When the file is compiled, i.e. CONFIG_NETFILTER_XT_TARGET_REDIRECT is
selected, all headers will be included and all functions inside the file
will be compiled, regardless of other Kconfig options.
This means redirect_tg6 and redirect_tg4 will be compiled (which doesn't
necessarily mean they will be _called_) but the linker needs to resolve
nf_nat_redirect_ipv4() due to the compilation of the redirect_tg4()
function.
nf_nat_redirect_ip4() is defined in
net/ipv4/netfilter/nf_nat_redirect_ipv4.c but this file is only included
into the build when CONFIG_NF_NAT_REDIRECT_IPV4 is enabled.
Now when a kernel config enables CONFIG_NETFILTER_XT_TARGET_REDIRECT but
_not_ CONFIG_NF_NAT_REDIRECT_IPV4, the declaration of
nf_nat_redirect_ipv4() from the header
<net/netfilter/ipv4/nf_nat_redirect.h> will have no definition (i.e., no
implementation), causing the linker to report an "undefined reference".
Same logic goes for nf_nat_redirect_ipv6().
Hope this helps,
Andreas
On 26.11.2014 11:24, Florian Westphal wrote:
> Andreas Ruprecht <rupran@einserver.de> wrote:
>> Additionally it is necessary to provide stubs for the
>> nf_nat_redirect_ipv{4,6} functions in case the header is included but
>> the corresponding Kconfig feature is not enabled.
>
> Hmmm, not following.
>
> Can you elaborate?
>
> Under which circumstances do we have a call to nf_nat_redirect_ipv4()
> (i.e., linker error) but can safely do a noop operation instead of the
> requested nat redirect...?
>
^ permalink raw reply
* Re: [patch net-next v3 16/17] bridge: add brport flags to dflt bridge_getlink
From: Thomas Graf @ 2014-11-26 10:48 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <20141126092512.GE1875@nanopsycho.orion>
On 11/26/14 at 10:25am, Jiri Pirko wrote:
> Tue, Nov 25, 2014 at 11:07:53PM CET, tgraf@suug.ch wrote:
> >> +static int brport_nla_put_flag(struct sk_buff *skb, u32 flags, u32 mask,
> >> + unsigned int attrnum, unsigned int flag)
> >> +{
> >> + if (mask & flag)
> >> + return nla_put_u8(skb, attrnum, !!(flags & flag));
> >
> >nla_put_flag()?
>
> No, that is not the same. nla_put_flag works differently. The attr is
> either present or not. But in this case, attr is always present and has
> value of either 0 or 1.
So this reports the driver capabilities through this interface as
well. Cool. Wasn't obvious to me before but that justifies the waste.
^ permalink raw reply
* Re: [patch net-next v3 17/17] rocker: add ndo_bridge_setlnk/getlink support for learning policy
From: Thomas Graf @ 2014-11-26 11:07 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1416911328-10979-18-git-send-email-jiri@resnulli.us>
On 11/25/14 at 11:28am, Jiri Pirko wrote:
> @@ -3657,6 +3693,64 @@ skip:
> return idx;
> }
>
> +static int rocker_port_bridge_setlink(struct net_device *dev,
> + struct nlmsghdr *nlh)
> +{
> + struct rocker_port *rocker_port = netdev_priv(dev);
> + struct nlattr *protinfo;
> + struct nlattr *afspec;
> + struct nlattr *attr;
> + u16 mode;
> + int err;
> +
> + protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
> + IFLA_PROTINFO);
> + afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
> +
> + if (afspec) {
> + attr = nla_find_nested(afspec, IFLA_BRIDGE_MODE);
> + if (attr) {
> + mode = nla_get_u16(attr);
> + if (mode != BRIDGE_MODE_SWDEV)
> + return -EINVAL;
> + }
> + }
The Netlink message is completely unverified at this point. All
rtnl_bridge_setlink() does is verify that msgsize >= ifinfomsg.
All of the drivers but br_setlink() need fixing in this regard.
^ permalink raw reply
* Re: [PATCH v2] net: netfilter: Fix undefined reference to nf_nat_redirect_* functions
From: Pablo Neira Ayuso @ 2014-11-26 11:24 UTC (permalink / raw)
To: Andreas Ruprecht
Cc: Florian Westphal, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <5475AC6F.9010902@einserver.de>
On Wed, Nov 26, 2014 at 11:33:19AM +0100, Andreas Ruprecht wrote:
> Sure.
>
> When the file is compiled, i.e. CONFIG_NETFILTER_XT_TARGET_REDIRECT is
> selected, all headers will be included and all functions inside the file
> will be compiled, regardless of other Kconfig options.
>
> This means redirect_tg6 and redirect_tg4 will be compiled (which doesn't
> necessarily mean they will be _called_) but the linker needs to resolve
> nf_nat_redirect_ipv4() due to the compilation of the redirect_tg4()
> function.
>
> nf_nat_redirect_ip4() is defined in
> net/ipv4/netfilter/nf_nat_redirect_ipv4.c but this file is only included
> into the build when CONFIG_NF_NAT_REDIRECT_IPV4 is enabled.
>
> Now when a kernel config enables CONFIG_NETFILTER_XT_TARGET_REDIRECT but
> _not_ CONFIG_NF_NAT_REDIRECT_IPV4, the declaration of
> nf_nat_redirect_ipv4() from the header
> <net/netfilter/ipv4/nf_nat_redirect.h> will have no definition (i.e., no
> implementation), causing the linker to report an "undefined reference".
>
> Same logic goes for nf_nat_redirect_ipv6().
I'd suggest alternatives to resolve this problem:
1) Split xt_REDIRECT into ipt_REDIRECT and ip6t_REDIRECT, so we
restore the state of how this was back in 2012. The main motivation
behind that change was to reduce memory consumption by combining both
modules. In other modules, these combinations have been causing us
problems specifically when IPv6 symbols are used and it's not that
clean since IPv6 specific code remains there unused in the module even
if CONFIG_IPV6=n.
2) Merge nf_nat_redirect_ipv4 and nf_nat_redirect_ipv6 into
nf_nat_redirect, so we inconditionally build IPv6 redirect code, thus
xt_REDIRECT always finds the IPv6 symbol that needs even if it doesn't
use it.
3) Add #ifdef to xt_REDIRECT.c to make IPv6 specific code, this should
be a simple and small patch, but it results in #ifdef pollution.
Comments?
Thanks.
^ permalink raw reply
* Re: [PATCH v2] net: netfilter: Fix undefined reference to nf_nat_redirect_* functions
From: Florian Westphal @ 2014-11-26 11:26 UTC (permalink / raw)
To: Andreas Ruprecht
Cc: Florian Westphal, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller, netfilter-devel, coreteam,
netdev, linux-kernel
In-Reply-To: <5475AC6F.9010902@einserver.de>
Andreas Ruprecht <rupran@einserver.de> wrote:
> When the file is compiled, i.e. CONFIG_NETFILTER_XT_TARGET_REDIRECT is
> selected, all headers will be included and all functions inside the file
> will be compiled, regardless of other Kconfig options.
>
> This means redirect_tg6 and redirect_tg4 will be compiled (which doesn't
> necessarily mean they will be _called_) but the linker needs to resolve
> nf_nat_redirect_ipv4() due to the compilation of the redirect_tg4()
> function.
So the problem is eg.
CONFIG_NETFILTER_XT_TARGET_REDIRECT=y
CONFIG_NF_NAT_IPV4=n
which yields
undefined reference to `nf_nat_redirect_ipv4'
adding stub fixes this; we will still register a netfilter target for
ipv4 redirect, but it cannot be called ever since that target is
resticted to 'nat' table, which doesn't exist for ipv4 in the above
config.
To me it seem cleaner to put
IS_ENABLED(NF_NAT_REDIRECT_IPV4)
into xt_REDIRECT.c instead of building not-working-but-never-called
ipv4 redirect.
Pablo, if you disagree I am fine with the patch, although
the stubs should get a 'static inline' prefix to not cause sym clash
in case we ever gain another call site.
^ permalink raw reply
* Re: [patch net-next v3 17/17] rocker: add ndo_bridge_setlnk/getlink support for learning policy
From: Jiri Pirko @ 2014-11-26 11:27 UTC (permalink / raw)
To: Thomas Graf
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <20141126110709.GC4321@casper.infradead.org>
Wed, Nov 26, 2014 at 12:07:09PM CET, tgraf@suug.ch wrote:
>On 11/25/14 at 11:28am, Jiri Pirko wrote:
>> @@ -3657,6 +3693,64 @@ skip:
>> return idx;
>> }
>>
>> +static int rocker_port_bridge_setlink(struct net_device *dev,
>> + struct nlmsghdr *nlh)
>> +{
>> + struct rocker_port *rocker_port = netdev_priv(dev);
>> + struct nlattr *protinfo;
>> + struct nlattr *afspec;
>> + struct nlattr *attr;
>> + u16 mode;
>> + int err;
>> +
>> + protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
>> + IFLA_PROTINFO);
>> + afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
>> +
>> + if (afspec) {
>> + attr = nla_find_nested(afspec, IFLA_BRIDGE_MODE);
>> + if (attr) {
>> + mode = nla_get_u16(attr);
>> + if (mode != BRIDGE_MODE_SWDEV)
>> + return -EINVAL;
>> + }
>> + }
>
>The Netlink message is completely unverified at this point. All
>rtnl_bridge_setlink() does is verify that msgsize >= ifinfomsg.
>All of the drivers but br_setlink() need fixing in this regard.
I believe that we should fix this for all drivers in a follow-up patch.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox