* [PATCH] net: bcmgenet: use ethtool_op_get_ts_info()
From: Ryan M. Collins @ 2019-08-30 18:49 UTC (permalink / raw)
To: Doug Berger, Florian Fainelli, David S. Miller
Cc: bcm-kernel-feedback-list, netdev, linux-kernel
This change enables the use of SW timestamping on the Raspberry Pi 4.
bcmgenet's transmit function bcmgenet_xmit() implements software
timestamping. However the SOF_TIMESTAMPING_TX_SOFTWARE capability was
missing and only SOF_TIMESTAMPING_RX_SOFTWARE was announced. By using
ethtool_ops bcmgenet_ethtool_ops() as get_ts_info(), the
SOF_TIMESTAMPING_TX_SOFTWARE capability is announced.
Similar to commit a8f5cb9e7991 ("smsc95xx: use ethtool_op_get_ts_info()")
Signed-off-by: Ryan M. Collins <rmc032@bucknell.edu>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 1586316eb6f1..12cb77ef1081 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1124,6 +1124,7 @@ static const struct ethtool_ops bcmgenet_ethtool_ops = {
.set_coalesce = bcmgenet_set_coalesce,
.get_link_ksettings = bcmgenet_get_link_ksettings,
.set_link_ksettings = bcmgenet_set_link_ksettings,
+ .get_ts_info = ethtool_op_get_ts_info,
};
/* Power down the unimac, based on mode. */
--
2.23.0
^ permalink raw reply related
* Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: Leonardo Bras @ 2019-08-30 18:16 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, David S. Miller, netfilter-devel, coreteam,
netdev, linux-kernel, Jozsef Kadlecsik, Alexey Kuznetsov,
Hideaki YOSHIFUJI
In-Reply-To: <20190829205832.GM20113@breakpoint.cc>
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
On Thu, 2019-08-29 at 22:58 +0200, Florian Westphal wrote:
> Ah, it was the latter.
> Making bridge netfilter not pass packets up with ipv6 off closes
> the problem for fib_ipv6 and inet, so only _netdev.c needs fixing.
Ok then, preparing a v4.
https://lkml.org/lkml/2019/8/30/843
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net] net: Properly update v4 routes with v6 nexthop
From: Donald Sharp @ 2019-08-30 18:14 UTC (permalink / raw)
To: netdev, dsahern, sworley
When creating a v4 route that uses a v6 nexthop from a nexthop group.
Allow the kernel to properly send the nexthop as v6 via the RTA_VIA
attribute.
Broken behavior:
$ ip nexthop add via fe80::9 dev eth0
$ ip nexthop show
id 1 via fe80::9 dev eth0 scope link
$ ip route add 4.5.6.7/32 nhid 1
$ ip route show
default via 10.0.2.2 dev eth0
4.5.6.7 nhid 1 via 254.128.0.0 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
$
Fixed behavior:
$ ip nexthop add via fe80::9 dev eth0
$ ip nexthop show
id 1 via fe80::9 dev eth0 scope link
$ ip route add 4.5.6.7/32 nhid 1
$ ip route show
default via 10.0.2.2 dev eth0
4.5.6.7 nhid 1 via inet6 fe80::9 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
$
Fixes: dcb1ecb50edf (“ipv4: Prepare for fib6_nh from a nexthop object”)
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
---
include/net/ip_fib.h | 4 ++--
include/net/nexthop.h | 2 +-
net/ipv4/fib_semantics.c | 21 ++++++++++++---------
net/ipv6/route.c | 9 +++++----
4 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index 4c81846ccce8..c7e94edae482 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -513,7 +513,7 @@ int ip_valid_fib_dump_req(struct net *net, const struct nlmsghdr *nlh,
struct netlink_callback *cb);
int fib_nexthop_info(struct sk_buff *skb, const struct fib_nh_common *nh,
- unsigned char *flags, bool skip_oif);
+ u8 family, unsigned char *flags, bool skip_oif);
int fib_add_nexthop(struct sk_buff *skb, const struct fib_nh_common *nh,
- int nh_weight);
+ int nh_weight, u8 family);
#endif /* _NET_FIB_H */
diff --git a/include/net/nexthop.h b/include/net/nexthop.h
index 95f766c31c90..f13c61806abf 100644
--- a/include/net/nexthop.h
+++ b/include/net/nexthop.h
@@ -172,7 +172,7 @@ int nexthop_mpath_fill_node(struct sk_buff *skb, struct nexthop *nh)
struct fib_nh_common *nhc = &nhi->fib_nhc;
int weight = nhg->nh_entries[i].weight;
- if (fib_add_nexthop(skb, nhc, weight) < 0)
+ if (fib_add_nexthop(skb, nhc, weight, nhc->nhc_family) < 0)
return -EMSGSIZE;
}
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 2db089e10ba0..e4417d171863 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1582,7 +1582,7 @@ struct fib_info *fib_create_info(struct fib_config *cfg,
}
int fib_nexthop_info(struct sk_buff *skb, const struct fib_nh_common *nhc,
- unsigned char *flags, bool skip_oif)
+ u8 family, unsigned char *flags, bool skip_oif)
{
if (nhc->nhc_flags & RTNH_F_DEAD)
*flags |= RTNH_F_DEAD;
@@ -1613,7 +1613,7 @@ int fib_nexthop_info(struct sk_buff *skb, const struct fib_nh_common *nhc,
/* if gateway family does not match nexthop family
* gateway is encoded as RTA_VIA
*/
- if (nhc->nhc_gw_family != nhc->nhc_family) {
+ if (family != nhc->nhc_gw_family) {
int alen = sizeof(struct in6_addr);
struct nlattr *nla;
struct rtvia *via;
@@ -1654,7 +1654,7 @@ EXPORT_SYMBOL_GPL(fib_nexthop_info);
#if IS_ENABLED(CONFIG_IP_ROUTE_MULTIPATH) || IS_ENABLED(CONFIG_IPV6)
int fib_add_nexthop(struct sk_buff *skb, const struct fib_nh_common *nhc,
- int nh_weight)
+ int nh_weight, u8 family)
{
const struct net_device *dev = nhc->nhc_dev;
struct rtnexthop *rtnh;
@@ -1667,7 +1667,7 @@ int fib_add_nexthop(struct sk_buff *skb, const struct fib_nh_common *nhc,
rtnh->rtnh_hops = nh_weight - 1;
rtnh->rtnh_ifindex = dev ? dev->ifindex : 0;
- if (fib_nexthop_info(skb, nhc, &flags, true) < 0)
+ if (fib_nexthop_info(skb, nhc, family, &flags, true) < 0)
goto nla_put_failure;
rtnh->rtnh_flags = flags;
@@ -1684,7 +1684,8 @@ EXPORT_SYMBOL_GPL(fib_add_nexthop);
#endif
#ifdef CONFIG_IP_ROUTE_MULTIPATH
-static int fib_add_multipath(struct sk_buff *skb, struct fib_info *fi)
+static int fib_add_multipath(struct sk_buff *skb, struct fib_info *fi,
+ u8 family)
{
struct nlattr *mp;
@@ -1699,7 +1700,8 @@ static int fib_add_multipath(struct sk_buff *skb, struct fib_info *fi)
}
for_nexthops(fi) {
- if (fib_add_nexthop(skb, &nh->nh_common, nh->fib_nh_weight) < 0)
+ if (fib_add_nexthop(skb, &nh->nh_common, nh->fib_nh_weight,
+ family) < 0)
goto nla_put_failure;
#ifdef CONFIG_IP_ROUTE_CLASSID
if (nh->nh_tclassid &&
@@ -1717,7 +1719,8 @@ static int fib_add_multipath(struct sk_buff *skb, struct fib_info *fi)
return -EMSGSIZE;
}
#else
-static int fib_add_multipath(struct sk_buff *skb, struct fib_info *fi)
+static int fib_add_multipath(struct sk_buff *skb, struct fib_info *fi,
+ u8 family)
{
return 0;
}
@@ -1775,7 +1778,7 @@ int fib_dump_info(struct sk_buff *skb, u32 portid, u32 seq, int event,
const struct fib_nh_common *nhc = fib_info_nhc(fi, 0);
unsigned char flags = 0;
- if (fib_nexthop_info(skb, nhc, &flags, false) < 0)
+ if (fib_nexthop_info(skb, nhc, AF_INET, &flags, false) < 0)
goto nla_put_failure;
rtm->rtm_flags = flags;
@@ -1790,7 +1793,7 @@ int fib_dump_info(struct sk_buff *skb, u32 portid, u32 seq, int event,
}
#endif
} else {
- if (fib_add_multipath(skb, fi) < 0)
+ if (fib_add_multipath(skb, fi, AF_INET) < 0)
goto nla_put_failure;
}
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index fd059e08785a..d91dd8d832cd 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -5337,7 +5337,7 @@ static int rt6_fill_node_nexthop(struct sk_buff *skb, struct nexthop *nh,
struct fib6_nh *fib6_nh;
fib6_nh = nexthop_fib6_nh(nh);
- if (fib_nexthop_info(skb, &fib6_nh->nh_common,
+ if (fib_nexthop_info(skb, &fib6_nh->nh_common, AF_INET6,
flags, false) < 0)
goto nla_put_failure;
}
@@ -5466,13 +5466,14 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
goto nla_put_failure;
if (fib_add_nexthop(skb, &rt->fib6_nh->nh_common,
- rt->fib6_nh->fib_nh_weight) < 0)
+ rt->fib6_nh->fib_nh_weight, AF_INET6) < 0)
goto nla_put_failure;
list_for_each_entry_safe(sibling, next_sibling,
&rt->fib6_siblings, fib6_siblings) {
if (fib_add_nexthop(skb, &sibling->fib6_nh->nh_common,
- sibling->fib6_nh->fib_nh_weight) < 0)
+ sibling->fib6_nh->fib_nh_weight,
+ AF_INET6) < 0)
goto nla_put_failure;
}
@@ -5489,7 +5490,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
rtm->rtm_flags |= nh_flags;
} else {
- if (fib_nexthop_info(skb, &rt->fib6_nh->nh_common,
+ if (fib_nexthop_info(skb, &rt->fib6_nh->nh_common, AF_INET6,
&nh_flags, false) < 0)
goto nla_put_failure;
--
2.21.0
^ permalink raw reply related
* [PATCH v4 0/2] Drop IPV6 packets if IPv6 is disabled on boot
From: Leonardo Bras @ 2019-08-30 18:13 UTC (permalink / raw)
To: netfilter-devel, coreteam, bridge, netdev, linux-kernel
Cc: Leonardo Bras, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Roopa Prabhu, Nikolay Aleksandrov,
David S. Miller
This patchset was prevously a single patch named:
- netfilter: nf_tables: fib: Drop IPV6 packets if IPv6 is disabled on boot
It fixes a bug where a host, with IPv6 disabled on boot, has to deal with
guest IPv6 packets, that comes from a bridge interface.
When these packets reach the host ip6tables they cause a kernel panic.
---
Changes from v3:
- Move drop logic from nft_fib6_eval{,_type} to nft_fib_netdev_eval
- Add another patch to drop ipv6 packets from bridge when ipv6 disabled
Changes from v2:
- Replace veredict.code from NF_DROP to NFT_BREAK
- Updated commit message (s/package/packet)
Changes from v1:
- Move drop logic from nft_fib_inet_eval() to nft_fib6_eval{,_type}
so it can affect other usages of these functions.
Leonardo Bras (2):
netfilter: Terminate rule eval if protocol=IPv6 and ipv6 module is
disabled
net: br_netfiler_hooks: Drops IPv6 packets if IPv6 module is not
loaded
net/bridge/br_netfilter_hooks.c | 2 ++
net/netfilter/nft_fib_netdev.c | 3 +++
2 files changed, 5 insertions(+)
--
2.20.1
^ permalink raw reply
* [PATCH v4 1/2] netfilter: Terminate rule eval if protocol=IPv6 and ipv6 module is disabled
From: Leonardo Bras @ 2019-08-30 18:13 UTC (permalink / raw)
To: netfilter-devel, coreteam, bridge, netdev, linux-kernel
Cc: Leonardo Bras, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Roopa Prabhu, Nikolay Aleksandrov,
David S. Miller
In-Reply-To: <20190830181354.26279-1-leonardo@linux.ibm.com>
If IPv6 is disabled on boot (ipv6.disable=1), but nft_fib_inet ends up
dealing with a IPv6 packet, it causes a kernel panic in
fib6_node_lookup_1(), crashing in bad_page_fault.
The panic is caused by trying to deference a very low address (0x38
in ppc64le), due to ipv6.fib6_main_tbl = NULL.
BUG: Kernel NULL pointer dereference at 0x00000038
The kernel panic was reproduced in a host that disabled IPv6 on boot and
have to process guest packets (coming from a bridge) using it's ip6tables.
Terminate rule evaluation when packet protocol is IPv6 but the ipv6 module
is not loaded.
Signed-off-by: Leonardo Bras <leonardo@linux.ibm.com>
---
net/netfilter/nft_fib_netdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/netfilter/nft_fib_netdev.c b/net/netfilter/nft_fib_netdev.c
index 2cf3f32fe6d2..a2e726ae7f07 100644
--- a/net/netfilter/nft_fib_netdev.c
+++ b/net/netfilter/nft_fib_netdev.c
@@ -14,6 +14,7 @@
#include <linux/netfilter/nf_tables.h>
#include <net/netfilter/nf_tables_core.h>
#include <net/netfilter/nf_tables.h>
+#include <net/ipv6.h>
#include <net/netfilter/nft_fib.h>
@@ -34,6 +35,8 @@ static void nft_fib_netdev_eval(const struct nft_expr *expr,
}
break;
case ETH_P_IPV6:
+ if (!ipv6_mod_enabled())
+ break;
switch (priv->result) {
case NFT_FIB_RESULT_OIF:
case NFT_FIB_RESULT_OIFNAME:
--
2.20.1
^ permalink raw reply related
* [PATCH v4 2/2] net: br_netfiler_hooks: Drops IPv6 packets if IPv6 module is not loaded
From: Leonardo Bras @ 2019-08-30 18:13 UTC (permalink / raw)
To: netfilter-devel, coreteam, bridge, netdev, linux-kernel
Cc: Leonardo Bras, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Roopa Prabhu, Nikolay Aleksandrov,
David S. Miller
In-Reply-To: <20190830181354.26279-1-leonardo@linux.ibm.com>
A kernel panic can happen if a host has disabled IPv6 on boot and have to
process guest packets (coming from a bridge) using it's ip6tables.
IPv6 packets need to be dropped if the IPv6 module is not loaded.
Signed-off-by: Leonardo Bras <leonardo@linux.ibm.com>
---
net/bridge/br_netfilter_hooks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index d3f9592f4ff8..5e8693730df1 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -493,6 +493,8 @@ static unsigned int br_nf_pre_routing(void *priv,
brnet = net_generic(state->net, brnf_net_id);
if (IS_IPV6(skb) || is_vlan_ipv6(skb, state->net) ||
is_pppoe_ipv6(skb, state->net)) {
+ if (!ipv6_mod_enabled())
+ return NF_DROP;
if (!brnet->call_ip6tables &&
!br_opt_get(br, BROPT_NF_CALL_IP6TABLES))
return NF_ACCEPT;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net/skbuff: silence warnings under memory pressure
From: Qian Cai @ 2019-08-30 18:06 UTC (permalink / raw)
To: Eric Dumazet, davem; +Cc: netdev, linux-mm, linux-kernel
In-Reply-To: <229ebc3b-1c7e-474f-36f9-0fa603b889fb@gmail.com>
On Fri, 2019-08-30 at 18:15 +0200, Eric Dumazet wrote:
>
> On 8/30/19 5:25 PM, Qian Cai wrote:
> > On Fri, 2019-08-30 at 17:11 +0200, Eric Dumazet wrote:
> > >
> > > On 8/30/19 4:57 PM, Qian Cai wrote:
> > > > When running heavy memory pressure workloads, the system is throwing
> > > > endless warnings below due to the allocation could fail from
> > > > __build_skb(), and the volume of this call could be huge which may
> > > > generate a lot of serial console output and cosumes all CPUs as
> > > > warn_alloc() could be expensive by calling dump_stack() and then
> > > > show_mem().
> > > >
> > > > Fix it by silencing the warning in this call site. Also, it seems
> > > > unnecessary to even print a warning at all if the allocation failed in
> > > > __build_skb(), as it may just retransmit the packet and retry.
> > > >
> > >
> > > Same patches are showing up there and there from time to time.
> > >
> > > Why is this particular spot interesting, against all others not adding
> > > __GFP_NOWARN ?
> > >
> > > Are we going to have hundred of patches adding __GFP_NOWARN at various
> > > points,
> > > or should we get something generic to not flood the syslog in case of
> > > memory
> > > pressure ?
> > >
> >
> > From my testing which uses LTP oom* tests. There are only 3 places need to
> > be
> > patched. The other two are in IOMMU code for both Intel and AMD. The place
> > is
> > particular interesting because it could cause the system with floating
> > serial
> > console output for days without making progress in OOM. I suppose it ends up
> > in
> > a looping condition that warn_alloc() would end up generating more calls
> > into
> > __build_skb() via ksoftirqd.
> >
>
> Yes, but what about other tests done by other people ?
Sigh, I don't know what tests do you have in mind. I tried many memory pressure
tests including LTP, stress-ng, and mmtests etc running for years. I don't
recall see other places that could loop like this for days.
>
> You do not really answer my last question, which was really the point I tried
> to make.
>
> If there is a risk of flooding the syslog, we should fix this generically
> in mm layer, not adding hundred of __GFP_NOWARN all over the places.
>
> Maybe just make __GFP_NOWARN the default, I dunno.
I don't really see how it could end up with adding hundred of _GFP_NOWARN in the
kernel code. If there is really a hundred places could loop like this, it may
make more sense looking into a general solution.
^ permalink raw reply
* Re: [PATCH net-next v2 16/22] bnxt_en: Handle firmware reset.
From: kbuild test robot @ 2019-08-30 17:56 UTC (permalink / raw)
To: Michael Chan; +Cc: kbuild-all, davem, netdev, vasundhara-v.volam, ray.jui
In-Reply-To: <1567137305-5853-17-git-send-email-michael.chan@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]
Hi Michael,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Michael-Chan/bnxt_en-health-and-error-recovery/20190830-164635
config: x86_64-randconfig-f001-201934 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/net/ethernet/broadcom/bnxt/bnxt.c: In function 'bnxt_fw_reset':
>> drivers/net/ethernet/broadcom/bnxt/bnxt.c:10021:35: error: 'struct bnxt' has no member named 'sriov_cfg'
if (bp->pf.registered_vfs || bp->sriov_cfg) {
^~
drivers/net/ethernet/broadcom/bnxt/bnxt.c: In function 'bnxt_fw_reset_task':
drivers/net/ethernet/broadcom/bnxt/bnxt.c:10418:34: error: 'struct bnxt' has no member named 'sriov_cfg'
if (bp->pf.registered_vfs || bp->sriov_cfg) {
^~
drivers/net/ethernet/broadcom/bnxt/bnxt.c:10425:11: error: 'struct bnxt' has no member named 'sriov_cfg'
bp->sriov_cfg);
^~
vim +10021 drivers/net/ethernet/broadcom/bnxt/bnxt.c
10003
10004 void bnxt_fw_reset(struct bnxt *bp)
10005 {
10006 int rc;
10007
10008 bnxt_rtnl_lock_sp(bp);
10009 if (test_bit(BNXT_STATE_OPEN, &bp->state) &&
10010 !test_bit(BNXT_STATE_IN_FW_RESET, &bp->state)) {
10011 set_bit(BNXT_STATE_IN_FW_RESET, &bp->state);
10012 if (BNXT_PF(bp) && bp->pf.active_vfs) {
10013 rc = bnxt_hwrm_func_qcfg(bp);
10014 if (rc) {
10015 netdev_err(bp->dev, "Firmware reset aborted, first func_qcfg cmd failed, rc = %d\n",
10016 rc);
10017 clear_bit(BNXT_STATE_IN_FW_RESET, &bp->state);
10018 dev_close(bp->dev);
10019 goto fw_reset_exit;
10020 }
10021 if (bp->pf.registered_vfs || bp->sriov_cfg) {
10022 u16 vf_tmo_dsecs = bp->pf.registered_vfs * 10;
10023
10024 if (bp->fw_reset_max_dsecs < vf_tmo_dsecs)
10025 bp->fw_reset_max_dsecs = vf_tmo_dsecs;
10026 bp->fw_reset_state =
10027 BNXT_FW_RESET_STATE_POLL_VF;
10028 bnxt_queue_fw_reset_work(bp, HZ / 10);
10029 goto fw_reset_exit;
10030 }
10031 }
10032 bnxt_fw_reset_close(bp);
10033 bp->fw_reset_state = BNXT_FW_RESET_STATE_ENABLE_DEV;
10034 bnxt_queue_fw_reset_work(bp, bp->fw_reset_min_dsecs * HZ / 10);
10035 }
10036 fw_reset_exit:
10037 bnxt_rtnl_unlock_sp(bp);
10038 }
10039
---
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: 33761 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] net: dsa: tag_8021q: Restore bridge VLANs when enabling vlan_filtering
From: Vivien Didelot @ 2019-08-30 17:20 UTC (permalink / raw)
To: Vladimir Oltean
Cc: f.fainelli, andrew, idosch, roopa, nikolay, davem, netdev,
Vladimir Oltean
In-Reply-To: <20190830005325.26526-3-olteanv@gmail.com>
Hi Vladimir,
On Fri, 30 Aug 2019 03:53:25 +0300, Vladimir Oltean <olteanv@gmail.com> wrote:
> The bridge core assumes that enabling/disabling vlan_filtering will
> translate into the simple toggling of a flag for switchdev drivers.
>
> That is clearly not the case for sja1105, which alters the VLAN table
> and the pvids in order to obtain port separation in standalone mode.
>
> There are 2 parts to the issue.
>
> First, tag_8021q changes the pvid to a unique per-port rx_vid for frame
> identification. But we need to disable tag_8021q when vlan_filtering
> kicks in, and at that point, the VLAN configured as pvid will have to be
> removed from the filtering table of the ports. With an invalid pvid, the
> ports will drop all traffic. Since the bridge will not call any vlan
> operation through switchdev after enabling vlan_filtering, we need to
> ensure we're in a functional state ourselves. Hence read the pvid that
> the bridge is aware of, and program that into our ports.
>
> Secondly, tag_8021q uses the 1024-3071 range privately in
> vlan_filtering=0 mode. Had the user installed one of these VLANs during
> a previous vlan_filtering=1 session, then upon the next tag_8021q
> cleanup for vlan_filtering to kick in again, VLANs in that range will
> get deleted unconditionally, hence breaking user expectation. So when
> deleting the VLANs, check if the bridge had knowledge about them, and if
> it did, re-apply the settings. Wrap this logic inside a
> dsa_8021q_vid_apply helper function to reduce code duplication.
>
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
I have no complaint with this series:
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Thanks for sending smaller pieces like this one btw,
Vivien
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] dt-bindings: net: dsa: mt7530: Add support for port 5
From: René van Dorst @ 2019-08-30 17:16 UTC (permalink / raw)
To: Rob Herring
Cc: Sean Wang, Andrew Lunn, Vivien Didelot, Florian Fainelli,
David S . Miller, Matthias Brugger, netdev, linux-arm-kernel,
linux-mediatek, John Crispin, linux-mips, Frank Wunderlich,
devicetree
In-Reply-To: <20190828063520.Horde.4_ak7mcmFhVJlxZWWy2wo3V@www.vdorst.com>
Hi Rob,
<snip>
>>> See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list
>>> of additional
>>> required, optional properties and how the integrated switch subnodes must
>>> be specified.
>>> @@ -94,3 +130,185 @@ Example:
>>> };
>>> };
>>> };
>>> +
>>> +Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4.
>>> +
>>> +ð {
>>> + status = "okay";
>>
>> Don't show status in examples.
>
> OK.
>
>> This should show the complete node.
>>
>
I asked this question below in my previous email.
May be you missed it, I hope that you have time soon to answer this so that I
can send a new version.
> To be clear, I should take ethernet node from the mt7621.dtsi [0] or
> mt7623.dtsi [1] and insert the example below?, right?
Greats,
René
>
> Greats,
>
> René
>
> [0]:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/drivers/staging/mt7621-dts/mt7621.dtsi#n397
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/arch/arm/boot/dts/mt7623.dtsi#n1023
>
>>> +
>>> + gmac0: mac@0 {
>>> + compatible = "mediatek,eth-mac";
>>> + reg = <0>;
>>> + phy-mode = "rgmii";
>>> +
>>> + fixed-link {
>>> + speed = <1000>;
>>> + full-duplex;
>>> + pause;
>>> + };
>>> + };
>>> +
>>> + gmac1: mac@1 {
>>> + compatible = "mediatek,eth-mac";
>>> + reg = <1>;
>>> + phy-mode = "rgmii-txid";
>>> + phy-handle = <&phy4>;
>>> + };
>>> +
>>> + mdio: mdio-bus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + /* Internal phy */
>>> + phy4: ethernet-phy@4 {
>>> + reg = <4>;
>>> + };
>>> +
>>> + mt7530: switch@1f {
>>> + compatible = "mediatek,mt7621";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0x1f>;
>>> + pinctrl-names = "default";
>>> + mediatek,mcm;
>>> +
>>> + resets = <&rstctrl 2>;
>>> + reset-names = "mcm";
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> + label = "lan0";
>>> + };
>>> +
>>> + port@1 {
>>> + reg = <1>;
>>> + label = "lan1";
>>> + };
>>> +
>>> + port@2 {
>>> + reg = <2>;
>>> + label = "lan2";
>>> + };
>>> +
>>> + port@3 {
>>> + reg = <3>;
>>> + label = "lan3";
>>> + };
>>> +
>>> +/* Commented out. Port 4 is handled by 2nd GMAC.
>>> + port@4 {
>>> + reg = <4>;
>>> + label = "lan4";
>>> + };
>>> +*/
>>> +
>>> + cpu_port0: port@6 {
>>> + reg = <6>;
>>> + label = "cpu";
>>> + ethernet = <&gmac0>;
>>> + phy-mode = "rgmii";
>>> +
>>> + fixed-link {
>>> + speed = <1000>;
>>> + full-duplex;
>>> + pause;
>>> + };
>>> + };
>>> + };
>>> + };
>>> + };
>>> +};
>>> +
>>> +Example 3: MT7621: Port 5 is connected to external PHY: Port 5 ->
>>> external PHY.
>>> +
>>> +ð {
>>> + status = "okay";
>>> +
>>> + gmac0: mac@0 {
>>> + compatible = "mediatek,eth-mac";
>>> + reg = <0>;
>>> + phy-mode = "rgmii";
>>> +
>>> + fixed-link {
>>> + speed = <1000>;
>>> + full-duplex;
>>> + pause;
>>> + };
>>> + };
>>> +
>>> + mdio: mdio-bus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + /* External phy */
>>> + ephy5: ethernet-phy@7 {
>>> + reg = <7>;
>>> + };
>>> +
>>> + mt7530: switch@1f {
>>> + compatible = "mediatek,mt7621";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0x1f>;
>>> + pinctrl-names = "default";
>>> + mediatek,mcm;
>>> +
>>> + resets = <&rstctrl 2>;
>>> + reset-names = "mcm";
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> + label = "lan0";
>>> + };
>>> +
>>> + port@1 {
>>> + reg = <1>;
>>> + label = "lan1";
>>> + };
>>> +
>>> + port@2 {
>>> + reg = <2>;
>>> + label = "lan2";
>>> + };
>>> +
>>> + port@3 {
>>> + reg = <3>;
>>> + label = "lan3";
>>> + };
>>> +
>>> + port@4 {
>>> + reg = <4>;
>>> + label = "lan4";
>>> + };
>>> +
>>> + port@5 {
>>> + reg = <5>;
>>> + label = "lan5";
>>> + phy-mode = "rgmii";
>>> + phy-handle = <&ephy5>;
>>> + };
>>> +
>>> + cpu_port0: port@6 {
>>> + reg = <6>;
>>> + label = "cpu";
>>> + ethernet = <&gmac0>;
>>> + phy-mode = "rgmii";
>>> +
>>> + fixed-link {
>>> + speed = <1000>;
>>> + full-duplex;
>>> + pause;
>>> + };
>>> + };
>>> + };
>>> + };
>>> + };
>>> +};
>>> --
>>> 2.20.1
>>>
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: Jiri Pirko @ 2019-08-30 17:04 UTC (permalink / raw)
To: David Ahern
Cc: Roopa Prabhu, Michal Kubecek, netdev, David Miller,
Jakub Kicinski, Stephen Hemminger, dcbw, Andrew Lunn, parav,
Saeed Mahameed, mlxsw
In-Reply-To: <9ec43634-d2e9-b976-1936-5b7ddc587b76@gmail.com>
Fri, Aug 30, 2019 at 04:47:41PM CEST, dsahern@gmail.com wrote:
>On 8/30/19 8:35 AM, Roopa Prabhu wrote:
>> On Wed, Aug 28, 2019 at 10:26 PM Michal Kubecek <mkubecek@suse.cz> wrote:
>>>
>>> On Wed, Aug 28, 2019 at 09:36:41PM -0700, Roopa Prabhu wrote:
>>>>
>>>> yes, correct. I mentioned that because I was wondering if we can
>>>> think along the same lines for this API.
>>>> eg
>>>> (a) RTM_NEWLINK always replaces the list attribute
>>>> (b) RTM_SETLINK with NLM_F_APPEND always appends to the list attribute
>>>> (c) RTM_DELLINK with NLM_F_APPEND updates the list attribute
>>>>
>>>> (It could be NLM_F_UPDATE if NLM_F_APPEND sounds weird in the del
>>>> case. I have not looked at the full dellink path if it will work
>>>> neatly..its been a busy day )
>>>
>>> AFAICS rtnl_dellink() calls nlmsg_parse_deprecated() so that even
>>> current code would ignore any future attribute in RTM_DELLINK message
>>> (any kernel before the strict validation was introduced definitely will)
>>> and it does not seem to check NLM_F_APPEND or NLM_F_UPDATE either. So
>>> unless I missed something, such message would result in deleting the
>>> network device (if possible) with any kernel not implementing the
>>> feature.
>>
>> ok, ack. yes today it does. I was hinting if that can be changed to
>> support list update with a flag like the RTM_DELLINK AF_BRIDGE does
>> for vlan list del.
>>
>> so to summarize, i think we have discussed the following options to
>> update a netlink list attribute so far:
>> (a) encode an optional attribute/flag in the list attribute in
>> RTM_SETLINK to indicate if it is a add or del
>
>The ALT_IFNAME attribute could also be a struct that has both the string
>and a flag.
Not a struct, please :/
>
>> (b) Use a flag in RTM_SETLINK and RTM_DELINK to indicate add/del
>> (close to bridge vlan add/del)
>> (c) introduce a separate generic msg type to add/del to a list
>> attribute (IIUC this does need a separate msg type per subsystem or
>> netlink API)
>>
>
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: Jiri Pirko @ 2019-08-30 17:03 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Michal Kubecek, netdev, David Miller, Jakub Kicinski, David Ahern,
Stephen Hemminger, dcbw, Andrew Lunn, parav, Saeed Mahameed,
mlxsw
In-Reply-To: <CAJieiUgGY4amm_z1VGgBF-3WZceah+R5OVLEi=O2RS8RGpC9dg@mail.gmail.com>
Fri, Aug 30, 2019 at 04:35:23PM CEST, roopa@cumulusnetworks.com wrote:
>On Wed, Aug 28, 2019 at 10:26 PM Michal Kubecek <mkubecek@suse.cz> wrote:
>>
>> On Wed, Aug 28, 2019 at 09:36:41PM -0700, Roopa Prabhu wrote:
>> >
>> > yes, correct. I mentioned that because I was wondering if we can
>> > think along the same lines for this API.
>> > eg
>> > (a) RTM_NEWLINK always replaces the list attribute
>> > (b) RTM_SETLINK with NLM_F_APPEND always appends to the list attribute
>> > (c) RTM_DELLINK with NLM_F_APPEND updates the list attribute
>> >
>> > (It could be NLM_F_UPDATE if NLM_F_APPEND sounds weird in the del
>> > case. I have not looked at the full dellink path if it will work
>> > neatly..its been a busy day )
>>
>> AFAICS rtnl_dellink() calls nlmsg_parse_deprecated() so that even
>> current code would ignore any future attribute in RTM_DELLINK message
>> (any kernel before the strict validation was introduced definitely will)
>> and it does not seem to check NLM_F_APPEND or NLM_F_UPDATE either. So
>> unless I missed something, such message would result in deleting the
>> network device (if possible) with any kernel not implementing the
>> feature.
>
>ok, ack. yes today it does. I was hinting if that can be changed to
>support list update with a flag like the RTM_DELLINK AF_BRIDGE does
>for vlan list del.
>
>so to summarize, i think we have discussed the following options to
>update a netlink list attribute so far:
>(a) encode an optional attribute/flag in the list attribute in
>RTM_SETLINK to indicate if it is a add or del
>(b) Use a flag in RTM_SETLINK and RTM_DELINK to indicate add/del
>(close to bridge vlan add/del)
Nope, bridge vlan add/del is done according to the cmd, not any flag.
>(c) introduce a separate generic msg type to add/del to a list
>attribute (IIUC this does need a separate msg type per subsystem or
>netlink API)
^ permalink raw reply
* [PATCH net] tc-testing: don't hardcode 'ip' in nsPlugin.py
From: Davide Caratti @ 2019-08-30 16:51 UTC (permalink / raw)
To: Hangbin Liu, Roman Mashak, Vlad Buslov, David S. Miller,
Lucas Bates, Nicolas Dichtel, netdev
Cc: Marcelo Ricardo Leitner
the following tdc test fails on Fedora:
# ./tdc.py -e 2638
-- ns/SubPlugin.__init__
Test 2638: Add matchall and try to get it
-----> prepare stage *** Could not execute: "$TC qdisc add dev $DEV1 clsact"
-----> prepare stage *** Error message: "/bin/sh: ip: command not found"
returncode 127; expected [0]
-----> prepare stage *** Aborting test run.
Let nsPlugin.py use the 'IP' variable introduced with commit 92c1a19e2fb9
("tc-tests: added path to ip command in tdc"), so that the path to 'ip' is
correctly resolved to the value we have in tdc_config.py.
# ./tdc.py -e 2638
-- ns/SubPlugin.__init__
Test 2638: Add matchall and try to get it
All test results:
1..1
ok 1 2638 - Add matchall and try to get it
Fixes: 489ce2f42514 ("tc-testing: Restore original behaviour for namespaces in tdc")
Reported-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
.../tc-testing/plugin-lib/nsPlugin.py | 22 +++++++++----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/tools/testing/selftests/tc-testing/plugin-lib/nsPlugin.py b/tools/testing/selftests/tc-testing/plugin-lib/nsPlugin.py
index affa7f2d9670..9539cffa9e5e 100644
--- a/tools/testing/selftests/tc-testing/plugin-lib/nsPlugin.py
+++ b/tools/testing/selftests/tc-testing/plugin-lib/nsPlugin.py
@@ -64,7 +64,7 @@ class SubPlugin(TdcPlugin):
cmdlist.insert(0, self.args.NAMES['NS'])
cmdlist.insert(0, 'exec')
cmdlist.insert(0, 'netns')
- cmdlist.insert(0, 'ip')
+ cmdlist.insert(0, self.args.NAMES['IP'])
else:
pass
@@ -78,16 +78,16 @@ class SubPlugin(TdcPlugin):
return command
def _ports_create(self):
- cmd = 'ip link add $DEV0 type veth peer name $DEV1'
+ cmd = '$IP link add $DEV0 type veth peer name $DEV1'
self._exec_cmd('pre', cmd)
- cmd = 'ip link set $DEV0 up'
+ cmd = '$IP link set $DEV0 up'
self._exec_cmd('pre', cmd)
if not self.args.namespace:
- cmd = 'ip link set $DEV1 up'
+ cmd = '$IP link set $DEV1 up'
self._exec_cmd('pre', cmd)
def _ports_destroy(self):
- cmd = 'ip link del $DEV0'
+ cmd = '$IP link del $DEV0'
self._exec_cmd('post', cmd)
def _ns_create(self):
@@ -97,16 +97,16 @@ class SubPlugin(TdcPlugin):
'''
self._ports_create()
if self.args.namespace:
- cmd = 'ip netns add {}'.format(self.args.NAMES['NS'])
+ cmd = '$IP netns add {}'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
- cmd = 'ip link set $DEV1 netns {}'.format(self.args.NAMES['NS'])
+ cmd = '$IP link set $DEV1 netns {}'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
- cmd = 'ip -n {} link set $DEV1 up'.format(self.args.NAMES['NS'])
+ cmd = '$IP -n {} link set $DEV1 up'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
if self.args.device:
- cmd = 'ip link set $DEV2 netns {}'.format(self.args.NAMES['NS'])
+ cmd = '$IP link set $DEV2 netns {}'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
- cmd = 'ip -n {} link set $DEV2 up'.format(self.args.NAMES['NS'])
+ cmd = '$IP -n {} link set $DEV2 up'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
def _ns_destroy(self):
@@ -115,7 +115,7 @@ class SubPlugin(TdcPlugin):
devices as well)
'''
if self.args.namespace:
- cmd = 'ip netns delete {}'.format(self.args.NAMES['NS'])
+ cmd = '$IP netns delete {}'.format(self.args.NAMES['NS'])
self._exec_cmd('post', cmd)
def _exec_cmd(self, stage, command):
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V40 23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: David Howells @ 2019-08-30 16:32 UTC (permalink / raw)
To: Matthew Garrett
Cc: dhowells, jmorris, linux-security-module, linux-kernel, linux-api,
Alexei Starovoitov, Matthew Garrett, Kees Cook, netdev,
Chun-Yi Lee, Daniel Borkmann
In-Reply-To: <20190820001805.241928-24-matthewgarrett@google.com>
Matthew Garrett <matthewgarrett@google.com> wrote:
> From: David Howells <dhowells@redhat.com>
>
> bpf_read() and bpf_read_str() could potentially be abused to (eg) allow
> private keys in kernel memory to be leaked. Disable them if the kernel
> has been locked down in confidentiality mode.
>
> Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Signed-off-by: Matthew Garrett <mjg59@google.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> cc: netdev@vger.kernel.org
> cc: Chun-Yi Lee <jlee@suse.com>
> cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: [PATCH] net/skbuff: silence warnings under memory pressure
From: Eric Dumazet @ 2019-08-30 16:15 UTC (permalink / raw)
To: Qian Cai, Eric Dumazet, davem; +Cc: netdev, linux-mm, linux-kernel
In-Reply-To: <1567178728.5576.32.camel@lca.pw>
On 8/30/19 5:25 PM, Qian Cai wrote:
> On Fri, 2019-08-30 at 17:11 +0200, Eric Dumazet wrote:
>>
>> On 8/30/19 4:57 PM, Qian Cai wrote:
>>> When running heavy memory pressure workloads, the system is throwing
>>> endless warnings below due to the allocation could fail from
>>> __build_skb(), and the volume of this call could be huge which may
>>> generate a lot of serial console output and cosumes all CPUs as
>>> warn_alloc() could be expensive by calling dump_stack() and then
>>> show_mem().
>>>
>>> Fix it by silencing the warning in this call site. Also, it seems
>>> unnecessary to even print a warning at all if the allocation failed in
>>> __build_skb(), as it may just retransmit the packet and retry.
>>>
>>
>> Same patches are showing up there and there from time to time.
>>
>> Why is this particular spot interesting, against all others not adding
>> __GFP_NOWARN ?
>>
>> Are we going to have hundred of patches adding __GFP_NOWARN at various points,
>> or should we get something generic to not flood the syslog in case of memory
>> pressure ?
>>
>
> From my testing which uses LTP oom* tests. There are only 3 places need to be
> patched. The other two are in IOMMU code for both Intel and AMD. The place is
> particular interesting because it could cause the system with floating serial
> console output for days without making progress in OOM. I suppose it ends up in
> a looping condition that warn_alloc() would end up generating more calls into
> __build_skb() via ksoftirqd.
>
Yes, but what about other tests done by other people ?
You do not really answer my last question, which was really the point I tried
to make.
If there is a risk of flooding the syslog, we should fix this generically
in mm layer, not adding hundred of __GFP_NOWARN all over the places.
Maybe just make __GFP_NOWARN the default, I dunno.
^ permalink raw reply
* Re: [PATCH net-next 03/14] bnxt_en: Refactor bnxt_sriov_enable().
From: Michael Chan @ 2019-08-30 16:00 UTC (permalink / raw)
To: Leon Romanovsky
Cc: David Miller, Netdev, Vasundhara Volam, Jiri Pirko, Ray Jui
In-Reply-To: <20190830091838.GC12611@unreal>
On Fri, Aug 30, 2019 at 2:18 AM Leon Romanovsky <leon@kernel.org> wrote:
>
> On Mon, Aug 26, 2019 at 09:00:45AM +0300, Leon Romanovsky wrote:
> > On Sun, Aug 25, 2019 at 11:54:54PM -0400, Michael Chan wrote:
> > > Refactor the hardware/firmware configuration portion in
> > > bnxt_sriov_enable() into a new function bnxt_cfg_hw_sriov(). This
> > > new function can be called after a firmware reset to reconfigure the
> > > VFs previously enabled.
> >
> > I wonder what does it mean for already bound VFs to vfio driver?
> > Will you rebind them as well? Can I assume that FW error in one VF
> > will trigger "restart" of other VFs too?
>
> Care to reply?
>
>
Sorry, I missed your email earlier.
A firmware reset/recovery has no direct effect on a VF or any function
if it is just idle. The PCI interface of any function does not get
reset.
If a VF driver (Linux VF driver, DPDK driver, etc) has initialized on
that function, meaning it has exchanged messages with firmware to
register itself and to allocate resources (such as rings), then the
firmware reset will require all those resources to be re-discovered
and re-initialized. These VF resources are initially assigned by the
PF. So this refactored function on the PF is to re-assign these
resources back to the VF after the firmware reset. Again, if the VF
is just bound to vfio and is idle, there is no effect.
^ permalink raw reply
* Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: Florian Westphal @ 2019-08-30 15:58 UTC (permalink / raw)
To: Leonardo Bras
Cc: Florian Westphal, Pablo Neira Ayuso, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel, Jozsef Kadlecsik,
Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <4b3b52d0f73aeb1437b4b2a46325b36e9c41f92b.camel@linux.ibm.com>
Leonardo Bras <leonardo@linux.ibm.com> wrote:
> On Thu, 2019-08-29 at 22:58 +0200, Florian Westphal wrote:
> [...]
> > 1. add a patch to BREAK in nft_fib_netdev.c for !ipv6_mod_enabled()
> [...]
>
> But this is still needed? I mean, in nft_fib_netdev_eval there are only
> 2 functions being called for IPv6 protocol : nft_fib6_eval and
> nft_fib6_eval_type. Both are already protected by this current patch.
>
> Is your 1st suggestion about this patch, or you think it's better to
> move this change to nft_fib_netdev_eval ?
Ah, it was the latter.
Making bridge netfilter not pass packets up with ipv6 off closes
the problem for fib_ipv6 and inet, so only _netdev.c needs fixing.
^ permalink raw reply
* RE: [PATCH] rtl_nic: add firmware rtl8125a-3
From: Hau @ 2019-08-30 15:56 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Josh Boyer, Linux Firmware, nic_swsd, netdev@vger.kernel.org,
Hayes Wang
In-Reply-To: <b4faccd6-10ff-c6ab-523d-39a1734e1b72@gmail.com>
> On 27.08.2019 14:08, Josh Boyer wrote:
> > On Mon, Aug 26, 2019 at 6:23 PM Heiner Kallweit <hkallweit1@gmail.com>
> wrote:
> >>
> >> This adds firmware rtl8125a-3 for Realtek's 2.5Gbps chip RTL8125.
> >>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >> ---
> >> Firmware file was provided by Realtek and they asked me to submit it.
> >
> > Can we get a Signed-off-by from someone at Realtek then?
> >
> Hi Hau,
>
> can you reply and add your Signed-off-by?
> I saw that all the RTL8168 firmware was submitted by Hayes Wang.
>
> > josh
> >
> Heiner
>
Signed-off-by: Chunhao Lin <hau@realtek.com>
> >> The related extension to r8169 driver will be submitted in the next days.
> >> ---
> >> WHENCE | 3 +++
> >> rtl_nic/rtl8125a-3.fw | Bin 0 -> 3456 bytes
> >> 2 files changed, 3 insertions(+)
> >> create mode 100644 rtl_nic/rtl8125a-3.fw
> >>
> >> diff --git a/WHENCE b/WHENCE
> >> index fb12924..dbec18a 100644
> >> --- a/WHENCE
> >> +++ b/WHENCE
> >> @@ -2906,6 +2906,9 @@ Version: 0.0.2
> >> File: rtl_nic/rtl8107e-2.fw
> >> Version: 0.0.2
> >>
> >> +File: rtl_nic/rtl8125a-3.fw
> >> +Version: 0.0.1
> >> +
> >> Licence:
> >> * Copyright © 2011-2013, Realtek Semiconductor Corporation
> >> *
> >> diff --git a/rtl_nic/rtl8125a-3.fw b/rtl_nic/rtl8125a-3.fw new file
> >> mode 100644 index
> >>
> 0000000000000000000000000000000000000000..fac635263f92e8d9734456b75
> 93
> >> 2b2088edd5ef9
> >> GIT binary patch
> >> literal 3456
> >>
> zcmb7G4@{Kj8Gr9M&hw<l39l3>p*MPE#webM6qsqQiuC(hXPi?+wDL#V(Z*4#K%
> FD{
> >>
> zd#PH+tTJbqZG?a`)*5G*m3F2zmN`7hx;2*IKiVu;;~Hwa_E@^5+Z^ooav$qyWa|!|
> >> z{J!V^^FHtMe%~vE5S!~a<<HMqSUGn=c_2HGJ>M6|pO=$6Z+-
> !F`d2|JjuT=?tX!6t
> >> zo1eG1ysol-V@-
> KgU0(T?#@f6Efr9d!!2E*zz=G_mCu@CyK;goi!iD+b1yk6B2%b&6
> >> z7edS;xkzqO0?9-2l9EW0ltM}+rIFG}86+PmljJ95fhB~6Z~~0y3JYX}?Z^&0uqy1t
> >>
> zny?FN!)}}nC*Ym12kkF<@t&E4_=v=ynF9AnDz2DmaE+uRv6r!*@!^m!6NmhMO
> zq8r
> >> zcySgS;n{HZ&ViVjO+Em7C<o$9E{w7~#?6OA6vF-
> CA|!?$MBkPmUNaZNIZ}kPTZ-Wd
> >> z8F2PIf~lcpz}RxchgOhZNnAy~1V!<ssEIFw^W*gx{=)|N&sV@7s=~F-
> YS=QKK)AC8
> >>
> z;l`&BHaB5(q!u4F*5UicX4Dw<xZc@_xQwl|*+!ct+H9u{FeB7V|DE*TO<fCht<>$I
> >> zZZG}Y@U*d?z6a>rPW?gZU!wjH^_^&crVIA-
> hauiRf}*mc@O*L%b>cXFD^8&Io|9br
> >>
> zFS+(#A<NUl=QsF#3U7Megl)!Y%#NIan9+;JM$V!#)QA3t5H6bia7TWJOXlz4ioA=<
> >> z<^?z-1MK-A9Fa>HXt;u_<`7nle1Pws`y;xZ4b$%$RvXt*Vtj-(#xP2a8yGS^#rwu*
> >> z7&RlXNB)8`;|q+Lf8+C)SZDkL{T(+MYZPk@p$0naYDvhUdK;W-
> &~&K<5x2TvCa4ES
> >>
> zJSq_Os=`o`>Ti(hqM4#RkyLfbOj8MwbamOxQ0|CNT`@D2E8<rJ4O!}{IZMSyW~=P
> b
> >> z9LCG0O+ej0lA~sw%T-
> ;^=BaOn@)@g8tu_{^65~O&#t5oXW3d`Ciq!i?u^KfEWsf|f
> >>
> z%8X@d%v{dr6>6QaQuTMNV*C=d)+lAYWhy1Kp7A%(ze4qPRH@`pHTfshkXfVRB
> 2TgY
> >>
> zO=`+Wt(q39Q=W61)m5XOc8&DkO5CPgp(bTNzg>y9p~8jDs$zJj5<R=s;Oi~Q^>M4
> (
> >>
> zG`vTNq`hitUz@`B_Nx)&fWp3Z<>))8?4g&GICDrH_jW38Z<lJiahS3rlpR$<98=@x
> >> z6ix)=-SB%nIOXwTePI%gc_p@upI;Gdo~F;Tmw)5`y%^_39nX1Ki-J6~L1FKz7NSjv
> >> z_`nkPz3?L$w%rohr-(vgBF1<i;qBEnDP75AC6X+Z8dD{_;JbnNV+;3L_)`miW?_eg
> >> z-4-4vre2o#VTHs{P{PCaz|dle45F5=t7KfRt3*ceh=r$#TAy7mkxtwHW#j)EHgmp)
> >> zO)hO_GH>cb5{`=!(@#j)h_-jxgCneiD9Hcd;ix`Q>rX~yy2c{beS3_|m>9m87;BeK
> >> z9^<~->L`kd5sZmZuw?QWNw>vliHU)j7&EQ4-f1m1#+c~6-
> j5U9k9~bn**#pV?$N|-
> >> zq$Nr8T#$I{J?c3t2VJ-F9=Aj_^{tkE`!wz?XF~Vaag5Xw_4`&lQTP1kQQmM$_|B0(
> >>
> zOkxdl@0Tb}k#O<ZNq?P7^BP@o5?P$tDMUYUDdm~Ohjk2MA!9p<P0Z~eCa@+
> uv7NOF
> >> zV)t~$Ac`@GiSytUlb?qfh~`cEKhXXQ`gkQS+oQgJX8gniiK%+szlqBBQMQ+LjIoYA
> >> z7Pea0V&QHJcUss?e1U!-
> enM;`#@W7FhmW$!&b34|Z>oiU3%_IGY6~}8_<=_875$5K
> >> z-p<>elW^0nO-Xb$v)?-<5?*G%4-
> kJO5#)Zu+T&X8&rjZA4DRX1phN*@#Ln3Z5`&x>
> >> zM^Cgz;x5{-ci}0VyQ8FT#^zi&IL{9H?xHU!(>!!e${wT4$GqBa3H>xiG*Va3d7hBl
> >> z$-
> lAV)_T3WsTa}QwwT;{)^yFKtnb^bPxFJExzl=W&oejIewS6dj^AhH>tVh&*5~e`
> >>
> zja9dg7?{KsZ_$^!dgjpQL9gf03g&nvnzMv6vp=S9DYVsnn`y<1qkR|cAF7hLwo&4_
> >> z$0b%#ug_6NWfb*$Il}q#a(!Ob6=ePMXrpB-
> v<#HJEP3C!v!5@<?;Dn1MU0<*f8Qxz
> >>
> zAjU7*@~eyS)8C3a`2}PA^u1Eoi5NfK?_u^^&&MtM&ozI+{=2wFEidM}?R=ite~tg7
> >> zpYGYyoP*`0xugV=o@1RyFwcMDQ>Obe;jicCb=vBh2MhU4<KB$Vk2NcQ<(`-
> qXixrA
> >> z8^49!$+$sGAily`auZvb-$fkYEIElgD0dJaC)$bQXUsw`@urBL?<RiJ1G^-)6L-BT
> >> z@#-RprR2w-
> mqwqPKV$B{bA8MiN1HEyEpap~@gZZ_*el!TTw^JF*(K5a0Q2#@rtsUg
> >> zt6SovowDhaJ<ob6YnhO-UOUgSow9UNkB-
> M#+sN~3dy@Qhi9cEVf73Z`N^D^5uW{WK
> >> zME%~Yvas61t;E=S%Z@SO6V|;&h-
> h!3cbdD!=(z6g@jH#a_vpS&+;={={DQpi2<!K6
> >> DeEY6F
> >>
> >> literal 0
> >> HcmV?d00001
> >>
> >> --
> >> 2.23.0
> >>
> >
>
>
> ------Please consider the environment before printing this e-mail.
^ permalink raw reply
* Re: [PATCH bpf-next v6 00/12] XDP unaligned chunk placement support
From: Jonathan Lemon @ 2019-08-30 15:52 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-1-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch set adds the ability to use unaligned chunks in the XDP umem.
Thanks, Kevin for your hard work and perseverance on this patch set!
--
Jonathan
^ permalink raw reply
* Re: [PATCH bpf-next v6 12/12] doc/af_xdp: include unaligned chunk case
From: Jonathan Lemon @ 2019-08-30 15:51 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-13-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> The addition of unaligned chunks mode, the documentation needs to be
> updated to indicate that the incoming addr to the fill ring will only be
> masked if the user application is run in the aligned chunk mode. This patch
> also adds a line to explicitly indicate that the incoming addr will not be
> masked if running the user application in the unaligned chunk mode.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 11/12] samples/bpf: use hugepages in xdpsock app
From: Jonathan Lemon @ 2019-08-30 15:51 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-12-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch modifies xdpsock to use mmap instead of posix_memalign. With
> this change, we can use hugepages when running the application in unaligned
> chunks mode. Using hugepages makes it more likely that we have physically
> contiguous memory, which supports the unaligned chunk mode better.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 10/12] samples/bpf: add buffer recycling for unaligned chunks to xdpsock
From: Jonathan Lemon @ 2019-08-30 15:49 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-11-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch adds buffer recycling support for unaligned buffers. Since we
> don't mask the addr to 2k at umem_reg in unaligned mode, we need to make
> sure we give back the correct (original) addr to the fill queue. We achieve
> this using the new descriptor format and associated masks. The new format
> uses the upper 16-bits for the offset and the lower 48-bits for the addr.
> Since we have a field for the offset, we no longer need to modify the
> actual address. As such, all we have to do to get back the original address
> is mask for the lower 48 bits (i.e. strip the offset and we get the address
> on it's own).
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: Leonardo Bras @ 2019-08-30 15:48 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, David S. Miller, netfilter-devel, coreteam,
netdev, linux-kernel, Jozsef Kadlecsik, Alexey Kuznetsov,
Hideaki YOSHIFUJI
In-Reply-To: <20190829205832.GM20113@breakpoint.cc>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
On Thu, 2019-08-29 at 22:58 +0200, Florian Westphal wrote:
[...]
> 1. add a patch to BREAK in nft_fib_netdev.c for !ipv6_mod_enabled()
[...]
But this is still needed? I mean, in nft_fib_netdev_eval there are only
2 functions being called for IPv6 protocol : nft_fib6_eval and
nft_fib6_eval_type. Both are already protected by this current patch.
Is your 1st suggestion about this patch, or you think it's better to
move this change to nft_fib_netdev_eval ?
Best regards,
Leonardo Bras
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next v6 09/12] samples/bpf: add unaligned chunks mode support to xdpsock
From: Jonathan Lemon @ 2019-08-30 15:47 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-10-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch adds support for the unaligned chunks mode. The addition of the
> unaligned chunks option will allow users to run the application with more
> relaxed chunk placement in the XDP umem.
>
> Unaligned chunks mode can be used with the '-u' or '--unaligned' command
> line options.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 08/12] libbpf: add flags to umem config
From: Jonathan Lemon @ 2019-08-30 15:46 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-9-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch adds a 'flags' field to the umem_config and umem_reg structs.
> This will allow for more options to be added for configuring umems.
>
> The first use for the flags field is to add a flag for unaligned chunks
> mode. These flags can either be user-provided or filled with a default.
>
> Since we change the size of the xsk_umem_config struct, we need to version
> the ABI. This patch includes the ABI versioning for xsk_umem__create. The
> Makefile was also updated to handle multiple function versions in
> check-abi.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ 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