* Re: [PATCH net-next 1/3] net: rework SIOCGSTAMP ioctl handling
From: Arnd Bergmann @ 2018-08-31 10:31 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Networking, David Miller, linux-arch, y2038 Mailman List,
Eric Dumazet, Willem de Bruijn, Linux Kernel Mailing List,
linux-hams, Bluez mailing list, linux-can, dccp, linux-wpan,
linux-sctp, linux-x25
In-Reply-To: <CAF=yD-J7-GumUmonrZt7s44e3bsjY2DCD6ZpmhtCx6FOBV5BNA@mail.gmail.com>
On Thu, Aug 30, 2018 at 10:10 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Wed, Aug 29, 2018 at 9:05 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > The SIOCGSTAMP/SIOCGSTAMPNS ioctl commands are implemented by many
> > socket protocol handlers, and all of those end up calling the same
> > sock_get_timestamp()/sock_get_timestampns() helper functions, which
> > results in a lot of duplicate code.
> >
> > With the introduction of 64-bit time_t on 32-bit architectures, this
> > gets worse, as we then need four different ioctl commands in each
> > socket protocol implementation.
> >
> > To simplify that, let's add a new .gettstamp() operation in
> > struct proto_ops, and move ioctl implementation into the common
> > sock_ioctl()/compat_sock_ioctl_trans() functions that these all go
> > through.
> >
> > We can reuse the sock_get_timestamp() implementation, but generalize
> > it so it can deal with both native and compat mode, as well as
> > timeval and timespec structures.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> This also will simplify fixing a recently reported race condition with
> sock_get_timestamp [1]. That calls sock_enable_timestamp, which
> modifies sk->sk_flags, without taking the socket lock. Currently some
> callers of sock_get_timestamp hold the lock (ax25, netrom, qrtr), many
> don't. See also how this patch removes the lock_sock in the netrom
> case. Moving the call to sock_gettstamp outside the protocol handlers
> will allow taking the lock inside the function.
I suppose it would be best to always take that lock then, rather than
removing the lock as my patch does at the moment.
> If this is the only valid implementation of .gettstamp, the indirect
> call could be avoided in favor of a simple branch.
I thought about that as well, but I could not come up with a
good way to encode the difference between socket protocols
that allow timestamping and those that don't.
I think ideally we would just call sock_gettstamp() unconditonally
on every socket, and have that function decide whether timestamps
make sense or not. The part I did not understand is which ones
actually want the timestamps or not. Most protocols that
implement the ioctls also assign skb->tstamp, but there are some
protocols in which I could not see skb->tstamp ever being set,
and some that set it but don't seem to have the ioctls.
Looking at it again, it seems that sock_gettstamp() should
actually deal with this gracefully: it will return a -EINVAL
error condition if the timestamp remains at the
SK_DEFAULT_STAMP initial value, which is probably
just as appropriate (or better) as the current -ENOTTY
default, and if we are actually recording timestamps, we
might just as well report them.
> Acked-by: Willem de Bruijn <willemb@google.com>
Thanks,
Arnd
^ permalink raw reply
* Re: [PATCH net-next 2/2] netlink: ipv6 MLD join notifications
From: kbuild test robot @ 2018-08-31 5:35 UTC (permalink / raw)
To: Patrick Ruddy; +Cc: kbuild-all, netdev, roopa, jiri, stephen
In-Reply-To: <20180830093545.29465-3-pruddy@vyatta.att-mail.com>
[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]
Hi Patrick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Patrick-Ruddy/netlink-ipv4-IGMP-join-notifications/20180831-105548
config: i386-randconfig-s0-201834 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/ipv6/addrconf.c: In function 'inet6_dump_ifaddr':
>> net/ipv6/addrconf.c:5039:10: error: expected expression before '=' token
ret = = inet6_dump_addr(skb, cb, type, RTM_NEWADDR);
^
vim +5039 net/ipv6/addrconf.c
5031
5032 static int inet6_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
5033 {
5034 enum addr_type_t type;
5035 int ret;
5036
5037 type = cb->args[3];
5038 if (type == UNICAST_ADDR) {
> 5039 ret = = inet6_dump_addr(skb, cb, type, RTM_NEWADDR);
5040 if (ret > 0)
5041 goto done;
5042
5043 /* reset indices and move on to multicast*/
5044 cb->args[0] = 0;
5045 cb->args[1] = 0;
5046 cb->args[2] = 0;
5047 type = MULTICAST_ADDR;
5048 }
5049
5050 /* do the RTM_NEWADDR notifications for multicast type */
5051 ret = inet6_dump_addr(skb, cb, type, RTM_NEWADDR);
5052 done:
5053 cb->args[3] = type;
5054 return ret;
5055 }
5056
---
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: 28040 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array
From: Linus Walleij @ 2018-08-31 9:14 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg KH, kishon,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald, Jiri Slaby, Willy Tarreau,
Geert Uytterhoeven, linux-doc, linux-i2c
In-Reply-To: <20180829204900.19390-2-jmkrzyszt@gmail.com>
On Wed, Aug 29, 2018 at 10:48 PM Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:
So it's no secret that I strongly fancy this patch set.
What would be great at this point is to have some people test
that the drivers still work as expected, even better if they can do
some benchmarking.
> - values[PIN_DATA0 + i] = !!(val & BIT(i));
> - values[PIN_CTRL_RS] = rs;
> + value_bitmap[0] = val;
> + __assign_bit(PIN_CTRL_RS, value_bitmap, rs);
> n = 9;
> if (hd->pins[PIN_CTRL_RW]) {
> - values[PIN_CTRL_RW] = 0;
> + __clear_bit(PIN_CTRL_RW, value_bitmap);
This seems fine to me, but I understand the comment that the
code becomes harder to read.
I think part of it is those __assign_bit() and __clear_bit() with
the double-underscore of unclear meaning. The meaning is
"non atomic" IIRC, so maybe I should move forward
with my plan to send a sed script to Torvalds just renaming all
of those to something sane in the next merge window.
Like __assign_bit() -> assign_bit_nonatomic()
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next 1/2] netlink: ipv4 IGMP join notifications
From: kbuild test robot @ 2018-08-31 4:52 UTC (permalink / raw)
To: Patrick Ruddy; +Cc: kbuild-all, netdev, roopa, jiri, stephen
In-Reply-To: <20180830093545.29465-2-pruddy@vyatta.att-mail.com>
[-- Attachment #1: Type: text/plain, Size: 2741 bytes --]
Hi Patrick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Patrick-Ruddy/netlink-ipv4-IGMP-join-notifications/20180831-105548
config: i386-randconfig-a1-201834 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from net//bridge/br_multicast.c:16:0:
>> include/linux/igmp.h:134:16: warning: 'struct netlink_callback' declared inside parameter list
struct net_device *dev);
^
>> include/linux/igmp.h:134:16: warning: its scope is only this definition or declaration, which is probably not what you want
vim +134 include/linux/igmp.h
108
109 extern int ip_check_mc_rcu(struct in_device *dev, __be32 mc_addr, __be32 src_addr, u8 proto);
110 extern int igmp_rcv(struct sk_buff *);
111 extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
112 extern int ip_mc_join_group_ssm(struct sock *sk, struct ip_mreqn *imr,
113 unsigned int mode);
114 extern int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr);
115 extern void ip_mc_drop_socket(struct sock *sk);
116 extern int ip_mc_source(int add, int omode, struct sock *sk,
117 struct ip_mreq_source *mreqs, int ifindex);
118 extern int ip_mc_msfilter(struct sock *sk, struct ip_msfilter *msf,int ifindex);
119 extern int ip_mc_msfget(struct sock *sk, struct ip_msfilter *msf,
120 struct ip_msfilter __user *optval, int __user *optlen);
121 extern int ip_mc_gsfget(struct sock *sk, struct group_filter *gsf,
122 struct group_filter __user *optval, int __user *optlen);
123 extern int ip_mc_sf_allow(struct sock *sk, __be32 local, __be32 rmt,
124 int dif, int sdif);
125 extern void ip_mc_init_dev(struct in_device *);
126 extern void ip_mc_destroy_dev(struct in_device *);
127 extern void ip_mc_up(struct in_device *);
128 extern void ip_mc_down(struct in_device *);
129 extern void ip_mc_unmap(struct in_device *);
130 extern void ip_mc_remap(struct in_device *);
131 extern void ip_mc_dec_group(struct in_device *in_dev, __be32 addr);
132 extern void ip_mc_inc_group(struct in_device *in_dev, __be32 addr);
133 extern int ip_mc_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb,
> 134 struct net_device *dev);
135 int ip_mc_check_igmp(struct sk_buff *skb, struct sk_buff **skb_trimmed);
136
---
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: 34377 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v1 0/3] device property: Support MAC address in VPD
From: Srinivas Kandagatla @ 2018-08-31 8:43 UTC (permalink / raw)
To: Brian Norris, Rob Herring
Cc: Brian Norris, Florian Fainelli, Greg Kroah-Hartman,
Rafael J. Wysocki, Andrew Lunn, Dmitry Torokhov, Guenter Roeck,
netdev, devicetree, linux-kernel, Julius Werner, Stephen Boyd
In-Reply-To: <20180831012656.GB67271@ban.mtv.corp.google.com>
Sorry for the delay!! For some reason I missed this email thread totally!
On 31/08/18 02:26, Brian Norris wrote:
>> Seems to me that nvmem needs to be extended to allow providers to
>> retrieve and interpret data. Not everything is at some fixed offset and
>> size. Something like this is valid dts:
>>
>> nvmem = <&phandle> "a-string";
>>
There has been some discussion on extending nvmem support to MTD and
non-DT users in https://patchwork.kernel.org/cover/10562365/
One of the thing which we discussed in this thread is adding compatible
strings to cells mainly to
1> Differentiate between actual cells and partitions for MTD case.
2> Allow provider specific bindings for each cell, in VPD instance key
string & value length could be one them.
This means that we would endup adding xlate callback support to the
nvmem_config.
AFAIU, From consumer side old bindings should still work!
From non-dt or ACPI side these cells can be parsed by the provider
driver and add it to the nvmem_config.
Does this make sense? Or Did I miss anything obvious ?
>> But that's pretty uncommon (I can't think of a binding that actually
>> uses that). Perhaps the provider has an array of keys defined and the
>> consumer just provides the index.
> In the case of VPD, all keys are 0-terminated strings (there's also a
> length field, but the key is still 0-terminated), so that scheme could
> work. (I'm not sure an indexed provider is extremely relevant right now,
> although it probably could be supported if I expand the of_nvmem
> retrieval to support a generic of_xlate() override anyway.) The
> information represented is almost the same as in my proposal, except that:
> (a) now I have to give the VPD a phandle -- so far, I've avoided that,
> as it's just an auto-enumerated device underneath the
> /firmware/coreboot device (see drivers/firmware/google/vpd.c)
> (b) this is no longer directly useful to ACPI systems -- I'm not
> actually sure how (if at all) nvmem provider/consumer is supposed to
> work there
>
> But maybe this isn't really that useful to ACPI, and it's sufficient to
> just have fwnode_get_mac_address() call of_get_nvmem_mac_address() when
> we're using DT.
>
>> Or we could do '<key>-nvmem = <&phandle>', but parsing that is a bit
>> more complicated.
> That doesn't seem to have much advantage to me.
^ permalink raw reply
* [bpf PATCH v2] bpf: avoid misuse of psock when TCP_ULP_BPF collides with another ULP
From: John Fastabend @ 2018-08-31 4:25 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev
Currently we check sk_user_data is non NULL to determine if the sk
exists in a map. However, this is not sufficient to ensure the psock
or the ULP ops are not in use by another user, such as kcm or TLS. To
avoid this when adding a sock to a map also verify it is of the
correct ULP type. Additionally, when releasing a psock verify that
it is the TCP_ULP_BPF type before releasing the ULP. The error case
where we abort an update due to ULP collision can cause this error
path.
For example,
__sock_map_ctx_update_elem()
[...]
err = tcp_set_ulp_id(sock, TCP_ULP_BPF) <- collides with TLS
if (err) <- so err out here
goto out_free
[...]
out_free:
smap_release_sock() <- calling tcp_cleanup_ulp releases the
TLS ULP incorrectly.
Fixes: 2f857d04601a ("bpf: sockmap, remove STRPARSER map_flags and add multi-map support")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index ce63e58..488ef96 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1462,10 +1462,16 @@ static void smap_destroy_psock(struct rcu_head *rcu)
schedule_work(&psock->gc_work);
}
+static bool psock_is_smap_sk(struct sock *sk)
+{
+ return inet_csk(sk)->icsk_ulp_ops == &bpf_tcp_ulp_ops;
+}
+
static void smap_release_sock(struct smap_psock *psock, struct sock *sock)
{
if (refcount_dec_and_test(&psock->refcnt)) {
- tcp_cleanup_ulp(sock);
+ if (psock_is_smap_sk(sock))
+ tcp_cleanup_ulp(sock);
write_lock_bh(&sock->sk_callback_lock);
smap_stop_sock(psock, sock);
write_unlock_bh(&sock->sk_callback_lock);
@@ -1892,6 +1898,10 @@ static int __sock_map_ctx_update_elem(struct bpf_map *map,
* doesn't update user data.
*/
if (psock) {
+ if (!psock_is_smap_sk(sock)) {
+ err = -EBUSY;
+ goto out_progs;
+ }
if (READ_ONCE(psock->bpf_parse) && parse) {
err = -EBUSY;
goto out_progs;
^ permalink raw reply related
* Re: [PATCH net-next 1/2] netlink: ipv4 IGMP join notifications
From: kbuild test robot @ 2018-08-31 4:23 UTC (permalink / raw)
To: Patrick Ruddy; +Cc: kbuild-all, netdev, roopa, jiri, stephen
In-Reply-To: <20180830093545.29465-2-pruddy@vyatta.att-mail.com>
[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]
Hi Patrick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Patrick-Ruddy/netlink-ipv4-IGMP-join-notifications/20180831-105548
config: i386-randconfig-s0-201834 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from net//ipv4/udp.c:92:0:
>> include/linux/igmp.h:133:58: warning: 'struct netlink_callback' declared inside parameter list will not be visible outside of this definition or declaration
extern int ip_mc_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb,
^~~~~~~~~~~~~~~~
vim +133 include/linux/igmp.h
108
109 extern int ip_check_mc_rcu(struct in_device *dev, __be32 mc_addr, __be32 src_addr, u8 proto);
110 extern int igmp_rcv(struct sk_buff *);
111 extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
112 extern int ip_mc_join_group_ssm(struct sock *sk, struct ip_mreqn *imr,
113 unsigned int mode);
114 extern int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr);
115 extern void ip_mc_drop_socket(struct sock *sk);
116 extern int ip_mc_source(int add, int omode, struct sock *sk,
117 struct ip_mreq_source *mreqs, int ifindex);
118 extern int ip_mc_msfilter(struct sock *sk, struct ip_msfilter *msf,int ifindex);
119 extern int ip_mc_msfget(struct sock *sk, struct ip_msfilter *msf,
120 struct ip_msfilter __user *optval, int __user *optlen);
121 extern int ip_mc_gsfget(struct sock *sk, struct group_filter *gsf,
122 struct group_filter __user *optval, int __user *optlen);
123 extern int ip_mc_sf_allow(struct sock *sk, __be32 local, __be32 rmt,
124 int dif, int sdif);
125 extern void ip_mc_init_dev(struct in_device *);
126 extern void ip_mc_destroy_dev(struct in_device *);
127 extern void ip_mc_up(struct in_device *);
128 extern void ip_mc_down(struct in_device *);
129 extern void ip_mc_unmap(struct in_device *);
130 extern void ip_mc_remap(struct in_device *);
131 extern void ip_mc_dec_group(struct in_device *in_dev, __be32 addr);
132 extern void ip_mc_inc_group(struct in_device *in_dev, __be32 addr);
> 133 extern int ip_mc_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb,
134 struct net_device *dev);
135 int ip_mc_check_igmp(struct sk_buff *skb, struct sk_buff **skb_trimmed);
136
---
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: 28040 bytes --]
^ permalink raw reply
* Re: KASAN: use-after-free Read in vhost_work_queue
From: Stefan Hajnoczi @ 2018-08-31 8:15 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: syzbot, jasowang, kvm, linux-kernel, netdev, syzkaller-bugs,
virtualization, cavery
In-Reply-To: <20180828111055-mutt-send-email-mst@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 6881 bytes --]
On Tue, Aug 28, 2018 at 11:11:21AM -0400, Michael S. Tsirkin wrote:
> On Tue, Aug 28, 2018 at 07:44:03AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 33e17876ea4e Merge branch 'akpm' (patches from Andrew)
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12d8a20a400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=40e5d6b26b73cd5b
> > dashboard link: https://syzkaller.appspot.com/bug?extid=d5a0a170c5069658b141
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > userspace arch: i386
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+d5a0a170c5069658b141@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: use-after-free in vhost_work_queue+0xc3/0xe0
> > drivers/vhost/vhost.c:258
> > Read of size 8 at addr ffff880193862068 by task syz-executor7/22100
> >
> > CPU: 0 PID: 22100 Comm: syz-executor7 Not tainted 4.18.0+ #108
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> > print_address_description+0x6c/0x20b mm/kasan/report.c:256
> > kasan_report_error mm/kasan/report.c:354 [inline]
> > kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
> > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> > vhost_work_queue+0xc3/0xe0 drivers/vhost/vhost.c:258
> > vhost_transport_send_pkt+0x28a/0x380 drivers/vhost/vsock.c:227
> > virtio_transport_send_pkt_info+0x31d/0x460
> > net/vmw_vsock/virtio_transport_common.c:190
> > virtio_transport_shutdown+0x1b1/0x270
> > net/vmw_vsock/virtio_transport_common.c:604
> > vsock_send_shutdown net/vmw_vsock/af_vsock.c:451 [inline]
> > vsock_shutdown+0x229/0x290 net/vmw_vsock/af_vsock.c:849
> > __sys_shutdown+0x15c/0x2c0 net/socket.c:1964
> > __do_sys_shutdown net/socket.c:1972 [inline]
> > __se_sys_shutdown net/socket.c:1970 [inline]
> > __ia32_sys_shutdown+0x54/0x80 net/socket.c:1970
> > do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
> > do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
> > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> > RIP: 0023:0xf7fa4ca9
> > Code: 55 08 8b 88 64 cd ff ff 8b 98 68 cd ff ff 89 c8 85 d2 74 02 89 0a 5b
> > 5d c3 8b 04 24 c3 8b 1c 24 c3 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90
> > 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
> > RSP: 002b:00000000f5f7f0cc EFLAGS: 00000296 ORIG_RAX: 0000000000000175
> > RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> >
> > Allocated by task 22094:
> > save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> > set_track mm/kasan/kasan.c:460 [inline]
> > kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> > __do_kmalloc_node mm/slab.c:3682 [inline]
> > __kmalloc_node+0x47/0x70 mm/slab.c:3689
> > kmalloc_node include/linux/slab.h:555 [inline]
> > kvmalloc_node+0xb9/0xf0 mm/util.c:423
> > kvmalloc include/linux/mm.h:577 [inline]
> > vhost_vsock_dev_open+0xa2/0x5a0 drivers/vhost/vsock.c:511
> > misc_open+0x3ca/0x560 drivers/char/misc.c:141
> > chrdev_open+0x25a/0x770 fs/char_dev.c:417
> > do_dentry_open+0x49c/0x1140 fs/open.c:771
> > vfs_open+0xa0/0xd0 fs/open.c:880
> > do_last fs/namei.c:3418 [inline]
> > path_openat+0x12fb/0x5300 fs/namei.c:3534
> > do_filp_open+0x255/0x380 fs/namei.c:3564
> > do_sys_open+0x584/0x720 fs/open.c:1063
> > __do_compat_sys_openat fs/open.c:1109 [inline]
> > __se_compat_sys_openat fs/open.c:1107 [inline]
> > __ia32_compat_sys_openat+0x98/0xf0 fs/open.c:1107
> > do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
> > do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
> > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> >
> > Freed by task 22093:
> > save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> > set_track mm/kasan/kasan.c:460 [inline]
> > __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> > kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> > __cache_free mm/slab.c:3498 [inline]
> > kfree+0xd9/0x210 mm/slab.c:3813
> > kvfree+0x61/0x70 mm/util.c:449
> > vhost_vsock_free drivers/vhost/vsock.c:499 [inline]
> > vhost_vsock_dev_release+0x4fd/0x750 drivers/vhost/vsock.c:604
> > __fput+0x36e/0x8c0 fs/file_table.c:278
> > ____fput+0x15/0x20 fs/file_table.c:309
> > task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
> > tracehook_notify_resume include/linux/tracehook.h:193 [inline]
> > exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
> > prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> > syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> > do_syscall_32_irqs_on arch/x86/entry/common.c:341 [inline]
> > do_fast_syscall_32+0xcd5/0xfb2 arch/x86/entry/common.c:397
> > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> >
> > The buggy address belongs to the object at ffff880193861fc0
> > which belongs to the cache kmalloc-65536 of size 65536
> > The buggy address is located 168 bytes inside of
> > 65536-byte region [ffff880193861fc0, ffff880193871fc0)
> > The buggy address belongs to the page:
> > page:ffffea00064e1800 count:1 mapcount:0 mapping:ffff8801dac02500 index:0x0
> > compound_mapcount: 0
> > flags: 0x2fffc0000008100(slab|head)
> > raw: 02fffc0000008100 ffffea00064c7008 ffffea00064e5008 ffff8801dac02500
> > raw: 0000000000000000 ffff880193861fc0 0000000100000001 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff880193861f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff880193861f80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> > > ffff880193862000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ^
> > ffff880193862080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff880193862100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ==================================================================
>
> Seems like a duplicate of the bug Stefan's working on now.
I am currently away on leave and not working on fixes. Please contact
Cathy about vsock syzkaller bugs while I'm away.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH net-next v2 3/3] net: mvneta: reduce smp_processor_id() calling in mvneta_tx_done_gbe
From: Jisheng Zhang @ 2018-08-31 8:11 UTC (permalink / raw)
To: thomas.petazzoni, David S. Miller, Andrew Lunn, Gregory CLEMENT
Cc: netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20180831160810.2539ef4c@xhacker.debian>
In the loop of mvneta_tx_done_gbe(), we call the smp_processor_id()
each time, move the call out of the loop to optimize the code a bit.
Before the patch, the loop looks like(under arm64):
ldr x1, [x29,#120]
...
ldr w24, [x1,#36]
...
bl 0 <_raw_spin_lock>
str w24, [x27,#132]
...
After the patch, the loop looks like(under arm64):
...
bl 0 <_raw_spin_lock>
str w23, [x28,#132]
...
where w23 is loaded so be ready before the loop.
From another side, mvneta_tx_done_gbe() is called from mvneta_poll()
which is in non-preemptible context, so it's safe to call the
smp_processor_id() function once.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index bcd20ebb2ebd..fe3edb3c2bf4 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2507,12 +2507,13 @@ static void mvneta_tx_done_gbe(struct mvneta_port *pp, u32 cause_tx_done)
{
struct mvneta_tx_queue *txq;
struct netdev_queue *nq;
+ int cpu = smp_processor_id();
while (cause_tx_done) {
txq = mvneta_tx_done_policy(pp, cause_tx_done);
nq = netdev_get_tx_queue(pp->dev, txq->id);
- __netif_tx_lock(nq, smp_processor_id());
+ __netif_tx_lock(nq, cpu);
if (txq->count)
mvneta_txq_done(pp, txq);
--
2.18.0
^ permalink raw reply related
* Re: [PATCH bpf-next 2/3] xsk: get rid of useless struct xdp_umem_props
From: kbuild test robot @ 2018-08-31 4:03 UTC (permalink / raw)
To: Magnus Karlsson
Cc: kbuild-all, magnus.karlsson, bjorn.topel, ast, daniel, netdev
In-Reply-To: <1535637403-14549-3-git-send-email-magnus.karlsson@intel.com>
[-- Attachment #1: Type: text/plain, Size: 4229 bytes --]
Hi Magnus,
I love your patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Magnus-Karlsson/i40e-fix-possible-compiler-warning-in-xsk-TX-path/20180831-095442
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=ia64
Note: the linux-review/Magnus-Karlsson/i40e-fix-possible-compiler-warning-in-xsk-TX-path/20180831-095442 HEAD 9b1f94c22aa3118f7657ec5a5124135bab6eb50b builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/net//ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_reuse_rx_buffer_zc':
>> drivers/net//ethernet/intel/i40e/i40e_xsk.c:445:55: error: 'struct xdp_umem' has no member named 'props'
unsigned long mask = (unsigned long)rx_ring->xsk_umem->props.chunk_mask;
^~
drivers/net//ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_zca_free':
drivers/net//ethernet/intel/i40e/i40e_xsk.c:480:26: error: 'struct xdp_umem' has no member named 'props'
mask = rx_ring->xsk_umem->props.chunk_mask;
^~
vim +445 drivers/net//ethernet/intel/i40e/i40e_xsk.c
0a714186 Björn Töpel 2018-08-28 432
0a714186 Björn Töpel 2018-08-28 433 /**
0a714186 Björn Töpel 2018-08-28 434 * i40e_reuse_rx_buffer_zc - Recycle an Rx buffer
0a714186 Björn Töpel 2018-08-28 435 * @rx_ring: Rx ring
0a714186 Björn Töpel 2018-08-28 436 * @old_bi: The Rx buffer to recycle
0a714186 Björn Töpel 2018-08-28 437 *
0a714186 Björn Töpel 2018-08-28 438 * This function recycles a finished Rx buffer, and places it on the
0a714186 Björn Töpel 2018-08-28 439 * recycle queue (next_to_alloc).
0a714186 Björn Töpel 2018-08-28 440 **/
0a714186 Björn Töpel 2018-08-28 441 static void i40e_reuse_rx_buffer_zc(struct i40e_ring *rx_ring,
0a714186 Björn Töpel 2018-08-28 442 struct i40e_rx_buffer *old_bi)
0a714186 Björn Töpel 2018-08-28 443 {
0a714186 Björn Töpel 2018-08-28 444 struct i40e_rx_buffer *new_bi = &rx_ring->rx_bi[rx_ring->next_to_alloc];
0a714186 Björn Töpel 2018-08-28 @445 unsigned long mask = (unsigned long)rx_ring->xsk_umem->props.chunk_mask;
0a714186 Björn Töpel 2018-08-28 446 u64 hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
0a714186 Björn Töpel 2018-08-28 447 u16 nta = rx_ring->next_to_alloc;
0a714186 Björn Töpel 2018-08-28 448
0a714186 Björn Töpel 2018-08-28 449 /* update, and store next to alloc */
0a714186 Björn Töpel 2018-08-28 450 nta++;
0a714186 Björn Töpel 2018-08-28 451 rx_ring->next_to_alloc = (nta < rx_ring->count) ? nta : 0;
0a714186 Björn Töpel 2018-08-28 452
0a714186 Björn Töpel 2018-08-28 453 /* transfer page from old buffer to new buffer */
0a714186 Björn Töpel 2018-08-28 454 new_bi->dma = old_bi->dma & mask;
0a714186 Björn Töpel 2018-08-28 455 new_bi->dma += hr;
0a714186 Björn Töpel 2018-08-28 456
0a714186 Björn Töpel 2018-08-28 457 new_bi->addr = (void *)((unsigned long)old_bi->addr & mask);
0a714186 Björn Töpel 2018-08-28 458 new_bi->addr += hr;
0a714186 Björn Töpel 2018-08-28 459
0a714186 Björn Töpel 2018-08-28 460 new_bi->handle = old_bi->handle & mask;
0a714186 Björn Töpel 2018-08-28 461 new_bi->handle += rx_ring->xsk_umem->headroom;
0a714186 Björn Töpel 2018-08-28 462
0a714186 Björn Töpel 2018-08-28 463 old_bi->addr = NULL;
0a714186 Björn Töpel 2018-08-28 464 }
0a714186 Björn Töpel 2018-08-28 465
:::::: The code at line 445 was first introduced by commit
:::::: 0a714186d3c0f7c563a03537f98716457c1f5ae0 i40e: add AF_XDP zero-copy Rx support
:::::: TO: Björn Töpel <bjorn.topel@intel.com>
:::::: CC: Alexei Starovoitov <ast@kernel.org>
---
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: 51759 bytes --]
^ permalink raw reply
* [PATCH net-next v2 2/3] net: mvneta: enable NETIF_F_RXCSUM by default
From: Jisheng Zhang @ 2018-08-31 8:10 UTC (permalink / raw)
To: thomas.petazzoni, David S. Miller, Andrew Lunn, Gregory CLEMENT
Cc: netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20180831160810.2539ef4c@xhacker.debian>
The code and HW supports NETIF_F_RXCSUM, so let's enable it by default.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 814aee92a1d3..bcd20ebb2ebd 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4595,7 +4595,8 @@ static int mvneta_probe(struct platform_device *pdev)
}
}
- dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_TSO;
+ dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
+ NETIF_F_TSO | NETIF_F_RXCSUM;
dev->hw_features |= dev->features;
dev->vlan_features |= dev->features;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
--
2.18.0
^ permalink raw reply related
* [PATCH net-next v2 1/3] net: mvneta: Don't check NETIF_F_GRO ourself
From: Jisheng Zhang @ 2018-08-31 8:09 UTC (permalink / raw)
To: thomas.petazzoni, David S. Miller, Andrew Lunn, Gregory CLEMENT
Cc: netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20180831160810.2539ef4c@xhacker.debian>
napi_gro_receive() checks NETIF_F_GRO bit as well, if the bit is not
set, we will go through GRO_NORMAL in napi_skb_finish(), so fall back
to netif_receive_skb_internal(), so we don't need to check NETIF_F_GRO
ourself.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index bc80a678abc3..814aee92a1d3 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2065,10 +2065,7 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
/* Linux processing */
rxq->skb->protocol = eth_type_trans(rxq->skb, dev);
- if (dev->features & NETIF_F_GRO)
- napi_gro_receive(napi, rxq->skb);
- else
- netif_receive_skb(rxq->skb);
+ napi_gro_receive(napi, rxq->skb);
/* clean uncomplete skb pointer in queue */
rxq->skb = NULL;
--
2.18.0
^ permalink raw reply related
* [PATCH net-next v2 0/3] net: mvneta: some small improvements
From: Jisheng Zhang @ 2018-08-31 8:08 UTC (permalink / raw)
To: thomas.petazzoni, David S. Miller, Andrew Lunn, Gregory CLEMENT
Cc: netdev, linux-arm-kernel, linux-kernel
patch1 removes the NETIF_F_GRO check ourself, because the net subsystem
will handle it for us.
patch2 enables NETIF_F_RXCSUM by default, since the driver and HW
supports the feature.
patch3 is a small optimization, to reduce smp_processor_id() calling
in mvneta_tx_done_gbe.
since v1:
- based on net-next tree
- remove the fix patches, since they should be based on net branch.
- Add Gregory's Reviewed-by tag
Jisheng Zhang (3):
net: mvneta: Don't check NETIF_F_GRO ourself
net: mvneta: enable NETIF_F_RXCSUM by default
net: mvneta: reduce smp_processor_id() calling in mvneta_tx_done_gbe
drivers/net/ethernet/marvell/mvneta.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--
2.18.0
^ permalink raw reply
* [PATCH net-next] bnxt_en: remove set but not used variable 'rx_stats'
From: YueHaibing @ 2018-08-31 4:08 UTC (permalink / raw)
To: Michael Chan, David S. Miller; +Cc: YueHaibing, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c: In function 'bnxt_vf_rep_rx':
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c:212:28: warning:
variable 'rx_stats' set but not used [-Wunused-but-set-variable]
struct bnxt_vf_rep_stats *rx_stats;
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c
index e31f5d8..b574fe8 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c
@@ -209,9 +209,7 @@ struct net_device *bnxt_get_vf_rep(struct bnxt *bp, u16 cfa_code)
void bnxt_vf_rep_rx(struct bnxt *bp, struct sk_buff *skb)
{
struct bnxt_vf_rep *vf_rep = netdev_priv(skb->dev);
- struct bnxt_vf_rep_stats *rx_stats;
- rx_stats = &vf_rep->rx_stats;
vf_rep->rx_stats.bytes += skb->len;
vf_rep->rx_stats.packets++;
^ permalink raw reply related
* [PATCH net-next] failover: remove set but not used variable 'primary_dev'
From: YueHaibing @ 2018-08-31 3:46 UTC (permalink / raw)
To: David S. Miller, Sridhar Samudrala, Stephen Hemminger,
Dan Carpenter, Alexander Duyck, Jeff Kirsher, Liran Alon,
Joao Martins
Cc: YueHaibing, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/net_failover.c: In function 'net_failover_slave_unregister':
drivers/net/net_failover.c:598:35: warning:
variable 'primary_dev' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/net_failover.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/net_failover.c b/drivers/net/net_failover.c
index 7ae1856..e103c94e 100644
--- a/drivers/net/net_failover.c
+++ b/drivers/net/net_failover.c
@@ -595,12 +595,11 @@ static int net_failover_slave_pre_unregister(struct net_device *slave_dev,
static int net_failover_slave_unregister(struct net_device *slave_dev,
struct net_device *failover_dev)
{
- struct net_device *standby_dev, *primary_dev;
+ struct net_device *standby_dev;
struct net_failover_info *nfo_info;
bool slave_is_standby;
nfo_info = netdev_priv(failover_dev);
- primary_dev = rtnl_dereference(nfo_info->primary_dev);
standby_dev = rtnl_dereference(nfo_info->standby_dev);
vlan_vids_del_by_dev(slave_dev, failover_dev);
^ permalink raw reply related
* [PATCH net-next] net: remove duplicated include from net_failover.c
From: YueHaibing @ 2018-08-31 3:44 UTC (permalink / raw)
To: David S. Miller, Sridhar Samudrala, Stephen Hemminger,
Dan Carpenter, Alexander Duyck, Jeff Kirsher, Liran Alon,
Joao Martins
Cc: YueHaibing, netdev, kernel-janitors
Remove duplicated include.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/net_failover.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/net_failover.c b/drivers/net/net_failover.c
index 7ae1856..192ae1c 100644
--- a/drivers/net/net_failover.c
+++ b/drivers/net/net_failover.c
@@ -19,7 +19,6 @@
#include <linux/ethtool.h>
#include <linux/module.h>
#include <linux/slab.h>
-#include <linux/netdevice.h>
#include <linux/netpoll.h>
#include <linux/rtnetlink.h>
#include <linux/if_vlan.h>
^ permalink raw reply related
* [PATCH] mac80211: fix TX status reporting for ieee80211s
From: Yuan-Chi Pang @ 2018-08-31 7:12 UTC (permalink / raw)
To: johannes; +Cc: davem, linux-wireless, netdev, linux-kernel, Yuan-Chi Pang
ieee80211s_update_metric works only if wireless
driver passes tx_status of data frame to mac80211
Make API and caller of ieee80211s_update_metric to be
similar to rate_control_tx_status
Signed-off-by: Yuan-Chi Pang <fu3mo6goo@gmail.com>
---
net/mac80211/mesh.h | 2 +-
net/mac80211/mesh_hwmp.c | 8 ++------
net/mac80211/status.c | 4 +++-
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index ee56f18..3c6095a 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -217,7 +217,7 @@ void mesh_rmc_free(struct ieee80211_sub_if_data *sdata);
int mesh_rmc_init(struct ieee80211_sub_if_data *sdata);
void ieee80211s_init(void);
void ieee80211s_update_metric(struct ieee80211_local *local,
- struct sta_info *sta, struct sk_buff *skb);
+ struct sta_info *sta, struct ieee80211_tx_status *st);
void ieee80211_mesh_init_sdata(struct ieee80211_sub_if_data *sdata);
void ieee80211_mesh_teardown_sdata(struct ieee80211_sub_if_data *sdata);
int ieee80211_start_mesh(struct ieee80211_sub_if_data *sdata);
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index daf9db3..4286673 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -295,15 +295,11 @@ int mesh_path_error_tx(struct ieee80211_sub_if_data *sdata,
}
void ieee80211s_update_metric(struct ieee80211_local *local,
- struct sta_info *sta, struct sk_buff *skb)
+ struct sta_info *sta, struct ieee80211_tx_status *st)
{
- struct ieee80211_tx_info *txinfo = IEEE80211_SKB_CB(skb);
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+ struct ieee80211_tx_info *txinfo = st->info;
int failed;
- if (!ieee80211_is_data(hdr->frame_control))
- return;
-
failed = !(txinfo->flags & IEEE80211_TX_STAT_ACK);
/* moving average, scaled to 100.
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 9a6d720..dfcd419 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -811,7 +811,7 @@ static void __ieee80211_tx_status(struct ieee80211_hw *hw,
rate_control_tx_status(local, sband, status);
if (ieee80211_vif_is_mesh(&sta->sdata->vif))
- ieee80211s_update_metric(local, sta, skb);
+ ieee80211s_update_metric(local, sta, status);
if (!(info->flags & IEEE80211_TX_CTL_INJECTED) && acked)
ieee80211_frame_acked(sta, skb);
@@ -972,6 +972,8 @@ void ieee80211_tx_status_ext(struct ieee80211_hw *hw,
}
rate_control_tx_status(local, sband, status);
+ if (ieee80211_vif_is_mesh(&sta->sdata->vif))
+ ieee80211s_update_metric(local, sta, status);
}
if (acked || noack_success) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 bpf-next 0/2] bpf tcp save syn set/get sockoptions
From: Alexei Starovoitov @ 2018-08-31 3:00 UTC (permalink / raw)
To: Nikita V. Shirokov; +Cc: ast, brakmo, daniel, netdev
In-Reply-To: <20180830145154.1128593-1-tehnerd@fb.com>
On Thu, Aug 30, 2018 at 07:51:52AM -0700, Nikita V. Shirokov wrote:
>
> adding supprot for two new bpf's tcp sockopts:
> TCP_SAVE_SYN (set) and TCP_SAVED_SYN (get)
> this would allow for tcp-bpf program to build some logic based on fields from
> ingress syn packet (e.g. doing tcp's tos/tclass reflection (see sample prog))
> and do it transparently from userspace program point of view
Applied, Thanks
but please convert the sample code into selftest.
^ permalink raw reply
* Re: [PATCH][net-next] xdp: remove redundant variable 'headroom'
From: Alexei Starovoitov @ 2018-08-31 2:50 UTC (permalink / raw)
To: Björn Töpel
Cc: Colin King, David S . Miller, Jesper Dangaard Brouer, netdev,
Alexei Starovoitov, daniel@iogearbox.net, kernel-janitors,
linux-kernel
In-Reply-To: <ec579a7c-345b-f462-95ac-f36de1072614@intel.com>
On Thu, Aug 30, 2018 at 04:37:50PM +0200, Björn Töpel wrote:
> On 2018-08-30 16:27, Colin King wrote:
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > Variable 'headroom' is being assigned but is never used hence it is
> > redundant and can be removed.
> >
> > Cleans up clang warning:
> > variable ‘headroom’ set but not used [-Wunused-but-set-variable]
> >
> > Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > ---
> > net/core/xdp.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/net/core/xdp.c b/net/core/xdp.c
> > index 654dbb19707e..4b2b194f4f1f 100644
> > --- a/net/core/xdp.c
> > +++ b/net/core/xdp.c
> > @@ -412,7 +412,7 @@ EXPORT_SYMBOL_GPL(xdp_attachment_setup);
> > struct xdp_frame *xdp_convert_zc_to_xdp_frame(struct xdp_buff *xdp)
> > {
> > - unsigned int metasize, headroom, totsize;
> > + unsigned int metasize, totsize;
> > void *addr, *data_to_copy;
> > struct xdp_frame *xdpf;
> > struct page *page;
> > @@ -420,7 +420,6 @@ struct xdp_frame *xdp_convert_zc_to_xdp_frame(struct xdp_buff *xdp)
> > /* Clone into a MEM_TYPE_PAGE_ORDER0 xdp_frame. */
> > metasize = xdp_data_meta_unsupported(xdp) ? 0 :
> > xdp->data - xdp->data_meta;
> > - headroom = xdp->data - xdp->data_hard_start;
> > totsize = xdp->data_end - xdp->data + metasize;
> > if (sizeof(*xdpf) + totsize > PAGE_SIZE)
> >
>
> This should go via bpf-next. Thanks for the fix!
>
> Acked-by: Björn Töpel <bjorn.topel@intel.com>
Applied, Thanks
^ permalink raw reply
* Re: [PATCH bpf-next 0/3] xsk: misc code cleanup
From: Alexei Starovoitov @ 2018-08-31 2:42 UTC (permalink / raw)
To: Magnus Karlsson; +Cc: bjorn.topel, ast, daniel, netdev
In-Reply-To: <1535637403-14549-1-git-send-email-magnus.karlsson@intel.com>
On Thu, Aug 30, 2018 at 03:56:40PM +0200, Magnus Karlsson wrote:
> This patch set cleans up two code style issues with the xsk zero-copy
> code. The resulting code is smaller and simpler.
>
> Patch 1: Removes a potential compiler warning reported by the Intel
> 0-DAY kernel test infrastructure.
> Patches 2-3: Removes the xdp_umem_props structure. At some point, it
> was used to break a dependency, but the members are these
> days much better off in the xdp_umem since the dependency
> does not exist anymore.
>
> I based this patch set on bpf-next commit 234dbe3dc1db ("Merge branch
> 'verifier-liveness-simplification'")
Applied, Thanks
^ permalink raw reply
* [PATCH bpf-next] samples/bpf: xdpsock, minor fixes
From: Prashant Bhole @ 2018-08-31 1:00 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Björn Töpel,
Magnus Karlsson
Cc: Prashant Bhole, netdev
- xsks_map size was fixed to 4, changed it MAX_SOCKS
- Remove redundant definition of MAX_SOCKS in xdpsock_user.c
- In dump_stats(), add NULL check for xsks[i]
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
samples/bpf/xdpsock_kern.c | 2 +-
samples/bpf/xdpsock_user.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/samples/bpf/xdpsock_kern.c b/samples/bpf/xdpsock_kern.c
index d8806c41362e..b8ccd0802b3f 100644
--- a/samples/bpf/xdpsock_kern.c
+++ b/samples/bpf/xdpsock_kern.c
@@ -16,7 +16,7 @@ struct bpf_map_def SEC("maps") xsks_map = {
.type = BPF_MAP_TYPE_XSKMAP,
.key_size = sizeof(int),
.value_size = sizeof(int),
- .max_entries = 4,
+ .max_entries = MAX_SOCKS,
};
struct bpf_map_def SEC("maps") rr_map = {
diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
index b3906111bedb..57ecadc58403 100644
--- a/samples/bpf/xdpsock_user.c
+++ b/samples/bpf/xdpsock_user.c
@@ -118,7 +118,6 @@ struct xdpsock {
unsigned long prev_tx_npkts;
};
-#define MAX_SOCKS 4
static int num_socks;
struct xdpsock *xsks[MAX_SOCKS];
@@ -596,7 +595,7 @@ static void dump_stats(void)
prev_time = now;
- for (i = 0; i < num_socks; i++) {
+ for (i = 0; i < num_socks && xsks[i]; i++) {
char *fmt = "%-15s %'-11.0f %'-11lu\n";
double rx_pps, tx_pps;
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next] xsk: remove unnecessary assignment
From: Prashant Bhole @ 2018-08-31 0:59 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Björn Töpel,
Magnus Karlsson
Cc: Prashant Bhole, netdev
Since xdp_umem_query() was added one assignment of bpf.command was
missed from cleanup. Removing the assignment statement.
Fixes: 84c6b86875e01a0 ("xsk: don't allow umem replace at stack level")
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
net/xdp/xdp_umem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index bfe2dbea480b..d179732617dc 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -76,8 +76,6 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
if (!dev->netdev_ops->ndo_bpf || !dev->netdev_ops->ndo_xsk_async_xmit)
return force_zc ? -EOPNOTSUPP : 0; /* fail or fallback */
- bpf.command = XDP_QUERY_XSK_UMEM;
-
rtnl_lock();
err = xdp_umem_query(dev, queue_id);
if (err) {
--
2.17.1
^ permalink raw reply related
* Re: [bpf PATCH] bpf: avoid kcm psock use and tcp_bpf from colliding
From: John Fastabend @ 2018-08-31 0:24 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev
In-Reply-To: <20180830223325.11399.82496.stgit@john-Precision-Tower-5810>
On 08/30/2018 03:33 PM, John Fastabend wrote:
> Currently we check sk_user_data is non NULL to determine if the sk
> exists in a map. However, this is not sufficient to ensure the psock
> is not in use by another (non-ULP TCP) user, such as kcm. To avoid
> this when adding a sock to a map also verify it is of the correct ULP
> type.
>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
I'll send a v2 of this we have one more spot we need to check
the psock type in the error path.
Thanks,
John
^ permalink raw reply
* Re: [PATCH] net: sched: Fix memory exposure from short TCA_U32_SEL
From: Al Viro @ 2018-08-31 4:03 UTC (permalink / raw)
To: Cong Wang
Cc: Jamal Hadi Salim, Kees Cook, LKML, Jiri Pirko, David Miller,
Linux Kernel Network Developers
In-Reply-To: <20180828155938.GF6515@ZenIV.linux.org.uk>
On Tue, Aug 28, 2018 at 04:59:38PM +0100, Al Viro wrote:
> On Tue, Aug 28, 2018 at 01:03:10AM +0100, Al Viro wrote:
> > if (tcf_exts_get_net(&n->exts))
> > tcf_queue_work(&n->rwork, u32_delete_key_freepf_work);
> > else
> > u32_destroy_key(n->tp, n, true);
> > ... and we hit u32_destroy_key(<tp>, <knode>, true), which does
>
> Speaking of which, we'd better never hit that branch for other reasons - there's
> no RCU delay between removal of knode from the hash chain and its kfree().
> tcf_queue_work() does guarantee such delay (by use of queue_rcu_work()), direct
> call doesn't...
>
> Anyway, whichever branch is taken, the memory corruption problem remains - the
> comments below are accurate, AFAICS.
>
> > Incidentally, if we hit
> > tcf_queue_work(&n->rwork, u32_delete_key_freepf_work);
> > instead of u32_destroy_key(), the things don't seem to be any better - we
> > won't do anything to <knode> until rtnl is dropped, so u32_destroy() won't
> > break on the second pass through the loop - it'll free <ht0> there and
> > return. Setting us up for trouble, since when u32_delete_key_freepf_work()
> > finally gets to u32_destroy_key() we'll have <knode>->ht_down pointing
> > to freed memory and decrementing its contents...
Build the kernel with slab poisoning and try this:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 100 handle 1: u32 divisor 1
tc filter add dev eth0 parent ffff: protocol ip prio 200 handle 2: u32 divisor 1
tc filter add dev eth0 parent ffff: protocol ip prio 100 handle 1:0:11 u32 ht 1: link 801: offset at 0 mask 0f00 shift 6 plus 0 eat match ip protocol 6 ff
tc filter delete dev eth0 parent ffff: protocol ip prio 200
tc filter change dev eth0 parent ffff: protocol ip prio 100 handle 1:0:11 u32 ht 1: link 0: offset at 0 mask 0f00 shift 6 plus 0 eat match ip protocol 6 ff
tc filter delete dev eth0 parent ffff: protocol ip prio 100
Then watch it oops in u32_lookup_ht() from u32_get() from tc_del_tfilter()
Oopsing insn: cmp %ebp,0x8(%rbx). RBX: 6b6b6b6b6b6b6b6b, i.e. slab
poison...
What happens is that ht 801: (created when we'd added tcf_proto for prio 200)
gets pinned down by link 801: in the third tc filter add. Then removal of
prio 200 triggers u32_destroy(), dropping refcount on 801: and doing nothing
else to it. Then filter change drops the last reference to 801:, freeing
it. And we have a freed struct tc_u_hnode stuck in the middle of the list...
^ permalink raw reply
* [RFC PATCH] bpf: test_maps add a test to catch kcm + sockmap
From: John Fastabend @ 2018-08-30 22:39 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev
In-Reply-To: <20180830223555.11553.24093.stgit@john-Precision-Tower-5810>
RFC for now, once the fix is in bpf-next will submit there.
Adding a socket to both sockmap and kcm is not supported due to
collision on sk_user_data usage. At some point we will fix this
but until then lets ensure we don't corrupt things.
Now if selftests is run without KCM support we will issue a
warning and continue with the tests.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
tools/testing/selftests/bpf/Makefile | 2 -
tools/testing/selftests/bpf/test_maps.c | 64 ++++++++++++++++++++++++++++++-
2 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index fff7fb1..16f5dcc 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -35,7 +35,7 @@ TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test
test_get_stack_rawtp.o test_sockmap_kern.o test_sockhash_kern.o \
test_lwt_seg6local.o sendmsg4_prog.o sendmsg6_prog.o test_lirc_mode2_kern.o \
get_cgroup_id_kern.o socket_cookie_prog.o test_select_reuseport_kern.o \
- test_skb_cgroup_id_kern.o
+ test_skb_cgroup_id_kern.o sockmap_kcm.o
# Order correspond to 'make run_tests' order
TEST_PROGS := test_kmod.sh \
diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
index 6f54f84..473b690 100644
--- a/tools/testing/selftests/bpf/test_maps.c
+++ b/tools/testing/selftests/bpf/test_maps.c
@@ -20,6 +20,7 @@
#include <sys/socket.h>
#include <netinet/in.h>
#include <linux/bpf.h>
+#include <linux/kcm.h>
#include <bpf/bpf.h>
#include <bpf/libbpf.h>
@@ -479,14 +480,16 @@ static void test_devmap(int task, void *data)
#define SOCKMAP_PARSE_PROG "./sockmap_parse_prog.o"
#define SOCKMAP_VERDICT_PROG "./sockmap_verdict_prog.o"
#define SOCKMAP_TCP_MSG_PROG "./sockmap_tcp_msg_prog.o"
+#define KCM_PROG "./sockmap_kcm.o"
static void test_sockmap(int tasks, void *data)
{
struct bpf_map *bpf_map_rx, *bpf_map_tx, *bpf_map_msg, *bpf_map_break;
- int map_fd_msg = 0, map_fd_rx = 0, map_fd_tx = 0, map_fd_break;
+ int map_fd_msg = 0, map_fd_rx = 0, map_fd_tx = 0, map_fd_break, kcm;
int ports[] = {50200, 50201, 50202, 50204};
int err, i, fd, udp, sfd[6] = {0xdeadbeef};
u8 buf[20] = {0x0, 0x5, 0x3, 0x2, 0x1, 0x0};
- int parse_prog, verdict_prog, msg_prog;
+ int parse_prog, verdict_prog, msg_prog, kcm_prog;
+ struct kcm_attach attach_info;
struct sockaddr_in addr;
int one = 1, s, sc, rc;
struct bpf_object *obj;
@@ -740,6 +743,62 @@ static void test_sockmap(int tasks, void *data)
goto out_sockmap;
}
+ /* Test adding a KCM socket into map */
+#define AF_KCM 41
+ kcm = socket(AF_KCM, SOCK_DGRAM, KCMPROTO_CONNECTED);
+ if (kcm == -1) {
+ printf("Warning, KCM+Sockmap could not be tested.\n");
+ goto skip_kcm;
+ }
+
+ err = bpf_prog_load(KCM_PROG,
+ BPF_PROG_TYPE_SOCKET_FILTER,
+ &obj, &kcm_prog);
+ if (err) {
+ printf("Failed to load SK_SKB parse prog\n");
+ goto out_sockmap;
+ }
+
+ i = 2;
+ memset(&attach_info, 0, sizeof(attach_info));
+ attach_info.fd = sfd[i];
+ attach_info.bpf_fd = kcm_prog;
+ err = ioctl(kcm, SIOCKCMATTACH, &attach_info);
+ if (!err) {
+ perror("Failed KCM attached to sockmap fd: ");
+ goto out_sockmap;
+ }
+
+ err = bpf_map_delete_elem(fd, &i);
+ if (err) {
+ printf("Failed delete sockmap from empty map %i %i\n", err, errno);
+ goto out_sockmap;
+ }
+
+ err = ioctl(kcm, SIOCKCMATTACH, &attach_info);
+ if (err) {
+ perror("Failed KCM attach");
+ goto out_sockmap;
+ }
+
+ err = bpf_map_update_elem(fd, &i, &sfd[i], BPF_ANY);
+ if (!err) {
+ printf("Failed sockmap attached KCM sock!\n");
+ goto out_sockmap;
+ }
+ err = ioctl(kcm, SIOCKCMUNATTACH, &attach_info);
+ if (err) {
+ printf("Failed detattch KCM sock!\n");
+ goto out_sockmap;
+ }
+
+ err = bpf_map_update_elem(fd, &i, &sfd[i], BPF_ANY);
+ if (err) {
+ printf("Failed post-kcm update sockmap '%i:%i'\n",
+ i, sfd[i]);
+ goto out_sockmap;
+ }
+
/* Test map update elem afterwards fd lives in fd and map_fd */
for (i = 0; i < 6; i++) {
err = bpf_map_update_elem(map_fd_rx, &i, &sfd[i], BPF_ANY);
@@ -772,6 +831,7 @@ static void test_sockmap(int tasks, void *data)
}
}
+skip_kcm:
/* Put sfd[2] (sending fd below) into msg map to test sendmsg bpf */
i = 0;
err = bpf_map_update_elem(map_fd_msg, &i, &sfd[2], BPF_ANY);
^ 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