* [PATCH 3/6] bcm63xx_enet: do not rely on probe order
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
To: netdev, linux-arm-kernel, linux-kernel
Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
In-Reply-To: <20171001110220.27668-1-jonas.gorski@gmail.com>
Do not rely on the shared device being probed before the enet(sw)
devices. This makes it easier to eventually move out the shared
device as a dma controller driver (what it should be).
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index a1e1e12e187a..8caf6abab3a6 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1722,10 +1722,8 @@ static int bcm_enet_probe(struct platform_device *pdev)
const char *clk_name;
int i, ret;
- /* stop if shared driver failed, assume driver->probe will be
- * called in the same order we register devices (correct ?) */
if (!bcm_enet_shared_base[0])
- return -ENODEV;
+ return -EPROBE_DEFER;
res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
res_irq_rx = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
@@ -2696,11 +2694,8 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
struct resource *res_mem;
int ret, irq_rx, irq_tx;
- /* stop if shared driver failed, assume driver->probe will be
- * called in the same order we register devices (correct ?)
- */
if (!bcm_enet_shared_base[0])
- return -ENODEV;
+ return -EPROBE_DEFER;
res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
irq_rx = platform_get_irq(pdev, 0);
--
2.13.2
^ permalink raw reply related
* [PATCH 2/6] bcm63xx_enet: do not write to random DMA channel on BCM6345
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
To: netdev, linux-arm-kernel, linux-kernel
Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
In-Reply-To: <20171001110220.27668-1-jonas.gorski@gmail.com>
The DMA controller regs actually point to DMA channel 0, so the write to
ENETDMA_CFG_REG will actually modify a random DMA channel.
Since DMA controller registers do not exist on BCM6345, guard the write
with the usual check for dma_has_sram.
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index a45ec97b5b1e..a1e1e12e187a 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1062,7 +1062,8 @@ static int bcm_enet_open(struct net_device *dev)
val = enet_readl(priv, ENET_CTL_REG);
val |= ENET_CTL_ENABLE_MASK;
enet_writel(priv, val, ENET_CTL_REG);
- enet_dma_writel(priv, ENETDMA_CFG_EN_MASK, ENETDMA_CFG_REG);
+ if (priv->dma_has_sram)
+ enet_dma_writel(priv, ENETDMA_CFG_EN_MASK, ENETDMA_CFG_REG);
enet_dmac_writel(priv, priv->dma_chan_en_mask,
ENETDMAC_CHANCFG, priv->rx_chan);
--
2.13.2
^ permalink raw reply related
* [PATCH 1/6] bcm63xx_enet: correct clock usage
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
To: netdev, linux-arm-kernel, linux-kernel
Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
In-Reply-To: <20171001110220.27668-1-jonas.gorski@gmail.com>
Check the return code of prepare_enable and change one last instance of
enable only to prepare_enable. Also properly disable and release the
clock in error paths and on remove for enetsw.
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 31 +++++++++++++++++++++-------
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index c6221f04a748..a45ec97b5b1e 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1773,7 +1773,9 @@ static int bcm_enet_probe(struct platform_device *pdev)
ret = PTR_ERR(priv->mac_clk);
goto out;
}
- clk_prepare_enable(priv->mac_clk);
+ ret = clk_prepare_enable(priv->mac_clk);
+ if (ret)
+ goto out_put_clk_mac;
/* initialize default and fetch platform data */
priv->rx_ring_size = BCMENET_DEF_RX_DESC;
@@ -1805,9 +1807,11 @@ static int bcm_enet_probe(struct platform_device *pdev)
if (IS_ERR(priv->phy_clk)) {
ret = PTR_ERR(priv->phy_clk);
priv->phy_clk = NULL;
- goto out_put_clk_mac;
+ goto out_disable_clk_mac;
}
- clk_prepare_enable(priv->phy_clk);
+ ret = clk_prepare_enable(priv->phy_clk);
+ if (ret)
+ goto out_put_clk_phy;
}
/* do minimal hardware init to be able to probe mii bus */
@@ -1900,13 +1904,16 @@ static int bcm_enet_probe(struct platform_device *pdev)
out_uninit_hw:
/* turn off mdc clock */
enet_writel(priv, 0, ENET_MIISC_REG);
- if (priv->phy_clk) {
+ if (priv->phy_clk)
clk_disable_unprepare(priv->phy_clk);
+
+out_put_clk_phy:
+ if (priv->phy_clk)
clk_put(priv->phy_clk);
- }
-out_put_clk_mac:
+out_disable_clk_mac:
clk_disable_unprepare(priv->mac_clk);
+out_put_clk_mac:
clk_put(priv->mac_clk);
out:
free_netdev(dev);
@@ -2748,7 +2755,9 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
ret = PTR_ERR(priv->mac_clk);
goto out_unmap;
}
- clk_enable(priv->mac_clk);
+ ret = clk_prepare_enable(priv->mac_clk);
+ if (ret)
+ goto out_put_clk;
priv->rx_chan = 0;
priv->tx_chan = 1;
@@ -2769,7 +2778,7 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
ret = register_netdev(dev);
if (ret)
- goto out_put_clk;
+ goto out_disable_clk;
netif_carrier_off(dev);
platform_set_drvdata(pdev, dev);
@@ -2778,6 +2787,9 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
return 0;
+out_disable_clk:
+ clk_disable_unprepare(priv->mac_clk);
+
out_put_clk:
clk_put(priv->mac_clk);
@@ -2809,6 +2821,9 @@ static int bcm_enetsw_remove(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(res->start, resource_size(res));
+ clk_disable_unprepare(priv->mac_clk);
+ clk_put(priv->mac_clk);
+
free_netdev(dev);
return 0;
}
--
2.13.2
^ permalink raw reply related
* [PATCH 0/6] bcm63xx_enet: small fixes and cleanups
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
To: netdev, linux-arm-kernel, linux-kernel
Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
This patch set fixes a few theoretical issues and cleans up the code a
bit. It also adds a bit more managed function usage to simplify clock
and iomem usage.
Based on net-next.
Jonas Gorski (6):
bcm63xx_enet: correct clock usage
bcm63xx_enet: do not write to random DMA channel on BCM6345
bcm63xx_enet: do not rely on probe order
bcm63xx_enet: use managed functions for clock/ioremap
bcm63xx_enet: drop unneeded NULL phy_clk check
bcm63xx_enet: remove unneeded include
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 78 ++++++++++------------------
drivers/net/ethernet/broadcom/bcm63xx_enet.h | 1 -
2 files changed, 28 insertions(+), 51 deletions(-)
--
2.13.2
^ permalink raw reply
* Re: [PATCH net-next] net: ipv4: remove fib_info arg to fib_check_nh
From: Sergei Shtylyov @ 2017-10-01 10:44 UTC (permalink / raw)
To: David Ahern, netdev
In-Reply-To: <1506570119-17088-1-git-send-email-dsahern@gmail.com>
Hello!
On 9/28/2017 6:41 AM, David Ahern wrote:
> fib_check_nh does not use the fib_info arg; remove t.
s/t/it/. :-)
> Signed-off-by: David Ahern <dsahern@gmail.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [patch net-next 3/7] ipv4: ipmr: Don't forward packets already forwarded by hardware
From: Yotam Gigi @ 2017-10-01 8:51 UTC (permalink / raw)
To: Florian Fainelli, Jiri Pirko, netdev
Cc: davem, idosch, mlxsw, nikolay, andrew, dsa, edumazet, willemb,
johannes.berg, dcaratti, pabeni, daniel, fw, gfree.wind
In-Reply-To: <bb37f353-8f15-f570-a35e-ed76c56f1180@gmail.com>
On 09/28/2017 08:56 PM, Florian Fainelli wrote:
> On 09/28/2017 10:34 AM, Jiri Pirko wrote:
>> From: Yotam Gigi <yotamg@mellanox.com>
>>
>> Change the ipmr module to not forward packets if:
>> - The packet is marked with the offload_mr_fwd_mark, and
>> - Both input interface and output interface share the same parent ID.
>>
>> This way, a packet can go through partial multicast forwarding in the
>> hardware, where it will be forwarded only to the devices that share the
>> same parent ID (AKA, reside inside the same hardware). The kernel will
>> forward the packet to all other interfaces.
>>
>> To do this, add the ipmr_offload_forward helper, which per skb, ingress VIF
>> and egress VIF, returns whether the forwarding was offloaded to hardware.
>> The ipmr_queue_xmit frees the skb and does not forward it if the result is
>> a true value.
>>
>> All the forwarding path code compiles out when the CONFIG_NET_SWITCHDEV is
>> not set.
>>
>> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
>> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>> net/ipv4/ipmr.c | 37 ++++++++++++++++++++++++++++++++-----
>> 1 file changed, 32 insertions(+), 5 deletions(-)
>>
>> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
>> index 4566c54..deba569 100644
>> --- a/net/ipv4/ipmr.c
>> +++ b/net/ipv4/ipmr.c
>> @@ -1857,10 +1857,33 @@ static inline int ipmr_forward_finish(struct net *net, struct sock *sk,
>> return dst_output(net, sk, skb);
>> }
>>
>> +#ifdef CONFIG_NET_SWITCHDEV
>> +static bool ipmr_forward_offloaded(struct sk_buff *skb, struct mr_table *mrt,
>> + int in_vifi, int out_vifi)
>> +{
>> + struct vif_device *out_vif = &mrt->vif_table[out_vifi];
>> + struct vif_device *in_vif = &mrt->vif_table[in_vifi];
> Nit: in_vifi and out_vifi may be better named as in_vif_idx and
> out_vif_idx, oh well you are just replicating the existing naming
> conventions used down below, never mind then.
Yes, unfortunately, the acronym "vifi" is pretty common in the file. I would
also prefer something like vif_index, but vifi would better match the current
convention in the code.
^ permalink raw reply
* Re: [PATCH RFC 3/5] Add KSZ8795 switch driver
From: Pavel Machek @ 2017-10-01 7:21 UTC (permalink / raw)
To: Tristram.Ha
Cc: andrew, muvarov, nathan.leigh.conrad, vivien.didelot, f.fainelli,
netdev, linux-kernel, Woojung.Huh
In-Reply-To: <93AF473E2DA327428DE3D46B72B1E9FD4112CBC8@CHN-SV-EXMX02.mchp-main.com>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Fri 2017-09-29 18:45:19, Tristram.Ha@microchip.com wrote:
> > > > > > Similar code will be needed by other drivers, right?
> > > > >
> > > > > Although KSZ8795 and KSZ8895 may use the same code, the other
> > > > > chips will have different code.
> > > >
> > > > Ok, please make sure code is shared between these two.
> > >
> > > The exact function probably cannot be shared between KSZ8795
> > > and KSZ8895 drivers because although the register constants look
> > > the same but their exact locations are different in the 2 chips.
> >
> > Put the code into header as static inline and include it from both
> > places?
>
> Although KSZ8795 and KSZ8895 share the same code when simulating
> the PHY register access, even though the exact registers are not the
> same, this code needs a little modification for another chip. It also looks
> too large to put in a header.
I believe putting it into a header is prefferable to having two (or
three) copies of the code. If it needs small changes, you can
introduce if () ..., gcc can probably optimize it out.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [patch net-next 2/7] ipv4: ipmr: Add the parent ID field to VIF struct
From: Yotam Gigi @ 2017-10-01 6:33 UTC (permalink / raw)
To: Nikolay Aleksandrov, Jiri Pirko, netdev
Cc: davem, idosch, mlxsw, andrew, dsa, edumazet, willemb,
johannes.berg, dcaratti, pabeni, daniel, f.fainelli, fw,
gfree.wind
In-Reply-To: <29b9104c-6ada-0c9a-ce84-df104fa0afba@cumulusnetworks.com>
On 09/29/2017 12:50 PM, Nikolay Aleksandrov wrote:
> On 28/09/17 20:34, Jiri Pirko wrote:
>> From: Yotam Gigi <yotamg@mellanox.com>
>>
>> In order to allow the ipmr module to do partial multicast forwarding
>> according to the device parent ID, add the device parent ID field to the
>> VIF struct. This way, the forwarding path can use the parent ID field
>> without invoking switchdev calls, which requires the RTNL lock.
>>
>> When a new VIF is added, set the device parent ID field in it by invoking
>> the switchdev_port_attr_get call.
>>
>> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
>> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>> include/linux/mroute.h | 2 ++
>> net/ipv4/ipmr.c | 9 +++++++++
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/include/linux/mroute.h b/include/linux/mroute.h
>> index b072a84..a46577f 100644
>> --- a/include/linux/mroute.h
>> +++ b/include/linux/mroute.h
>> @@ -57,6 +57,8 @@ static inline bool ipmr_rule_default(const struct fib_rule *rule)
>>
>> struct vif_device {
>> struct net_device *dev; /* Device we are using */
>> + struct netdev_phys_item_id dev_parent_id; /* Device parent ID */
>> + bool dev_parent_id_valid;
>> unsigned long bytes_in,bytes_out;
>> unsigned long pkt_in,pkt_out; /* Statistics */
>> unsigned long rate_limit; /* Traffic shaping (NI) */
>> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
>> index 292a8e8..4566c54 100644
>> --- a/net/ipv4/ipmr.c
>> +++ b/net/ipv4/ipmr.c
>> @@ -67,6 +67,7 @@
>> #include <net/fib_rules.h>
>> #include <linux/netconf.h>
>> #include <net/nexthop.h>
>> +#include <net/switchdev.h>
>>
>> struct ipmr_rule {
>> struct fib_rule common;
>> @@ -868,6 +869,9 @@ static int vif_add(struct net *net, struct mr_table *mrt,
>> struct vifctl *vifc, int mrtsock)
>> {
>> int vifi = vifc->vifc_vifi;
>> + struct switchdev_attr attr = {
>> + .id = SWITCHDEV_ATTR_ID_PORT_PARENT_ID,
>> + };
>> struct vif_device *v = &mrt->vif_table[vifi];
>> struct net_device *dev;
>> struct in_device *in_dev;
>> @@ -942,6 +946,11 @@ static int vif_add(struct net *net, struct mr_table *mrt,
>>
>> /* Fill in the VIF structures */
>>
>> + attr.orig_dev = dev;
>> + if (!switchdev_port_attr_get(dev, &attr)) {
>> + v->dev_parent_id_valid = true;
>> + memcpy(v->dev_parent_id.id, attr.u.ppid.id, attr.u.ppid.id_len);
>> + }
>> v->rate_limit = vifc->vifc_rate_limit;
>> v->local = vifc->vifc_lcl_addr.s_addr;
>> v->remote = vifc->vifc_rmt_addr.s_addr;
>>
> One more thing - what happens on vif delete, then add with the same vif index of another
> device that doesn't have a parent id ? I think the vif will be stuck with its parent_id
> when it gets set.
>
Right. I will set the len to 0 if the device has no parent.
Thanks!
^ permalink raw reply
* Re: [patch net-next 2/7] ipv4: ipmr: Add the parent ID field to VIF struct
From: Yotam Gigi @ 2017-10-01 6:22 UTC (permalink / raw)
To: Nikolay Aleksandrov, Jiri Pirko, netdev
Cc: davem, idosch, mlxsw, andrew, dsa, edumazet, willemb,
johannes.berg, dcaratti, pabeni, daniel, f.fainelli, fw,
gfree.wind
In-Reply-To: <11d1be00-0bd4-3bcc-d63b-9419d5399602@cumulusnetworks.com>
On 09/29/2017 12:45 PM, Nikolay Aleksandrov wrote:
> On 29/09/17 12:29, Nikolay Aleksandrov wrote:
>> On 28/09/17 20:34, Jiri Pirko wrote:
>>> From: Yotam Gigi <yotamg@mellanox.com>
>>>
>>> In order to allow the ipmr module to do partial multicast forwarding
>>> according to the device parent ID, add the device parent ID field to the
>>> VIF struct. This way, the forwarding path can use the parent ID field
>>> without invoking switchdev calls, which requires the RTNL lock.
>>>
>>> When a new VIF is added, set the device parent ID field in it by invoking
>>> the switchdev_port_attr_get call.
>>>
>>> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
>>> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>> ---
>>> include/linux/mroute.h | 2 ++
>>> net/ipv4/ipmr.c | 9 +++++++++
>>> 2 files changed, 11 insertions(+)
>>>
>>> diff --git a/include/linux/mroute.h b/include/linux/mroute.h
>>> index b072a84..a46577f 100644
>>> --- a/include/linux/mroute.h
>>> +++ b/include/linux/mroute.h
>>> @@ -57,6 +57,8 @@ static inline bool ipmr_rule_default(const struct fib_rule *rule)
>>>
>>> struct vif_device {
>>> struct net_device *dev; /* Device we are using */
>>> + struct netdev_phys_item_id dev_parent_id; /* Device parent ID */
>>> + bool dev_parent_id_valid;
>>> unsigned long bytes_in,bytes_out;
>>> unsigned long pkt_in,pkt_out; /* Statistics */
>>> unsigned long rate_limit; /* Traffic shaping (NI) */
>>> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
>>> index 292a8e8..4566c54 100644
>>> --- a/net/ipv4/ipmr.c
>>> +++ b/net/ipv4/ipmr.c
>>> @@ -67,6 +67,7 @@
>>> #include <net/fib_rules.h>
>>> #include <linux/netconf.h>
>>> #include <net/nexthop.h>
>>> +#include <net/switchdev.h>
>>>
>>> struct ipmr_rule {
>>> struct fib_rule common;
>>> @@ -868,6 +869,9 @@ static int vif_add(struct net *net, struct mr_table *mrt,
>>> struct vifctl *vifc, int mrtsock)
>>> {
>>> int vifi = vifc->vifc_vifi;
>>> + struct switchdev_attr attr = {
>>> + .id = SWITCHDEV_ATTR_ID_PORT_PARENT_ID,
>>> + };
>>> struct vif_device *v = &mrt->vif_table[vifi];
>>> struct net_device *dev;
>>> struct in_device *in_dev;
>>> @@ -942,6 +946,11 @@ static int vif_add(struct net *net, struct mr_table *mrt,
>>>
>>> /* Fill in the VIF structures */
>>>
>>> + attr.orig_dev = dev;
>>> + if (!switchdev_port_attr_get(dev, &attr)) {
>>> + v->dev_parent_id_valid = true;
>>> + memcpy(v->dev_parent_id.id, attr.u.ppid.id, attr.u.ppid.id_len);
>> Hmm, shouldn't you set dev_parent_id.id_len too ? It would seem netdev_phys_item_id_same()
>> uses it in the comparison and without the len it would always look like they're the same
>> because memcmp will simply return 0 with count = 0.
> Also maybe we can use the non-zero id_len as a signal that it was set and drop the dev_parent_id_valid
> field altogether, it would seem there's no valid reason to have id_len == 0 and yet expect a valid
> parent_id.
Yes, I agree to both. I will remove the parent_id_valid field and use the len to
indicate whether it is valid.
Thanks for spotting the bug - since we have only been testing it with a pimreg
device, the problem was not found in our tests. Multi-ASIC setups are a bit
hard to find these days :)
>>> + }
>>> v->rate_limit = vifc->vifc_rate_limit;
>>> v->local = vifc->vifc_lcl_addr.s_addr;
>>> v->remote = vifc->vifc_rmt_addr.s_addr;
>>>
^ permalink raw reply
* Re: [PATCH v5 2/2] ip_tunnel: add mpls over gre encapsulation
From: kbuild test robot @ 2017-10-01 5:27 UTC (permalink / raw)
To: Amine Kherbouche
Cc: kbuild-all, netdev, davem, xeb, roopa, amine.kherbouche, equinox
In-Reply-To: <f0e68e51351239614cea89ae612c09a1ed8f5928.1506616215.git.amine.kherbouche@6wind.com>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
Hi Amine,
[auto build test ERROR on net/master]
[also build test ERROR on v4.14-rc2 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Amine-Kherbouche/mpls-export-mpls_forward/20171001-074929
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "mpls_forward" [net/ipv4/gre.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 40011 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/3] support changing steering policies in tuntap
From: Michael S. Tsirkin @ 2017-10-01 3:28 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Jason Wang, Network Development, LKML
In-Reply-To: <CAF=yD-KuDZK0-YUfYde=dk_6M6fgj_opuiK2VTfCKDM_=MqDcw@mail.gmail.com>
On Thu, Sep 28, 2017 at 12:09:05PM -0400, Willem de Bruijn wrote:
> Programming from the guest is
> indeed different. I don't fully understand that use case.
Generally programming host BPF from guest is a clear win - think DOS
protection. Guest runs logic to detect dos attacks, then passes the
program to host. Afterwards, host does not need to enter guest if
there's a DOS attack. Saves a ton of cycles.
The difficulty is making it work well, e.g. how do we handle maps?
--
MST
^ permalink raw reply
* Re: [kbuild-all] [PATCH net-next] vhost_net: do not stall on zerocopy depletion
From: Fengguang Wu @ 2017-10-01 3:26 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Willem de Bruijn, netdev, jasowang, Willem de Bruijn, den,
virtualization, kbuild-all, davem
In-Reply-To: <20171001062018-mutt-send-email-mst@kernel.org>
On Sun, Oct 01, 2017 at 06:20:49AM +0300, Michael S. Tsirkin wrote:
>On Sun, Oct 01, 2017 at 08:09:30AM +0800, kbuild test robot wrote:
>> Hi Willem,
>>
>> [auto build test WARNING on net-next/master]
>>
>> url: https://github.com/0day-ci/linux/commits/Willem-de-Bruijn/vhost_net-do-not-stall-on-zerocopy-depletion/20171001-054709
>> reproduce:
>> # apt-get install sparse
>> make ARCH=x86_64 allmodconfig
>> make C=1 CF=-D__CHECK_ENDIAN__
>
>BTW __CHECK_ENDIAN__ is the default now, I think you can drop it from
>your scripts.
Good tip, thank you! However since we're testing old kernels, too,
we'll need to keep it for probably 1-3 more years.
Thanks,
Fengguang
>>
>> sparse warnings: (new ones prefixed by >>)
>>
>>
>> vim +440 drivers/vhost/net.c
>>
>> 433
>> 434 static bool vhost_exceeds_maxpend(struct vhost_net *net)
>> 435 {
>> 436 struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
>> 437 struct vhost_virtqueue *vq = &nvq->vq;
>> 438
>> 439 return (nvq->upend_idx + UIO_MAXIOV - nvq->done_idx) % UIO_MAXIOV >
>> > 440 min(VHOST_MAX_PEND, vq->num >> 2);
>> 441 }
>> 442
>>
>> ---
>> 0-DAY kernel test infrastructure Open Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>_______________________________________________
>kbuild-all mailing list
>kbuild-all@lists.01.org
>https://lists.01.org/mailman/listinfo/kbuild-all
^ permalink raw reply
* [PATCH v2 iproute2] tc: fix ipv6 filter selector attribute for some prefix lengths
From: Yulia Kartseva @ 2017-10-01 3:18 UTC (permalink / raw)
To: stephen; +Cc: netdev, yulia.kartseva, hex
In-Reply-To: <20170927092634.0870468d@shemminger-XPS-13-9360>
Wrong TCA_U32_SEL attribute packing if prefixLen AND 0x1f equals 0x1f.
These are /31, /63, /95 and /127 prefix lengths.
Example:
ip6 dst face:b00f::/31
filter parent b: protocol ipv6 pref 2307 u32
filter parent b: protocol ipv6 pref 2307 u32 fh 800: ht divisor 1
filter parent b: protocol ipv6 pref 2307 u32 fh 800::800 order 2048
key ht 800 bkt 0
match faceb00f/ffffffff at 24
v2: previous patch was made with a wrong repo
Signed-off-by: Yulia Kartseva <hex@fb.com>
---
tc/f_u32.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tc/f_u32.c b/tc/f_u32.c
index 5815be9..14b9588 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -385,8 +385,7 @@ static int parse_ip6_addr(int *argc_p, char ***argv_p,
plen = addr.bitlen;
for (i = 0; i < plen; i += 32) {
- /* if (((i + 31) & ~0x1F) <= plen) { */
- if (i + 31 <= plen) {
+ if (i + 31 < plen) {
res = pack_key(sel, addr.data[i / 32],
0xFFFFFFFF, off + 4 * (i / 32), offmask);
if (res < 0)
--
2.9.5
^ permalink raw reply related
* Re: [PATCH net-next] vhost_net: do not stall on zerocopy depletion
From: Michael S. Tsirkin @ 2017-10-01 3:20 UTC (permalink / raw)
To: kbuild test robot
Cc: Willem de Bruijn, kbuild-all, netdev, davem, jasowang, den,
virtualization, Willem de Bruijn
In-Reply-To: <201710010753.KeY9a5xF%fengguang.wu@intel.com>
On Sun, Oct 01, 2017 at 08:09:30AM +0800, kbuild test robot wrote:
> Hi Willem,
>
> [auto build test WARNING on net-next/master]
>
> url: https://github.com/0day-ci/linux/commits/Willem-de-Bruijn/vhost_net-do-not-stall-on-zerocopy-depletion/20171001-054709
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
BTW __CHECK_ENDIAN__ is the default now, I think you can drop it from
your scripts.
>
> sparse warnings: (new ones prefixed by >>)
>
>
> vim +440 drivers/vhost/net.c
>
> 433
> 434 static bool vhost_exceeds_maxpend(struct vhost_net *net)
> 435 {
> 436 struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
> 437 struct vhost_virtqueue *vq = &nvq->vq;
> 438
> 439 return (nvq->upend_idx + UIO_MAXIOV - nvq->done_idx) % UIO_MAXIOV >
> > 440 min(VHOST_MAX_PEND, vq->num >> 2);
> 441 }
> 442
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next v2 0/7] net: dsa: change dsa_ptr for a dsa_port
From: David Miller @ 2017-10-01 3:15 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170929211921.5571-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Fri, 29 Sep 2017 17:19:14 -0400
> With DSA, a master net_device is physically wired to a dedicated CPU
> switch port. For interaction with the DSA layer, the struct net_device
> contains a dsa_ptr, which currently points to a dsa_switch_tree object.
>
> This is only valid for a switch fabric with a single CPU port. In order
> to support switch fabrics with multiple CPU ports, we first need to
> change the type of dsa_ptr to what it really is: a dsa_port object.
>
> This is what this patchset does. The first patches adds a
> dsa_master_get_slave helper and cleans up portions of DSA core to make
> the next patches more readable. These next patches prepare the xmit and
> receive hot paths and finally change dsa_ptr.
>
> Changes in v2:
> - introduce dsa_master_get_slave helper to simplify patch 6
> - keep hot path data at beginning of dsa_port for cacheline 1
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: hns3: fix null pointer dereference before null check
From: David Miller @ 2017-10-01 3:13 UTC (permalink / raw)
To: colin.king
Cc: yisen.zhuang, salil.mehta, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170929195123.4189-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 29 Sep 2017 20:51:23 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> pointer ndev is being dereferenced with the call to netif_running
> before it is being null checked. Re-order the code to only dereference
> ndev after it has been null checked.
>
> Detected by CoverityScan, CID#1457206 ("Dereference before null check")
>
> Fixes: 9df8f79a4d29 ("net: hns3: Add DCB support when interacting with network stack")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] hv_netvsc: report stop_queue and wake_queue
From: David Miller @ 2017-10-01 3:11 UTC (permalink / raw)
To: sixiao; +Cc: netdev, kys, haiyangz, sthemmin
In-Reply-To: <20170929183946.18364-1-sixiao@microsoft.com>
From: Simon Xiao <sixiao@microsoft.com>
Date: Fri, 29 Sep 2017 11:39:46 -0700
> Report the numbers of events for stop_queue and wake_queue in
> ethtool stats.
>
> Example:
> ethtool -S eth0
> NIC statistics:
> ...
> stop_queue: 7
> wake_queue: 7
> ...
>
> Signed-off-by: Simon Xiao <sixiao@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bpf: Fix compiler warning on info.map_ids for 32bit platform
From: David Miller @ 2017-10-01 3:11 UTC (permalink / raw)
To: kafai; +Cc: netdev, ast, daniel, kernel-team
In-Reply-To: <20170929175217.437830-1-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Fri, 29 Sep 2017 10:52:17 -0700
> This patch uses u64_to_user_ptr() to cast info.map_ids to a userspace ptr.
> It also tags the user_map_ids with '__user' for sparse check.
>
> Fixes: cb4d2b3f03d8 ("bpf: Add name, load_time, uid and map_ids to bpf_prog_info")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Applied.
^ permalink raw reply
* Re: [PATCH][net-next] net_sched: remove redundant assignment to ret
From: David Miller @ 2017-10-01 3:08 UTC (permalink / raw)
To: colin.king
Cc: jhs, xiyou.wangcong, jiri, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170929140116.8642-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 29 Sep 2017 15:01:16 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The assignment of -EINVAL to variable ret is redundant as it
> is being overwritten on the following error exit paths or
> to the return value from the following call to basic_set_parms.
> Fix this up by removing it. Cleans up clang warning message:
>
> net/sched/cls_basic.c:185:2: warning: Value stored to 'err' is never read
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH][net-next] net: ipmr: make function ipmr_notifier_init static
From: David Miller @ 2017-10-01 3:07 UTC (permalink / raw)
To: colin.king; +Cc: kuznet, yoshfuji, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20170929133422.7846-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 29 Sep 2017 14:34:22 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The function ipmr_notifier_init is local to the source and does
> not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> warning: symbol 'ipmr_notifier_init' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net v1 1/1] tipc: use only positive error codes in messages
From: David Miller @ 2017-10-01 3:04 UTC (permalink / raw)
To: parthasarathy.bhuvaragan
Cc: netdev, tipc-discussion, jon.maloy, maloy, ying.xue,
parthasarathy.bhuvaragan
In-Reply-To: <1506672174-26962-1-git-send-email-parthasarathy.bhuvaragan@ericsson.com>
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Date: Fri, 29 Sep 2017 10:02:54 +0200
> In commit e3a77561e7d32 ("tipc: split up function tipc_msg_eval()"),
> we have updated the function tipc_msg_lookup_dest() to set the error
> codes to negative values at destination lookup failures. Thus when
> the function sets the error code to -TIPC_ERR_NO_NAME, its inserted
> into the 4 bit error field of the message header as 0xf instead of
> TIPC_ERR_NO_NAME (1). The value 0xf is an unknown error code.
>
> In this commit, we set only positive error code.
>
> Fixes: e3a77561e7d32 ("tipc: split up function tipc_msg_eval()")
> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ibmvnic: Set state UP
From: David Miller @ 2017-10-01 3:03 UTC (permalink / raw)
To: mjtarsel; +Cc: netdev, tlfalcon
In-Reply-To: <1506631998-12670-1-git-send-email-mjtarsel@linux.vnet.ibm.com>
From: Mick Tarsel <mjtarsel@linux.vnet.ibm.com>
Date: Thu, 28 Sep 2017 13:53:18 -0700
> State is initially reported as UNKNOWN. Before register call
> netif_carrier_off(). Once the device is opened, call netif_carrier_on() in
> order to set the state to UP.
>
> Signed-off-by: Mick Tarsel <mjtarsel@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] Revert "net: dsa: bcm_sf2: Defer port enabling to calling port_enable"
From: David Miller @ 2017-10-01 3:02 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20170928181906.3156-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 28 Sep 2017 11:19:06 -0700
> This reverts commit e85ec74ace29 ("net: dsa: bcm_sf2: Defer port
> enabling to calling port_enable") because this now makes an unbind
> followed by a bind to fail connecting to the ingrated PHY.
>
> What this patch missed is that we need the PHY to be enabled with
> bcm_sf2_gphy_enable_set() before probing it on the MDIO bus. This is
> correctly done in the ops->setup() function, but by the time
> ops->port_enable() runs, this is too late. Upon unbind we would power
> down the PHY, and so when we would bind again, the PHY would be left
> powered off.
>
> Fixes: e85ec74ace29 ("net: dsa: bcm_sf2: Defer port enabling to calling port_enable")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ppp: fix __percpu annotation
From: David Miller @ 2017-10-01 2:58 UTC (permalink / raw)
To: g.nault; +Cc: netdev, gfree.wind, paulus
In-Reply-To: <1e69021734ef43406df65571b9fa97884831825d.1506613995.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Thu, 28 Sep 2017 17:57:58 +0200
> Move sparse annotation right after pointer type.
>
> Fixes sparse warning:
> drivers/net/ppp/ppp_generic.c:1422:13: warning: incorrect type in initializer (different address spaces)
> drivers/net/ppp/ppp_generic.c:1422:13: expected void const [noderef] <asn:3>*__vpp_verify
> drivers/net/ppp/ppp_generic.c:1422:13: got int *<noident>
> ...
>
> Fixes: e5dadc65f9e0 ("ppp: Fix false xmit recursion detect with two ppp devices")
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net 0/2] udp: fix early demux for mcast packets
From: David Miller @ 2017-10-01 2:56 UTC (permalink / raw)
To: pabeni; +Cc: netdev
In-Reply-To: <cover.1506606381.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 28 Sep 2017 15:51:35 +0200
> Currently the early demux callbacks do not perform source address validation.
> This is not an issue for TCP or UDP unicast, where the early demux
> is only allowed for connected sockets and the source address is validated
> for the first packet and never change.
>
> The UDP protocol currently allows early demux also for unconnected multicast
> sockets, and we are not currently doing any validation for them, after that
> the first packet lands on the socket: beyond ignoring the rp_filter - if
> enabled - any kind of martian sources are also allowed.
>
> This series addresses the issue allowing the early demux callback to return an
> error code, and performing the proper checks for unconnected UDP multicast
> sockets before leveraging the rx dst cache.
>
> Alternatively we could disable the early demux for unconnected mcast sockets,
> but that would cause relevant performance regression - around 50% - while with
> this series, with full rp_filter in place, we keep the regression to a more
> moderate level.
Series applied and queued up for -stable, thanks.
^ 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