* [PATCH net v3] vxlan: do not destroy fdb if register_netdevice() is failed
From: Taehee Yoo @ 2019-06-28 5:07 UTC (permalink / raw)
To: davem, roopa, petrm, netdev; +Cc: ap420073
__vxlan_dev_create() destroys FDB using specific pointer which indicates
a fdb when error occurs.
But that pointer should not be used when register_netdevice() fails because
register_netdevice() internally destroys fdb when error occurs.
This patch makes vxlan_fdb_create() to do not link fdb entry to vxlan dev
internally.
Instead, a new function vxlan_fdb_insert() is added to link fdb to vxlan
dev.
vxlan_fdb_insert() is called after calling register_netdevice().
This routine can avoid situation that ->ndo_uninit() destroys fdb entry
in error path of register_netdevice().
Hence, error path of __vxlan_dev_create() routine can have an opportunity
to destroy default fdb entry by hand.
Test command
ip link add bonding_masters type vxlan id 0 group 239.1.1.1 \
dev enp0s9 dstport 4789
Splat looks like:
[ 213.392816] kasan: GPF could be caused by NULL-ptr deref or user memory access
[ 213.401257] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 213.402178] CPU: 0 PID: 1414 Comm: ip Not tainted 5.2.0-rc5+ #256
[ 213.402178] RIP: 0010:vxlan_fdb_destroy+0x120/0x220 [vxlan]
[ 213.402178] Code: df 48 8b 2b 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 06 01 00 00 4c 8b 63 08 48 b8 00 00 00 00 00 fc d
[ 213.402178] RSP: 0018:ffff88810cb9f0a0 EFLAGS: 00010202
[ 213.402178] RAX: dffffc0000000000 RBX: ffff888101d4a8c8 RCX: 0000000000000000
[ 213.402178] RDX: 1bd5a00000000040 RSI: ffff888101d4a8c8 RDI: ffff888101d4a8d0
[ 213.402178] RBP: 0000000000000000 R08: fffffbfff22b72d9 R09: 0000000000000000
[ 213.402178] R10: 00000000ffffffef R11: 0000000000000000 R12: dead000000000200
[ 213.402178] R13: ffff88810cb9f1f8 R14: ffff88810efccda0 R15: ffff88810efccda0
[ 213.402178] FS: 00007f7f6621a0c0(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
[ 213.402178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 213.402178] CR2: 000055746f0807d0 CR3: 00000001123e0000 CR4: 00000000001006f0
[ 213.402178] Call Trace:
[ 213.402178] __vxlan_dev_create+0x3a9/0x7d0 [vxlan]
[ 213.402178] ? vxlan_changelink+0x740/0x740 [vxlan]
[ 213.402178] ? rcu_read_unlock+0x60/0x60 [vxlan]
[ 213.402178] ? __kasan_kmalloc.constprop.3+0xa0/0xd0
[ 213.402178] vxlan_newlink+0x8d/0xc0 [vxlan]
[ 213.402178] ? __vxlan_dev_create+0x7d0/0x7d0 [vxlan]
[ 213.554119] ? __netlink_ns_capable+0xc3/0xf0
[ 213.554119] __rtnl_newlink+0xb75/0x1180
[ 213.554119] ? rtnl_link_unregister+0x230/0x230
[ ... ]
Fixes: 0241b836732f ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
Suggested-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
v2 -> v3 :
- Use function name vxlan_fdb_insert() instead of vxlan_fdb_link()
- Add and use __vxlan_fdb_free() instead of call_rcu()
v1 -> v2 :
- Add a new function vxlan_fdb_link().
- Fix fdb entry leak.
- Update description.
drivers/net/vxlan.c | 37 +++++++++++++++++++++++++++----------
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 083f3f0bf37f..b4283f52a09d 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -804,6 +804,14 @@ static struct vxlan_fdb *vxlan_fdb_alloc(struct vxlan_dev *vxlan,
return f;
}
+static void vxlan_fdb_insert(struct vxlan_dev *vxlan, const u8 *mac,
+ __be32 src_vni, struct vxlan_fdb *f)
+{
+ ++vxlan->addrcnt;
+ hlist_add_head_rcu(&f->hlist,
+ vxlan_fdb_head(vxlan, mac, src_vni));
+}
+
static int vxlan_fdb_create(struct vxlan_dev *vxlan,
const u8 *mac, union vxlan_addr *ip,
__u16 state, __be16 port, __be32 src_vni,
@@ -829,18 +837,13 @@ static int vxlan_fdb_create(struct vxlan_dev *vxlan,
return rc;
}
- ++vxlan->addrcnt;
- hlist_add_head_rcu(&f->hlist,
- vxlan_fdb_head(vxlan, mac, src_vni));
-
*fdb = f;
return 0;
}
-static void vxlan_fdb_free(struct rcu_head *head)
+static void __vxlan_fdb_free(struct vxlan_fdb *f)
{
- struct vxlan_fdb *f = container_of(head, struct vxlan_fdb, rcu);
struct vxlan_rdst *rd, *nd;
list_for_each_entry_safe(rd, nd, &f->remotes, list) {
@@ -850,6 +853,13 @@ static void vxlan_fdb_free(struct rcu_head *head)
kfree(f);
}
+static void vxlan_fdb_free(struct rcu_head *head)
+{
+ struct vxlan_fdb *f = container_of(head, struct vxlan_fdb, rcu);
+
+ __vxlan_fdb_free(f);
+}
+
static void vxlan_fdb_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f,
bool do_notify, bool swdev_notify)
{
@@ -977,6 +987,7 @@ static int vxlan_fdb_update_create(struct vxlan_dev *vxlan,
if (rc < 0)
return rc;
+ vxlan_fdb_insert(vxlan, mac, src_vni, f);
rc = vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f), RTM_NEWNEIGH,
swdev_notify, extack);
if (rc)
@@ -3571,12 +3582,17 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
if (err)
goto errout;
- /* notify default fdb entry */
if (f) {
+ vxlan_fdb_insert(vxlan, all_zeros_mac,
+ vxlan->default_dst.remote_vni, f);
+
+ /* notify default fdb entry */
err = vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f),
RTM_NEWNEIGH, true, extack);
- if (err)
- goto errout;
+ if (err) {
+ vxlan_fdb_destroy(vxlan, f, false, false);
+ goto unregister;
+ }
}
list_add(&vxlan->next, &vn->vxlan_list);
@@ -3588,7 +3604,8 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
* destroy the entry by hand here.
*/
if (f)
- vxlan_fdb_destroy(vxlan, f, false, false);
+ __vxlan_fdb_free(f);
+unregister:
if (unregister)
unregister_netdevice(dev);
return err;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 0/4] Compile-test UAPI and kernel headers
From: Masahiro Yamada @ 2019-06-28 4:57 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Song Liu, Jakub Kicinski, open list:DOCUMENTATION, Palmer Dabbelt,
Alexei Starovoitov, linux-riscv, Sam Ravnborg, Kees Cook,
xdp-newbies, Daniel Borkmann, Jonathan Corbet, Anton Vorontsov,
John Fastabend, Yonghong Song, Albert Ou, Jesper Dangaard Brouer,
Jani Nikula, Michal Marek,
moderated list:ARM/Mediatek SoC support, Matthias Brugger,
linux-arm-kernel, Tony Luck, Networking,
Linux Kernel Mailing List, David S. Miller, Colin Cross, bpf,
Martin KaFai Lau
In-Reply-To: <20190627163903.28398-1-yamada.masahiro@socionext.com>
On Fri, Jun 28, 2019 at 1:41 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> 1/4: Compile-test exported headers (reworked in v2)
>
> 2/4: fix a flaw I noticed when I was working on this series.
> Avoid generating intermediate wrappers.
>
> 3/4: maybe useful for 4/4 and in some other places.
> Add header-test-pattern-y syntax.
>
> 4/4: Compile-test kernel-space headers in include/.
> v2: compile as many headers as possible.
> v3: exclude more headers causing build errors
I push this series to
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
header-test-v3
for somebody who wants to test it.
>
> Masahiro Yamada (4):
> kbuild: compile-test UAPI headers to ensure they are self-contained
> kbuild: do not create wrappers for header-test-y
> kbuild: support header-test-pattern-y
> kbuild: compile-test kernel headers to ensure they are self-contained
>
> .gitignore | 1 -
> Documentation/dontdiff | 1 -
> Documentation/kbuild/makefiles.txt | 13 +-
> Makefile | 4 +-
> include/Kbuild | 1250 ++++++++++++++++++++++++++++
> init/Kconfig | 22 +
> scripts/Makefile.build | 10 +-
> scripts/Makefile.lib | 13 +-
> scripts/cc-system-headers.sh | 8 +
> usr/.gitignore | 1 -
> usr/Makefile | 2 +
> usr/include/.gitignore | 3 +
> usr/include/Makefile | 134 +++
> 13 files changed, 1449 insertions(+), 13 deletions(-)
> create mode 100644 include/Kbuild
> create mode 100755 scripts/cc-system-headers.sh
> create mode 100644 usr/include/.gitignore
> create mode 100644 usr/include/Makefile
>
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* linux-next: manual merge of the devicetree tree with the net-next tree
From: Stephen Rothwell @ 2019-06-28 4:56 UTC (permalink / raw)
To: Rob Herring, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Heiner Kallweit, Maxime Ripard
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/net/ethernet.txt
between commit:
79b647a0c0d5 ("dt-bindings: net: document new usxgmii phy mode")
from the net-next tree and commit:
4e7a33bff7d7 ("dt-bindings: net: Add YAML schemas for the generic Ethernet options")
from the devicetree tree.
I fixed it up (the latter seems to include the change made by the former,
so I just used the latter) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] net: stmmac: add sanity check to device_property_read_u32_array call
From: Martin Blumenstingl @ 2019-06-28 4:15 UTC (permalink / raw)
To: Colin Ian King
Cc: alexandre.torgue, davem, joabreu, kernel-janitors,
linux-arm-kernel, linux-kernel, linux-stm32, mcoquelin.stm32,
netdev, peppe.cavallaro
In-Reply-To: <c46d2d17-c35b-46f0-0674-0c55bea3a272@canonical.com>
On Tue, Jun 25, 2019 at 9:58 AM Colin Ian King <colin.king@canonical.com> wrote:
>
> On 25/06/2019 05:44, Martin Blumenstingl wrote:
> > Hi Colin,
> >
> > On Thu, Jun 20, 2019 at 3:34 AM Martin Blumenstingl
> > <martin.blumenstingl@googlemail.com> wrote:
> >>
> >> Hi Colin,
> >>
> >> On Wed, Jun 19, 2019 at 8:55 AM Colin Ian King <colin.king@canonical.com> wrote:
> >>>
> >>> On 19/06/2019 06:13, Martin Blumenstingl wrote:
> >>>> Hi Colin,
> >>>>
> >>>>> Currently the call to device_property_read_u32_array is not error checked
> >>>>> leading to potential garbage values in the delays array that are then used
> >>>>> in msleep delays. Add a sanity check to the property fetching.
> >>>>>
> >>>>> Addresses-Coverity: ("Uninitialized scalar variable")
> >>>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> >>>> I have also sent a patch [0] to fix initialize the array.
> >>>> can you please look at my patch so we can work out which one to use?
> >>>>
> >>>> my concern is that the "snps,reset-delays-us" property is optional,
> >>>> the current dt-bindings documentation states that it's a required
> >>>> property. in reality it isn't, there are boards (two examples are
> >>>> mentioned in my patch: [0]) without it.
> >>>>
> >>>> so I believe that the resulting behavior has to be:
> >>>> 1. don't delay if this property is missing (instead of delaying for
> >>>> <garbage value> ms)
> >>>> 2. don't error out if this property is missing
> >>>>
> >>>> your patch covers #1, can you please check whether #2 is also covered?
> >>>> I tested case #2 when submitting my patch and it worked fine (even
> >>>> though I could not reproduce the garbage values which are being read
> >>>> on some boards)
> > in the meantime I have tested your patch.
> > when I don't set the "snps,reset-delays-us" property then I get the
> > following error:
> > invalid property snps,reset-delays-us
> >
> > my patch has landed in the meantime: [0]
> > how should we proceed with your patch?
>
> I'm out of the office today. I'll get back to you on this tomorrow.
gentle ping
(I will be away for the weekend but I can reply on Monday)
^ permalink raw reply
* [PATCH v3] bpf: fix uapi bpf_prog_info fields alignment
From: Baruch Siach @ 2019-06-28 4:08 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Martin KaFai Lau, Song Liu, Yonghong Song, netdev, bpf,
Dmitry V . Levin, Arnd Bergmann, linux-arch, Baruch Siach,
Jiri Olsa, Geert Uytterhoeven, Linus Torvalds
Merge commit 1c8c5a9d38f60 ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next") undid the
fix from commit 36f9814a494 ("bpf: fix uapi hole for 32 bit compat
applications") by taking the gpl_compatible 1-bit field definition from
commit b85fab0e67b162 ("bpf: Add gpl_compatible flag to struct
bpf_prog_info") as is. That breaks architectures with 16-bit alignment
like m68k. Add 31-bit pad after gpl_compatible to restore alignment of
following fields.
Thanks to Dmitry V. Levin his analysis of this bug history.
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v3:
Use alignment pad as Alexei Starovoitov suggested
v2:
Use anonymous union with pad to make it less likely to break again in
the future.
---
include/uapi/linux/bpf.h | 1 +
tools/include/uapi/linux/bpf.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index a8b823c30b43..29a5bc3d5c66 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -3143,6 +3143,7 @@ struct bpf_prog_info {
char name[BPF_OBJ_NAME_LEN];
__u32 ifindex;
__u32 gpl_compatible:1;
+ __u32 :31; /* alignment pad */
__u64 netns_dev;
__u64 netns_ino;
__u32 nr_jited_ksyms;
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index a8b823c30b43..29a5bc3d5c66 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -3143,6 +3143,7 @@ struct bpf_prog_info {
char name[BPF_OBJ_NAME_LEN];
__u32 ifindex;
__u32 gpl_compatible:1;
+ __u32 :31; /* alignment pad */
__u64 netns_dev;
__u64 netns_ino;
__u32 nr_jited_ksyms;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net v2] vxlan: do not destroy fdb if register_netdevice() is failed
From: Taehee Yoo @ 2019-06-28 3:51 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: David Miller, netdev, Petr Machata
In-Reply-To: <CAJieiUjuRFgxC+YCNUfQFQa-FXjAmfMnTwLw-SOithEQt5QQyw@mail.gmail.com>
On Fri, 28 Jun 2019 at 03:33, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>
> On Thu, Jun 27, 2019 at 7:50 AM Taehee Yoo <ap420073@gmail.com> wrote:
> >
> > __vxlan_dev_create() destroys FDB using specific pointer which indicates
> > a fdb when error occurs.
> > But that pointer should not be used when register_netdevice() fails because
> > register_netdevice() internally destroys fdb when error occurs.
> >
> > This patch makes vxlan_fdb_create() to do not link fdb entry to vxlan dev
> > internally.
> > Instead, a new function vxlan_fdb_link() is added to link fdb to vxlan dev.
> >
> > vxlan_fdb_link() is called after calling register_netdevice().
> > This routine can avoid situation that ->ndo_uninit() destroys fdb entry
> > in error path of register_netdevice().
> > Hence, error path of __vxlan_dev_create() routine can have an opportunity
> > to destroy default fdb entry by hand.
> >
> > Test command
> > ip link add bonding_masters type vxlan id 0 group 239.1.1.1 \
> > dev enp0s9 dstport 4789
> >
> > Splat looks like:
> > [ 213.392816] kasan: GPF could be caused by NULL-ptr deref or user memory access
> > [ 213.401257] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
> > [ 213.402178] CPU: 0 PID: 1414 Comm: ip Not tainted 5.2.0-rc5+ #256
> > [ 213.402178] RIP: 0010:vxlan_fdb_destroy+0x120/0x220 [vxlan]
> > [ 213.402178] Code: df 48 8b 2b 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 06 01 00 00 4c 8b 63 08 48 b8 00 00 00 00 00 fc d
> > [ 213.402178] RSP: 0018:ffff88810cb9f0a0 EFLAGS: 00010202
> > [ 213.402178] RAX: dffffc0000000000 RBX: ffff888101d4a8c8 RCX: 0000000000000000
> > [ 213.402178] RDX: 1bd5a00000000040 RSI: ffff888101d4a8c8 RDI: ffff888101d4a8d0
> > [ 213.402178] RBP: 0000000000000000 R08: fffffbfff22b72d9 R09: 0000000000000000
> > [ 213.402178] R10: 00000000ffffffef R11: 0000000000000000 R12: dead000000000200
> > [ 213.402178] R13: ffff88810cb9f1f8 R14: ffff88810efccda0 R15: ffff88810efccda0
> > [ 213.402178] FS: 00007f7f6621a0c0(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
> > [ 213.402178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 213.402178] CR2: 000055746f0807d0 CR3: 00000001123e0000 CR4: 00000000001006f0
> > [ 213.402178] Call Trace:
> > [ 213.402178] __vxlan_dev_create+0x3a9/0x7d0 [vxlan]
> > [ 213.402178] ? vxlan_changelink+0x740/0x740 [vxlan]
> > [ 213.402178] ? rcu_read_unlock+0x60/0x60 [vxlan]
> > [ 213.402178] ? __kasan_kmalloc.constprop.3+0xa0/0xd0
> > [ 213.402178] vxlan_newlink+0x8d/0xc0 [vxlan]
> > [ 213.402178] ? __vxlan_dev_create+0x7d0/0x7d0 [vxlan]
> > [ 213.554119] ? __netlink_ns_capable+0xc3/0xf0
> > [ 213.554119] __rtnl_newlink+0xb75/0x1180
> > [ 213.554119] ? rtnl_link_unregister+0x230/0x230
> > [ ... ]
> >
> > Fixes: 0241b836732f ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
> > Suggested-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> > Signed-off-by: Taehee Yoo <ap420073@gmail.com>
> > ---
> >
> > v1 -> v2 :
> > - Add a new function vxlan_fdb_link().
> > - Fix fdb entry leak.
> > - Update description.
> >
>
> thanks for v2!. a few comments inline below ...
>
Thank you for review!
> > drivers/net/vxlan.c | 27 +++++++++++++++++++--------
> > 1 file changed, 19 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> > index 083f3f0bf37f..4066346d6f41 100644
> > --- a/drivers/net/vxlan.c
> > +++ b/drivers/net/vxlan.c
> > @@ -804,6 +804,14 @@ static struct vxlan_fdb *vxlan_fdb_alloc(struct vxlan_dev *vxlan,
> > return f;
> > }
> >
> > +static void vxlan_fdb_link(struct vxlan_dev *vxlan, const u8 *mac,
> > + __be32 src_vni, struct vxlan_fdb *f)
>
> I would prefer vxlan_fdb_insert or something along those lines.
>
> > +{
> > + ++vxlan->addrcnt;
> > + hlist_add_head_rcu(&f->hlist,
> > + vxlan_fdb_head(vxlan, mac, src_vni));
> > +}
> > +
> > static int vxlan_fdb_create(struct vxlan_dev *vxlan,
> > const u8 *mac, union vxlan_addr *ip,
> > __u16 state, __be16 port, __be32 src_vni,
> > @@ -829,10 +837,6 @@ static int vxlan_fdb_create(struct vxlan_dev *vxlan,
> > return rc;
> > }
> >
> > - ++vxlan->addrcnt;
> > - hlist_add_head_rcu(&f->hlist,
> > - vxlan_fdb_head(vxlan, mac, src_vni));
> > -
> > *fdb = f;
> >
> > return 0;
> > @@ -977,6 +981,7 @@ static int vxlan_fdb_update_create(struct vxlan_dev *vxlan,
> > if (rc < 0)
> > return rc;
> >
> > + vxlan_fdb_link(vxlan, mac, src_vni, f);
> > rc = vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f), RTM_NEWNEIGH,
> > swdev_notify, extack);
> > if (rc)
> > @@ -3571,12 +3576,17 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
> > if (err)
> > goto errout;
> >
> > - /* notify default fdb entry */
> > if (f) {
> > + vxlan_fdb_link(vxlan, all_zeros_mac,
> > + vxlan->default_dst.remote_vni, f);
> > +
> > + /* notify default fdb entry */
> > err = vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f),
> > RTM_NEWNEIGH, true, extack);
> > - if (err)
> > - goto errout;
> > + if (err) {
> > + vxlan_fdb_destroy(vxlan, f, false, false);
> > + goto unregister;
> > + }
> > }
> >
> > list_add(&vxlan->next, &vn->vxlan_list);
> > @@ -3588,7 +3598,8 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
> > * destroy the entry by hand here.
> > */
> > if (f)
> > - vxlan_fdb_destroy(vxlan, f, false, false);
> > + call_rcu(&f->rcu, vxlan_fdb_free);
>
> f is local to this function and not inserted at this point, so maybe
> we dont need to call_rcu here ?
>
I totally agree with your comments.
So, I will send a new patch.
Thank you!
> > +unregister:
> > if (unregister)
> > unregister_netdevice(dev);
> > return err;
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [PATCH 2/3 nf-next] netfilter:nf_flow_table: Support bridge type flow offload
From: wenxu @ 2019-06-28 3:37 UTC (permalink / raw)
To: Pablo Neira Ayuso, Florian Westphal; +Cc: netfilter-devel, netdev
In-Reply-To: <20190627125839.t56fnptdeqixt7wd@salvia>
On 6/27/2019 8:58 PM, Pablo Neira Ayuso wrote:
> On Thu, Jun 27, 2019 at 02:22:36PM +0800, wenxu wrote:
>> On 6/27/2019 3:19 AM, Florian Westphal wrote:
>>> Florian Westphal <fw@strlen.de> wrote:
> [...]
>>>> Whats the idea with this patch?
>>>>
>>>> Do you see a performance improvement when bypassing bridge layer? If so,
>>>> how much?
>>>>
>>>> I just wonder if its really cheaper than not using bridge conntrack in
>>>> the first place :-)
>> This patch is based on the conntrack function in bridge. It will
>> bypass the fdb lookup and conntrack lookup to get the performance
>> improvement. The more important things for hardware offload in the
>> future with nf_tables add hardware offload support
> Florian would like to see numbers / benchmark.
I just did a simple performace test with following test.
p netns add ns21
ip netns add ns22
ip l add dev veth21 type veth peer name eth0 netns ns21
ip l add dev veth22 type veth peer name eth0 netns ns22
ifconfig veth21 up
ifconfig veth22 up
ip netns exec ns21 ip a a dev eth0 10.0.0.7/24
ip netns exec ns22 ip a a dev eth0 10.0.0.8/24
ip netns exec ns21 ifconfig eth0 up
ip netns exec ns22 ifconfig eth0 up
ip l add dev br0 type bridge vlan_filtering 1
brctl addif br0 veth21
brctl addif br0 veth22
ifconfig br0 up
bridge vlan add dev veth21 vid 200 pvid untagged
bridge vlan add dev veth22 vid 200 pvid untagged
nft add table bridge firewall
nft add chain bridge firewall zones { type filter hook prerouting priority - 300 \; }
nft add rule bridge firewall zones counter ct zone set iif map { "veth21" : 2, "veth22" : 2 }
nft add chain bridge firewall rule-200-ingress
nft add rule bridge firewall rule-200-ingress ct zone 2 ct state established,related counter accept
nft add rule bridge firewall rule-200-ingress ct zone 2 ct state invalid counter drop
nft add rule bridge firewall rule-200-ingress ct zone 2 tcp dport 23 ct state new counter accept
nft add rule bridge firewall rule-200-ingress counter drop
nft add chain bridge firewall rule-200-egress
nft add rule bridge firewall rule-200-egress ct zone 2 ct state established,related counter accept
nft add rule bridge firewall rule-200-egress ct zone 2 ct state invalid counter drop
nft add rule bridge firewall rule-200-egress ct zone 2 tcp dport 23 ct state new counter drop
nft add rule bridge firewall rule-200-egress counter accept
nft add chain bridge firewall rules-all { type filter hook prerouting priority - 150 \; }
nft add rule bridge firewall rules-all counter meta protocol ip iif vmap { "veth22" : jump rule-200-ingress, "veth21" : jump rule-200-egress }
netns21 communication with ns22
ns21 iperf to 10.0.0.8 with dport 22 in ns22
first time with OFFLOAD enable
nft add flowtable bridge firewall fb2 { hook ingress priority 0 \; devices = { veth21, veth22 } \; }
nft add chain bridge firewall ftb-all {type filter hook forward priority 0 \; policy accept \; }
nft add rule bridge firewall ftb-all counter ct zone 2 ip protocol tcp flow offload @fb2
# iperf -c 10.0.0.8 -p 22 -t 60 -i2
------------------------------------------------------------
Client connecting to 10.0.0.8, TCP port 22
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.7 port 60014 connected with 10.0.0.8 port 22
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 10.8 GBytes 46.5 Gbits/sec
[ 3] 2.0- 4.0 sec 10.9 GBytes 46.7 Gbits/sec
[ 3] 4.0- 6.0 sec 10.9 GBytes 46.8 Gbits/sec
[ 3] 6.0- 8.0 sec 11.0 GBytes 47.2 Gbits/sec
[ 3] 8.0-10.0 sec 11.0 GBytes 47.1 Gbits/sec
[ 3] 10.0-12.0 sec 11.0 GBytes 47.1 Gbits/sec
[ 3] 12.0-14.0 sec 11.7 GBytes 50.4 Gbits/sec
[ 3] 14.0-16.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 16.0-18.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 18.0-20.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 20.0-22.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 22.0-24.0 sec 12.0 GBytes 51.4 Gbits/sec
[ 3] 24.0-26.0 sec 12.0 GBytes 51.3 Gbits/sec
[ 3] 26.0-28.0 sec 12.0 GBytes 51.7 Gbits/sec
[ 3] 28.0-30.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 30.0-32.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 32.0-34.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 34.0-36.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 36.0-38.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 38.0-40.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 40.0-42.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 42.0-44.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 44.0-46.0 sec 12.0 GBytes 51.4 Gbits/sec
[ 3] 46.0-48.0 sec 12.0 GBytes 51.4 Gbits/sec
[ 3] 48.0-50.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 50.0-52.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 52.0-54.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 54.0-56.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 56.0-58.0 sec 11.9 GBytes 51.2 Gbits/sec
[ 3] 58.0-60.0 sec 11.8 GBytes 50.7 Gbits/sec
[ 3] 0.0-60.0 sec 353 GBytes 50.5 Gbits/sec
The second time on any offload:
# iperf -c 10.0.0.8 -p 22 -t 60 -i2
------------------------------------------------------------
Client connecting to 10.0.0.8, TCP port 22
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.7 port 60536 connected with 10.0.0.8 port 22
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 8.88 GBytes 38.1 Gbits/sec
[ 3] 2.0- 4.0 sec 9.02 GBytes 38.7 Gbits/sec
[ 3] 4.0- 6.0 sec 9.02 GBytes 38.8 Gbits/sec
[ 3] 6.0- 8.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 8.0-10.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 10.0-12.0 sec 9.04 GBytes 38.8 Gbits/sec
[ 3] 12.0-14.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 14.0-16.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 16.0-18.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 18.0-20.0 sec 9.07 GBytes 39.0 Gbits/sec
[ 3] 20.0-22.0 sec 9.07 GBytes 38.9 Gbits/sec
[ 3] 22.0-24.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 24.0-26.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 26.0-28.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 28.0-30.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 30.0-32.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 32.0-34.0 sec 9.07 GBytes 38.9 Gbits/sec
[ 3] 34.0-36.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 36.0-38.0 sec 9.03 GBytes 38.8 Gbits/sec
[ 3] 38.0-40.0 sec 9.03 GBytes 38.8 Gbits/sec
[ 3] 40.0-42.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 42.0-44.0 sec 9.03 GBytes 38.8 Gbits/sec
[ 3] 44.0-46.0 sec 9.04 GBytes 38.8 Gbits/sec
[ 3] 46.0-48.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 48.0-50.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 50.0-52.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 52.0-54.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 54.0-56.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 56.0-58.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 58.0-60.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 0.0-60.0 sec 271 GBytes 38.8 Gbits/sec
>
^ permalink raw reply
* RE: [PATCH v3] e1000e: Make watchdog use delayed work
From: Brown, Aaron F @ 2019-06-28 3:21 UTC (permalink / raw)
To: Detlev Casanova, Kirsher, Jeffrey T, David S. Miller,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190623031437.19716-1-detlev.casanova@gmail.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Detlev Casanova
> Sent: Saturday, June 22, 2019 8:15 PM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; David S. Miller
> <davem@davemloft.net>; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: Detlev Casanova <detlev.casanova@gmail.com>
> Subject: [PATCH v3] e1000e: Make watchdog use delayed work
>
> Use delayed work instead of timers to run the watchdog of the e1000e
> driver.
>
> Simplify the code with one less middle function.
>
> Signed-off-by: Detlev Casanova <detlev.casanova@gmail.com>
> ---
> drivers/net/ethernet/intel/e1000e/e1000.h | 5 +-
> drivers/net/ethernet/intel/e1000e/netdev.c | 54 ++++++++++++----------
> 2 files changed, 32 insertions(+), 27 deletions(-)
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* RE: [PATCH net-next v6 1/8] igb: clear out skb->tstamp after reading the txtime
From: Brown, Aaron F @ 2019-06-28 3:01 UTC (permalink / raw)
To: Patel, Vedang, netdev@vger.kernel.org
Cc: Kirsher, Jeffrey T, davem@davemloft.net, jhs@mojatatu.com,
xiyou.wangcong@gmail.com, jiri@resnulli.us,
intel-wired-lan@lists.osuosl.org, Gomes, Vinicius, l@dorileo.org,
jakub.kicinski@netronome.com, m-karicheri2@ti.com,
sergei.shtylyov@cogentembedded.com, eric.dumazet@gmail.com
In-Reply-To: <1561500439-30276-2-git-send-email-vedang.patel@intel.com>
> From: Patel, Vedang
> Sent: Tuesday, June 25, 2019 3:07 PM
> To: netdev@vger.kernel.org
> Cc: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; davem@davemloft.net;
> jhs@mojatatu.com; xiyou.wangcong@gmail.com; jiri@resnulli.us; intel-wired-
> lan@lists.osuosl.org; Gomes, Vinicius <vinicius.gomes@intel.com>;
> l@dorileo.org; jakub.kicinski@netronome.com; m-karicheri2@ti.com;
> sergei.shtylyov@cogentembedded.com; eric.dumazet@gmail.com; Brown,
> Aaron F <aaron.f.brown@intel.com>; Patel, Vedang <vedang.patel@intel.com>
> Subject: [PATCH net-next v6 1/8] igb: clear out skb->tstamp after reading the
> txtime
>
> If a packet which is utilizing the launchtime feature (via SO_TXTIME socket
> option) also requests the hardware transmit timestamp, the hardware
> timestamp is not delivered to the userspace. This is because the value in
> skb->tstamp is mistaken as the software timestamp.
>
> Applications, like ptp4l, request a hardware timestamp by setting the
> SOF_TIMESTAMPING_TX_HARDWARE socket option. Whenever a new
> timestamp is
> detected by the driver (this work is done in igb_ptp_tx_work() which calls
> igb_ptp_tx_hwtstamps() in igb_ptp.c[1]), it will queue the timestamp in the
> ERR_QUEUE for the userspace to read. When the userspace is ready, it will
> issue a recvmsg() call to collect this timestamp. The problem is in this
> recvmsg() call. If the skb->tstamp is not cleared out, it will be
> interpreted as a software timestamp and the hardware tx timestamp will not
> be successfully sent to the userspace. Look at skb_is_swtx_tstamp() and the
> callee function __sock_recv_timestamp() in net/socket.c for more details.
>
> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* [PATCH v2 15/27] net: use zeroing allocator rather than allocator followed by memset zero
From: Fuqian Huang @ 2019-06-28 2:48 UTC (permalink / raw)
Cc: Fuqian Huang, David S. Miller, Derek Chickles, Satanand Burla,
Felix Manlunas, Tariq Toukan, netdev, linux-kernel, linux-rdma
Replace allocator followed by memset with 0 with zeroing allocator.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/eql.c | 3 +--
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c | 4 +---
drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c | 4 +---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 +--
4 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/eql.c b/drivers/net/eql.c
index 74263f8efe1a..2f101a6036e6 100644
--- a/drivers/net/eql.c
+++ b/drivers/net/eql.c
@@ -419,14 +419,13 @@ static int eql_enslave(struct net_device *master_dev, slaving_request_t __user *
if ((master_dev->flags & IFF_UP) == IFF_UP) {
/* slave is not a master & not already a slave: */
if (!eql_is_master(slave_dev) && !eql_is_slave(slave_dev)) {
- slave_t *s = kmalloc(sizeof(*s), GFP_KERNEL);
+ slave_t *s = kzalloc(sizeof(*s), GFP_KERNEL);
equalizer_t *eql = netdev_priv(master_dev);
int ret;
if (!s)
return -ENOMEM;
- memset(s, 0, sizeof(*s));
s->dev = slave_dev;
s->priority = srq.priority;
s->priority_bps = srq.priority;
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
index 43d11c38b38a..cf3835da32c8 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
@@ -719,12 +719,10 @@ static int cn23xx_setup_pf_mbox(struct octeon_device *oct)
for (i = 0; i < oct->sriov_info.max_vfs; i++) {
q_no = i * oct->sriov_info.rings_per_vf;
- mbox = vmalloc(sizeof(*mbox));
+ mbox = vzalloc(sizeof(*mbox));
if (!mbox)
goto free_mbox;
- memset(mbox, 0, sizeof(struct octeon_mbox));
-
spin_lock_init(&mbox->lock);
mbox->oct_dev = oct;
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
index fda49404968c..b3bd2767d3dd 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
@@ -279,12 +279,10 @@ static int cn23xx_setup_vf_mbox(struct octeon_device *oct)
{
struct octeon_mbox *mbox = NULL;
- mbox = vmalloc(sizeof(*mbox));
+ mbox = vzalloc(sizeof(*mbox));
if (!mbox)
return 1;
- memset(mbox, 0, sizeof(struct octeon_mbox));
-
spin_lock_init(&mbox->lock);
mbox->oct_dev = oct;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 6c01314e87b0..f1dff5c47676 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1062,7 +1062,7 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
struct mlx4_qp_context *context;
int err = 0;
- context = kmalloc(sizeof(*context), GFP_KERNEL);
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
if (!context)
return -ENOMEM;
@@ -1073,7 +1073,6 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
}
qp->event = mlx4_en_sqp_event;
- memset(context, 0, sizeof(*context));
mlx4_en_fill_qp_context(priv, ring->actual_size, ring->stride, 0, 0,
qpn, ring->cqn, -1, context);
context->db_rec_addr = cpu_to_be64(ring->wqres.db.dma);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 0/5] nfp: extend flower capabilities for GRE tunnel offload
From: David Miller @ 2019-06-28 2:47 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20190627231243.8323-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 27 Jun 2019 16:12:38 -0700
> Pieter says:
>
> This set extends the flower match and action components to offload
> GRE decapsulation with classification and encapsulation actions. The
> first 3 patches are refactor and cleanup patches for improving
> readability and reusability. Patch 4 and 5 implement GRE decap and
> encap functionality respectively.
Series applied.
^ permalink raw reply
* kernel BUG at net/rxrpc/local_object.c:LINE!
From: syzbot @ 2019-06-28 2:47 UTC (permalink / raw)
To: davem, dhowells, linux-afs, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14fabe45a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=e7c31a94f66cc0aa
dashboard link: https://syzkaller.appspot.com/bug?extid=1e0edc4b8b7494c28450
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13e2738da00000
The bug was bisected to:
commit 46894a13599a977ac35411b536fb3e0b2feefa95
Author: David Howells <dhowells@redhat.com>
Date: Thu Oct 4 08:32:28 2018 +0000
rxrpc: Use IPv4 addresses throught the IPv6
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=152fabe3a00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=172fabe3a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=132fabe3a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1e0edc4b8b7494c28450@syzkaller.appspotmail.com
Fixes: 46894a13599a ("rxrpc: Use IPv4 addresses throught the IPv6")
rxrpc: Assertion failed
------------[ cut here ]------------
kernel BUG at net/rxrpc/local_object.c:468!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.2.0-rc6+ #60
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:rxrpc_local_rcu net/rxrpc/local_object.c:468 [inline]
RIP: 0010:rxrpc_local_rcu.cold+0x11/0x13 net/rxrpc/local_object.c:462
Code: 83 eb 20 e9 74 ff ff ff e8 58 aa 2d fb eb cc 4c 89 ef e8 6e aa 2d fb
eb e2 e8 d7 fd f4 fa 48 c7 c7 20 8c 15 88 e8 6f 03 df fa <0f> 0b e8 c4 fd
f4 fa 48 c7 c7 20 8c 15 88 e8 5c 03 df fa 0f 0b e8
RSP: 0018:ffff8880a9917c98 EFLAGS: 00010286
RAX: 0000000000000017 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815ad926 RDI: ffffed1015322f85
RBP: ffff8880a9917ca8 R08: 0000000000000017 R09: ffffed1015d260a1
R10: ffffed1015d260a0 R11: ffff8880ae930507 R12: ffff888099033b40
R13: ffff888099033b40 R14: ffffffff867b8f10 R15: ffff8880a9917d28
FS: 0000000000000000(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f380ebda000 CR3: 000000007ad50000 CR4: 00000000001406e0
Call Trace:
__rcu_reclaim kernel/rcu/rcu.h:222 [inline]
rcu_do_batch kernel/rcu/tree.c:2092 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2310 [inline]
rcu_core+0xba5/0x1500 kernel/rcu/tree.c:2291
__do_softirq+0x25c/0x94c kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:603 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:595
smpboot_thread_fn+0x6a3/0xa30 kernel/smpboot.c:165
kthread+0x354/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace 0e784d6285151217 ]---
RIP: 0010:rxrpc_local_rcu net/rxrpc/local_object.c:468 [inline]
RIP: 0010:rxrpc_local_rcu.cold+0x11/0x13 net/rxrpc/local_object.c:462
Code: 83 eb 20 e9 74 ff ff ff e8 58 aa 2d fb eb cc 4c 89 ef e8 6e aa 2d fb
eb e2 e8 d7 fd f4 fa 48 c7 c7 20 8c 15 88 e8 6f 03 df fa <0f> 0b e8 c4 fd
f4 fa 48 c7 c7 20 8c 15 88 e8 5c 03 df fa 0f 0b e8
RSP: 0018:ffff8880a9917c98 EFLAGS: 00010286
RAX: 0000000000000017 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815ad926 RDI: ffffed1015322f85
RBP: ffff8880a9917ca8 R08: 0000000000000017 R09: ffffed1015d260a1
R10: ffffed1015d260a0 R11: ffff8880ae930507 R12: ffff888099033b40
R13: ffff888099033b40 R14: ffffffff867b8f10 R15: ffff8880a9917d28
FS: 0000000000000000(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f380ebda000 CR3: 000000007ad50000 CR4: 00000000001406e0
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH v2 03/27] atm: idt77252: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-28 2:46 UTC (permalink / raw)
Cc: Fuqian Huang, Chas Williams, linux-atm-general, netdev,
linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/atm/idt77252.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index 43a14579e80e..df51680e8931 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -1379,7 +1379,6 @@ init_tsq(struct idt77252_dev *card)
printk("%s: can't allocate TSQ.\n", card->name);
return -1;
}
- memset(card->tsq.base, 0, TSQSIZE);
card->tsq.last = card->tsq.base + TSQ_NUM_ENTRIES - 1;
card->tsq.next = card->tsq.last;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 2/5] net: dsa: microchip: Replace ksz9477_wait_vlan_ctrl_ready polling with regmap
From: Florian Fainelli @ 2019-06-28 2:44 UTC (permalink / raw)
To: Marek Vasut, netdev; +Cc: Andrew Lunn, Tristram Ha, Woojung Huh
In-Reply-To: <20190627215556.23768-3-marex@denx.de>
On 6/27/2019 2:55 PM, Marek Vasut wrote:
> Regmap provides polling function to poll for bits in a register. This
> function is another reimplementation of polling for bit being clear in
> a register. Replace this with regmap polling function. Moreover, inline
> the function parameters, as the function is never called with any other
> parameter values than this one.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Tristram Ha <Tristram.Ha@microchip.com>
> Cc: Woojung Huh <Woojung.Huh@microchip.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 1/5] net: dsa: microchip: Replace ad-hoc polling with regmap
From: Florian Fainelli @ 2019-06-28 2:43 UTC (permalink / raw)
To: Marek Vasut, netdev; +Cc: Andrew Lunn, Tristram Ha, Woojung Huh
In-Reply-To: <20190627215556.23768-2-marex@denx.de>
On 6/27/2019 2:55 PM, Marek Vasut wrote:
> Regmap provides polling function to poll for bits in a register,
> use in instead of reimplementing it.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Tristram Ha <Tristram.Ha@microchip.com>
> Cc: Woojung Huh <Woojung.Huh@microchip.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH net-next] net/ipv6: Fix misuse of proc_dointvec "flowlabel_reflect"
From: Eiichi Tsukata @ 2019-06-28 2:37 UTC (permalink / raw)
To: davem, edumazet, kuznet, yoshfuji, netdev, linux-kernel; +Cc: Eiichi Tsukata
/proc/sys/net/ipv6/flowlabel_reflect assumes written value to be in the
range of 0 to 3. Use proc_dointvec_minmax instead of proc_dointvec.
Fixes: 323a53c41292 ("ipv6: tcp: enable flowlabel reflection in some RST packets")
Signed-off-by: Eiichi Tsukata <devel@etsukata.com>
---
net/ipv6/sysctl_net_ipv6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 6d86fac472e7..831573461e19 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -114,7 +114,7 @@ static struct ctl_table ipv6_table_template[] = {
.data = &init_net.ipv6.sysctl.flowlabel_reflect,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_dointvec_minmax,
.extra1 = &zero,
.extra2 = &three,
},
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 4/6 bfp-next] Simplify AF_XDP umem allocation path for Intel drivers.
From: Jonathan Lemon @ 2019-06-28 2:36 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, bjorn.topel, magnus.karlsson, saeedm, maximmi, brouer,
kernel-team
In-Reply-To: <20190627154206.5d458e94@cakuba.netronome.com>
On 27 Jun 2019, at 15:42, Jakub Kicinski wrote:
> On Thu, 27 Jun 2019 15:08:34 -0700, Jonathan Lemon wrote:
>> Now that the recycle stack is always used for the driver umem path, the
>> driver code path can be simplified.
>>
>> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
>
> I guess it's a question to Bjorn and Magnus whether they want Intel
> drivers to always go through the reuse queue..
I did pass this by them earlier.
> Could you be more explicit on the motivation? I'd call this patch set
> "make all drivers use reuse queue" rather than "clean up".
The motivation is to have packets which were received on a zero-copy
AF_XDP socket, and which returned a TX verdict from the bpf program,
queued directly on the TX ring (if they're in the same napi context).
When these TX packets are completed, they are placed back onto the
reuse queue, as there isn't really any other place to handle them.
It also addresses Maxim's concern about having buffers end up sitting
on the rq after a ring resize.
I was going to send the TX change out as part of this patch, but
figured it would be better split unto its own series.
> Also when you're changing code please make sure you CC the author.
Who did I miss?
--
Jonathan
^ permalink raw reply
* Re: [PATCH 2/6 bpf-next] Clean up xsk reuseq API
From: Jonathan Lemon @ 2019-06-28 2:31 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, bjorn.topel, magnus.karlsson, saeedm, maximmi, brouer,
kernel-team
In-Reply-To: <20190627153856.1f4d4709@cakuba.netronome.com>
On 27 Jun 2019, at 15:38, Jakub Kicinski wrote:
> On Thu, 27 Jun 2019 15:08:32 -0700, Jonathan Lemon wrote:
>> The reuseq is actually a recycle stack, only accessed from the kernel
>> side.
>> Also, the implementation details of the stack should belong to the
>> umem
>> object, and not exposed to the caller.
>>
>> Clean up and rename for consistency in preparation for the next
>> patch.
>>
>> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
>
> Prepare/swap is to cater to how drivers should be written - being able
> to allocate resources independently of those currently used. Allowing
> for changing ring sizes and counts on the fly. This patch makes it
> harder to write drivers in the way we are encouraging people to.
>
> IOW no, please don't do this.
The main reason I rewrote this was to provide the same type
of functionality as realloc() - no need to allocate/initialize a new
array if the old one would still end up being used. This would seem
to be a win for the typical case of having the interface go up/down.
Perhaps I should have named the function differently?
--
Jonathan
^ permalink raw reply
* RE: [EXT] [PATCH 73/87] ethernet: freescale: Remove memset after dma_alloc_coherent
From: Andy Duan @ 2019-06-28 2:26 UTC (permalink / raw)
To: Fuqian Huang
Cc: David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190627174641.6474-1-huangfq.daxian@gmail.com>
From: Fuqian Huang <huangfq.daxian@gmail.com> Sent: Friday, June 28, 2019 1:47 AM
> In commit af7ddd8a627c
> ("Merge tag 'dma-mapping-4.21' of
> git://git.infradead.org/users/hch/dma-mapping"),
> dma_alloc_coherent has already zeroed the memory.
> So memset is not needed.
>
> Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 38f10f7dcbc3..ec87b8b78d21 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -3143,8 +3143,6 @@ static int fec_enet_init(struct net_device *ndev)
> return -ENOMEM;
> }
>
> - memset(cbd_base, 0, bd_size);
> -
> /* Get the Ethernet address */
> fec_get_mac(ndev);
> /* make sure MAC we just acquired is programmed into the hw */
> --
> 2.11.0
^ permalink raw reply
* Re: [PATCH 0/5] net: dsa: microchip: Further regmap cleanups
From: David Miller @ 2019-06-28 2:25 UTC (permalink / raw)
To: marex; +Cc: netdev, andrew, f.fainelli, Tristram.Ha, Woojung.Huh
In-Reply-To: <20190627215556.23768-1-marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Thu, 27 Jun 2019 23:55:51 +0200
> This patchset cleans up KSZ9477 switch driver by replacing various
> ad-hoc polling implementations and register RMW with regmap functions.
>
> Each polling function is replaced separately to make it easier to review
> and possibly bisect, but maybe the patches can be squashed.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
Series applied, thanks.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2019-06-28 1:45 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Dmitry Bogdanov, Igor Russkikh
[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got conflicts in:
drivers/net/ethernet/aquantia/atlantic/aq_nic.c
drivers/net/ethernet/aquantia/atlantic/aq_nic.h
between commit:
48dd73d08d4d ("net: aquantia: fix vlans not working over bridged network")
from the net tree and commit:
d3ed7c5cf79b ("net: aquantia: adding fields and device features for vlan offload")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/aquantia/atlantic/aq_nic.c
index 41172fbebddd,746f85e6de13..000000000000
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@@ -126,7 -126,8 +126,9 @@@ void aq_nic_cfg_start(struct aq_nic_s *
cfg->link_speed_msk &= cfg->aq_hw_caps->link_speed_msk;
cfg->features = cfg->aq_hw_caps->hw_features;
+ cfg->is_vlan_force_promisc = true;
+ cfg->is_vlan_rx_strip = !!(cfg->features & NETIF_F_HW_VLAN_CTAG_RX);
+ cfg->is_vlan_tx_insert = !!(cfg->features & NETIF_F_HW_VLAN_CTAG_TX);
}
static int aq_nic_update_link_status(struct aq_nic_s *self)
diff --cc drivers/net/ethernet/aquantia/atlantic/aq_nic.h
index 0f22f5d5691b,26c72f298684..000000000000
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
@@@ -35,7 -35,8 +35,9 @@@ struct aq_nic_cfg_s
u32 flow_control;
u32 link_speed_msk;
u32 wol;
+ bool is_vlan_force_promisc;
+ u8 is_vlan_rx_strip;
+ u8 is_vlan_tx_insert;
u16 is_mc_list_enabled;
u16 mc_list_count;
bool is_autoneg;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] net/sched: flower: fix infinite loop in fl_walk()
From: Cong Wang @ 2019-06-28 1:24 UTC (permalink / raw)
To: Davide Caratti
Cc: Vlad Buslov, David S. Miller, Linux Kernel Network Developers,
Lucas Bates
In-Reply-To: <94260c8898834cfa8e5421933a2b5ea59680b970.camel@redhat.com>
On Thu, Jun 27, 2019 at 3:10 PM Davide Caratti <dcaratti@redhat.com> wrote:
>
> On Wed, 2019-06-26 at 14:15 -0700, Cong Wang wrote:
> > Hi, Davide
> >
> > On Tue, Jun 25, 2019 at 12:29 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > > It should handle this overflow case more gracefully, I hope.
> > >
> >
> > Please try this attached one and let me know if it works.
> > Hope I get it right this time.
> >
> > Thanks!
>
> hello Cong, and thanks a lot for the patch!
> I see it uses
>
> (tmp <= id)
>
> as the condition to detect the overflow, and at each iteration it does
>
> tmp = id, ++id
>
> so that 'tmp' contains the last IDR found in the tree and 'id' is the next
> tentative value to be searched for. When 'id' overflows, (tmp <= id)
> becomes false, and the 'for' loop exits.
Yes, thanks for testing it with tc actions.
> I tested it successfully with TC actions having the highest possible
> index: 'tc actions show' doesn't loop anymore. But with cls_flower (that
> uses idr_for_each_entry_continue_ul() ) I still see the infinite loop:
> even when idr_for_each_entry_continue_ul() is used, fl_get_next_filter()
> never returns NULL, because
>
> (tmp <= id) && (((entry) = idr_get_next_ul(idr, &(id))) != NULL)
>
> calls idr_get_next_ul(idr, &(id)) at least once. So, even if
> idr_for_each_entry_continue_ul() detected the overflow of 'id' after the
> first iteration, and bailouts the for loop, fl_get_next_filter()
> repeatedly returns a pointer to the idr slot with index equal to
> 0xffffffff. Because of that, the while() loop in fl_walk() keeps dumping
> the same rule.
Good catch, it is actually the arg->cookie++ which causes the trouble
here.
> In my original patch I found easier to check for the overflow of
> arg->cookie in fl_walk(), before the self-increment, so I was sure that
>
> arg->fn(tp, f, arg)
>
> was already called once when 'f' was the slot having the highest possible
> IDR. Now, I didn't check it, but I guess
>
> refcount_inc_not_zero(&f->refcnt))
>
> in fl_get_next_filter() is always true during my test, so the inner
> while() loop is not endless, even when the idr has a slot with id equal to
> ULONG_MAX. Probably, to stay on the safe side, cls_flower needs both tests
> to be in place, what do you think?
I think we can just fold the nested loops into one for cls_flower and remove
the arg->cookie++.
What's more, arg->cookie could overflow too,seems we have to switch back to
arg->skip. I am not sure, if this is really a problem we can fix it separately.
Thanks.
^ permalink raw reply
* Re: [PATCH v4 02/13] dt-bindings: net: Add a YAML schemas for the generic PHY options
From: Rob Herring @ 2019-06-28 1:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Frank Rowand, David S . Miller, Chen-Yu Tsai,
Maxime Coquelin, Alexandre Torgue, netdev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-stm32, Maxime Chevallier, Antoine Ténart,
Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <945e54f02cc36a543b4c0bfd960475147359f7ff.1561649505.git-series.maxime.ripard@bootlin.com>
On Thu, Jun 27, 2019 at 9:32 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> The networking PHYs have a number of available device tree properties that
> can be used in their device tree node. Add a YAML schemas for those.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> Documentation/devicetree/bindings/net/ethernet-phy.yaml | 179 +++++++++-
> Documentation/devicetree/bindings/net/phy.txt | 80 +----
> 2 files changed, 180 insertions(+), 79 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/ethernet-phy.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> new file mode 100644
> index 000000000000..81d2016d7232
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> @@ -0,0 +1,179 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/ethernet-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ethernet PHY Generic Binding
> +
> +maintainers:
> + - Andrew Lunn <andrew@lunn.ch>
> + - Florian Fainelli <f.fainelli@gmail.com>
> + - Heiner Kallweit <hkallweit1@gmail.com>
> +
> +# The dt-schema tools will generate a select statement first by using
> +# the compatible, and second by using the node name if any. In our
> +# case, the node name is the one we want to match on, while the
> +# compatible is optional.
> +select:
> + properties:
> + $nodename:
> + pattern: "^ethernet-phy(@[a-f0-9]+)?$"
> +
> + required:
> + - $nodename
> +
> +properties:
> + $nodename:
> + pattern: "^ethernet-phy(@[a-f0-9]+)?$"
> +
> + compatible:
> + oneOf:
> + - const: ethernet-phy-ieee802.3-c22
> + description: PHYs that implement IEEE802.3 clause 22
> + - const: ethernet-phy-ieee802.3-c45
> + description: PHYs that implement IEEE802.3 clause 45
> + - pattern: "^ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$"
> + description:
> + If the PHY reports an incorrect ID (or none at all) then the
> + compatible list may contain an entry with the correct PHY ID
> + in the above form.
> + The first group of digits is the 16 bit Phy Identifier 1
> + register, this is the chip vendor OUI bits 3:18. The
> + second group of digits is the Phy Identifier 2 register,
> + this is the chip vendor OUI bits 19:24, followed by 10
> + bits of a vendor specific ID.
> + - items:
> + - pattern: "^ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$"
> + - const: ethernet-phy-ieee802.3-c45
> +
> + reg:
> + maxItems: 1
> + minimum: 0
> + maximum: 31
> + description:
> + The ID number for the PHY.
Mixing array and scalar properties is something we shouldn't be doing,
so I dropped maxItems as that is implied. I have a meta-schema check
for this once a couple of occurrences are fixed in the tree.
Rob
^ permalink raw reply
* [PATCH v3 net-next] net: link_watch: prevent starvation when processing linkwatch wq
From: Yunsheng Lin @ 2019-06-28 1:13 UTC (permalink / raw)
To: davem
Cc: hkallweit1, gregkh, tglx, netdev, linux-kernel, pbonzini, rkrcmar,
kvm
When user has configured a large number of virtual netdev, such
as 4K vlans, the carrier on/off operation of the real netdev
will also cause it's virtual netdev's link state to be processed
in linkwatch. Currently, the processing is done in a work queue,
which may cause rtnl locking starvation problem and worker
starvation problem for other work queue, such as irqfd_inject wq.
This patch releases the cpu when link watch worker has processed
a fixed number of netdev' link watch event, and schedule the
work queue again when there is still link watch event remaining.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
V2: use cond_resched and rtnl_unlock after processing a fixed
number of events
V3: fall back to v1 and change commit log to reflect that.
---
---
net/core/link_watch.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/net/core/link_watch.c b/net/core/link_watch.c
index 04fdc95..f153e06 100644
--- a/net/core/link_watch.c
+++ b/net/core/link_watch.c
@@ -163,9 +163,16 @@ static void linkwatch_do_dev(struct net_device *dev)
static void __linkwatch_run_queue(int urgent_only)
{
+#define MAX_DO_DEV_PER_LOOP 100
+
+ int do_dev = MAX_DO_DEV_PER_LOOP;
struct net_device *dev;
LIST_HEAD(wrk);
+ /* Give urgent case more budget */
+ if (urgent_only)
+ do_dev += MAX_DO_DEV_PER_LOOP;
+
/*
* Limit the number of linkwatch events to one
* per second so that a runaway driver does not
@@ -184,7 +191,7 @@ static void __linkwatch_run_queue(int urgent_only)
spin_lock_irq(&lweventlist_lock);
list_splice_init(&lweventlist, &wrk);
- while (!list_empty(&wrk)) {
+ while (!list_empty(&wrk) && do_dev > 0) {
dev = list_first_entry(&wrk, struct net_device, link_watch_list);
list_del_init(&dev->link_watch_list);
@@ -195,9 +202,13 @@ static void __linkwatch_run_queue(int urgent_only)
}
spin_unlock_irq(&lweventlist_lock);
linkwatch_do_dev(dev);
+ do_dev--;
spin_lock_irq(&lweventlist_lock);
}
+ /* Add the remaining work back to lweventlist */
+ list_splice_init(&wrk, &lweventlist);
+
if (!list_empty(&lweventlist))
linkwatch_schedule_work(0);
spin_unlock_irq(&lweventlist_lock);
--
2.8.1
^ permalink raw reply related
* [PATCH bpf-next] selftests/bpf: fix -Wstrict-aliasing in test_sockopt_sk.c
From: Stanislav Fomichev @ 2019-06-28 1:12 UTC (permalink / raw)
To: netdev, bpf; +Cc: davem, ast, daniel, Stanislav Fomichev
Let's use union with u8[4] and u32 members for sockopt buffer,
that should fix any possible aliasing issues.
test_sockopt_sk.c: In function ‘getsetsockopt’:
test_sockopt_sk.c:115:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
if (*(__u32 *)buf != 0x55AA*2) {
^~
test_sockopt_sk.c:116:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
log_err("Unexpected getsockopt(SO_SNDBUF) 0x%x != 0x55AA*2",
^~~~~~~
Fixes: 8a027dc0d8f5 ("selftests/bpf: add sockopt test that exercises sk helpers")
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/testing/selftests/bpf/test_sockopt_sk.c | 51 +++++++++----------
1 file changed, 24 insertions(+), 27 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_sockopt_sk.c b/tools/testing/selftests/bpf/test_sockopt_sk.c
index 12e79ed075ce..036b652e5ca9 100644
--- a/tools/testing/selftests/bpf/test_sockopt_sk.c
+++ b/tools/testing/selftests/bpf/test_sockopt_sk.c
@@ -22,7 +22,10 @@
static int getsetsockopt(void)
{
int fd, err;
- char buf[4] = {};
+ union {
+ char u8[4];
+ __u32 u32;
+ } buf = {};
socklen_t optlen;
fd = socket(AF_INET, SOCK_STREAM, 0);
@@ -33,31 +36,31 @@ static int getsetsockopt(void)
/* IP_TOS - BPF bypass */
- buf[0] = 0x08;
- err = setsockopt(fd, SOL_IP, IP_TOS, buf, 1);
+ buf.u8[0] = 0x08;
+ err = setsockopt(fd, SOL_IP, IP_TOS, &buf, 1);
if (err) {
log_err("Failed to call setsockopt(IP_TOS)");
goto err;
}
- buf[0] = 0x00;
+ buf.u8[0] = 0x00;
optlen = 1;
- err = getsockopt(fd, SOL_IP, IP_TOS, buf, &optlen);
+ err = getsockopt(fd, SOL_IP, IP_TOS, &buf, &optlen);
if (err) {
log_err("Failed to call getsockopt(IP_TOS)");
goto err;
}
- if (buf[0] != 0x08) {
+ if (buf.u8[0] != 0x08) {
log_err("Unexpected getsockopt(IP_TOS) buf[0] 0x%02x != 0x08",
- buf[0]);
+ buf.u8[0]);
goto err;
}
/* IP_TTL - EPERM */
- buf[0] = 1;
- err = setsockopt(fd, SOL_IP, IP_TTL, buf, 1);
+ buf.u8[0] = 1;
+ err = setsockopt(fd, SOL_IP, IP_TTL, &buf, 1);
if (!err || errno != EPERM) {
log_err("Unexpected success from setsockopt(IP_TTL)");
goto err;
@@ -65,16 +68,16 @@ static int getsetsockopt(void)
/* SOL_CUSTOM - handled by BPF */
- buf[0] = 0x01;
- err = setsockopt(fd, SOL_CUSTOM, 0, buf, 1);
+ buf.u8[0] = 0x01;
+ err = setsockopt(fd, SOL_CUSTOM, 0, &buf, 1);
if (err) {
log_err("Failed to call setsockopt");
goto err;
}
- buf[0] = 0x00;
+ buf.u32 = 0x00;
optlen = 4;
- err = getsockopt(fd, SOL_CUSTOM, 0, buf, &optlen);
+ err = getsockopt(fd, SOL_CUSTOM, 0, &buf, &optlen);
if (err) {
log_err("Failed to call getsockopt");
goto err;
@@ -84,37 +87,31 @@ static int getsetsockopt(void)
log_err("Unexpected optlen %d != 1", optlen);
goto err;
}
- if (buf[0] != 0x01) {
- log_err("Unexpected buf[0] 0x%02x != 0x01", buf[0]);
+ if (buf.u8[0] != 0x01) {
+ log_err("Unexpected buf[0] 0x%02x != 0x01", buf.u8[0]);
goto err;
}
/* SO_SNDBUF is overwritten */
- buf[0] = 0x01;
- buf[1] = 0x01;
- buf[2] = 0x01;
- buf[3] = 0x01;
- err = setsockopt(fd, SOL_SOCKET, SO_SNDBUF, buf, 4);
+ buf.u32 = 0x01010101;
+ err = setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &buf, 4);
if (err) {
log_err("Failed to call setsockopt(SO_SNDBUF)");
goto err;
}
- buf[0] = 0x00;
- buf[1] = 0x00;
- buf[2] = 0x00;
- buf[3] = 0x00;
+ buf.u32 = 0x00;
optlen = 4;
- err = getsockopt(fd, SOL_SOCKET, SO_SNDBUF, buf, &optlen);
+ err = getsockopt(fd, SOL_SOCKET, SO_SNDBUF, &buf, &optlen);
if (err) {
log_err("Failed to call getsockopt(SO_SNDBUF)");
goto err;
}
- if (*(__u32 *)buf != 0x55AA*2) {
+ if (buf.u32 != 0x55AA*2) {
log_err("Unexpected getsockopt(SO_SNDBUF) 0x%x != 0x55AA*2",
- *(__u32 *)buf);
+ buf.u32);
goto err;
}
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
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