* Re: [PATCH net-next 2/2] netns: isolate seqnums to use per-netns locks
From: Christian Brauner @ 2018-04-23 10:12 UTC (permalink / raw)
To: kbuild-all
Cc: ebiederm, davem, netdev, linux-kernel, avagin, ktkhai, serge,
gregkh
In-Reply-To: <201804231003.izXFVWTI%fengguang.wu@intel.com>
On Mon, Apr 23, 2018 at 10:39:50AM +0800, kbuild test robot wrote:
> Hi Christian,
>
> 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/Christian-Brauner/netns-uevent-performance-tweaks/20180420-013717
> config: alpha-alldefconfig (attached as .config)
> compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.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
> make.cross ARCH=alpha
>
> All errors (new ones prefixed by >>):
>
> kernel/ksysfs.o: In function `uevent_seqnum_show':
> >> (.text+0x18c): undefined reference to `get_ns_uevent_seqnum_by_vpid'
> (.text+0x19c): undefined reference to `get_ns_uevent_seqnum_by_vpid'
Right, this happens when CONFIG_NET=n. I am about to send out the second
version of the patch that includes all of the test results in the commit
message and also accounts for kernels compiled without CONFIG_NET.
Thanks!
Christian
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: How to detect libbfd when building tools/bpf?
From: Daniel Borkmann @ 2018-04-23 10:05 UTC (permalink / raw)
To: Wang Sheng-Hui, ast, kstewart, gregkh, tglx, pombredanne
Cc: netdev, acme, jakub.kicinski, quentin.monnet
In-Reply-To: <tencent_2F07B2EF6347A6E6521E4B9DECEEDBF88E05@qq.com>
On 04/22/2018 09:51 AM, Wang Sheng-Hui wrote:
> Sorry to trouble you !
>
> I run debian and installed binutils-dev beforehand.
> Then I copied tools/build/feature/test-libbfd.c to t.c and run:
> ------------------------------------------------------------------------
> root@lazyfintech:~# cat t.c
> #include <bfd.h>
>
> extern int printf(const char *format, ...);
>
> int main(void)
> {
> char symbol[4096] = "FieldName__9ClassNameFd";
> char *tmp;
>
> tmp = bfd_demangle(0, symbol, 0);
>
> printf("demangled symbol: {%s}\n", tmp);
>
> return 0;
> }
> root@lazyfintech:~# gcc t.c -lbfd
Can you run with 'gcc t.c -lbfd -lz -liberty -ldl' since this is
what the Makefile for the feature test is doing:
$(OUTPUT)test-libbfd.bin:
$(BUILD) -DPACKAGE='"perf"' -lbfd -lz -liberty -ldl
Seems most likely that you're missing some of the remaining libs
to have the feature test properly detect it?
> root@lazyfintech:~# ./a.out
> demangled symbol: {ClassName::FieldName}
>
>
> I thought libbfd can be reached from above.
> But when I built tools/bpf, libbfd cannot be detected:
> -------------------------------------------------------------------------
> /linux# make O=../buildkernel/ tools/bpf
> make[1]: Entering directory '/root/buildkernel'
> DESCEND bpf
>
> Auto-detecting system features:
> ... libbfd: [ OFF ]
> ... disassembler-four-args: [ on ]
>
> DESCEND bpftool
>
> Auto-detecting system features:
> ... libbfd: [ OFF ]
> ... disassembler-four-args: [ on ]
>
> make[1]: Leaving directory '/root/buildkernel'
>
>
> I wonder how should I do to get libbfd auto detected when building bpf tool?
>
> Regards,
> shenghui
^ permalink raw reply
* Re: [PATCH 2/3] xen netback: add fault injection facility
From: Wei Liu @ 2018-04-23 9:58 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: jakub.kicinski, hpa, mcroce, tglx, ggarcia, daniel, x86, mingo,
xen-devel, axboe, konrad.wilk, amir.jer.levy, paul.durrant,
stefanha, dsa, boris.ostrovsky, jgross, linux-block, wei.liu2,
netdev, linux-kernel, davem, dwmw, roger.pau
In-Reply-To: <20180420104731.17823.97617.stgit@dev-dsk-staskins-1a-ca5afbf2.eu-west-1.amazon.com>
On Fri, Apr 20, 2018 at 10:47:31AM +0000, Stanislav Kinsburskii wrote:
>
> #include <linux/kthread.h>
> #include <linux/if_vlan.h>
> @@ -1649,6 +1650,7 @@ static int __init netback_init(void)
> PTR_ERR(xen_netback_dbg_root));
> #endif /* CONFIG_DEBUG_FS */
>
> + (void) xen_netbk_fi_init();
If you care about the return value, please propagate it to
netback_init's caller. Otherwise you can just make the function return
void.
> +
> +int xenvif_fi_init(struct xenvif *vif)
> +{
> + struct dentry *parent;
> + struct xenvif_fi *vfi;
> + int fi, err = -ENOMEM;
> +
> + parent = vif_fi_dir;
> + if (!parent)
> + return -ENOMEM;
> +
> + vfi = kmalloc(sizeof(*vfi), GFP_KERNEL);
> + if (!vfi)
> + return -ENOMEM;
> +
> + vfi->dir = debugfs_create_dir(vif->dev->name, parent);
> + if (!vfi->dir)
> + goto err_dir;
> +
> + for (fi = 0; fi < XENVIF_FI_MAX; fi++) {
> + vfi->faults[fi] = xen_fi_dir_add(vfi->dir,
> + xenvif_fi_names[fi]);
> + if (!vfi->faults[fi])
> + goto err_fault;
> + }
> +
> + vif->fi_info = vfi;
> + return 0;
> +
> +err_fault:
> + for (; fi > 0; fi--)
fi >= 0
Wei.
^ permalink raw reply
* Re: bpf: samples/bpf/sockex2: Assertion `setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, prog_fd, sizeof(prog_fd[0])) == 0' failed.
From: Daniel Borkmann @ 2018-04-23 9:53 UTC (permalink / raw)
To: Wang Sheng-Hui, ast, netdev
In-Reply-To: <tencent_8DE3019EA8BEBE9DCA1A4C791875FCBB7E07@qq.com>
On 04/23/2018 04:56 AM, Wang Sheng-Hui wrote:
> Sorry to trouble you!
>
> I run samples/bpf/sockex2 failed with
> "Assertion `setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, prog_fd, sizeof(prog_fd[0])) == 0' failed."
>
> Then I run " strace ./sockex2" and got:
> ...
> bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("lo"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
> setsockopt(3, SOL_SOCKET, SO_ATTACH_BPF, [0], 4) = -1 EINVAL (Invalid argument)
> write(2, "sockex2: /root/linux/samples/bpf"..., 156sockex2: /root/linux/samples/bpf/sockex2_user.c:35: main: Assertion `setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, prog_fd, sizeof(prog_fd[0])) == 0' failed.
> ) = 156
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb8ec4bf000
> rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
> rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
> getpid() = 3513
> gettid() = 3513
> tgkill(3513, 3513, SIGABRT) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=3513, si_uid=0} ---
> +++ killed by SIGABRT +++
> Aborted
[...]
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=16, max_entries=1024}, 72) = 4
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_SOCKET_FILTER, insn_cnt=201, insns=0x2676cd0, license="GPL", log_level=0, log_size=0, log_buf=0, kern_version=0}, 72) = 5
close(3) = 0
socket(AF_PACKET, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, 768) = 3
access("/proc/net", R_OK) = 0
access("/proc/net/unix", R_OK) = 0
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 6
ioctl(6, SIOCGIFINDEX, {ifr_name="lo", }) = 0
close(6) = 0
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("lo"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_BPF, [5], 4) = 0
pipe2([6, 7], O_CLOEXEC) = 0
[...]
Works fine for me. The EINVAL in your case comes from the 'setsockopt(3, SOL_SOCKET,
SO_ATTACH_BPF, [0], 4)'. So you send fd 0 to SO_ATTACH_BPF, which is not a valid BPF
fd and therefore bails out here. You might want to debug bpf_load.c why it's failing
to load the program in your case, or check strace a bit further above where you do
the map and prog creation (as I copied in my case).
Cheers,
Daniel
^ permalink raw reply
* Re: [lkp-robot] [bpf] 4f7b25baf0: kernel_selftests.bpf.test_maps.fail
From: Daniel Borkmann @ 2018-04-23 9:41 UTC (permalink / raw)
To: kernel test robot, John Fastabend; +Cc: ast, netdev, davem, lkp
In-Reply-To: <20180423063250.GO5563@yexl-desktop>
On 04/23/2018 08:32 AM, kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 4f7b25baf0cefa88aa267e8ff60150c4ac1479ef ("bpf: sockmap, refactor sockmap routines to work with hashmap")
> url: https://github.com/0day-ci/linux/commits/John-Fastabend/bpf-sockmap-free-memory-on-sock-close-with-cork-data/20180401-230416
> base: https://git.kernel.org/cgit/linux/kernel/git/bpf/bpf-next.git master
(fyi, refers to https://patchwork.ozlabs.org/patch/894017/ which is not in tree.)
> in testcase: kernel_selftests
> with following parameters:
>
> group: kselftests-00
>
> test-description: The kernel contains a set of "self tests" under the tools/testing/selftests/ directory. These are intended to be small unit tests to exercise individual code paths in the kernel.
> test-url: https://www.kernel.org/doc/Documentation/kselftest.txt
>
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 4 -m 5G
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
> selftests: test_maps
> ========================================
> Failed allowed duplicate programs in update ANY sockmap 0 '4:8'
> not ok 1..3 selftests: test_maps [FAIL]
>
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
>
>
>
> Thanks,
> Xiaolong
>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: btf: Clean up btf.h in uapi
From: Daniel Borkmann @ 2018-04-23 9:34 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, kernel-team
In-Reply-To: <20180421164823.1059397-1-kafai@fb.com>
On 04/21/2018 06:48 PM, Martin KaFai Lau wrote:
> This patch cleans up btf.h in uapi:
> 1) Rename "name" to "name_off" to better reflect it is an offset to the
> string section instead of a char array.
> 2) Remove unused value BTF_FLAGS_COMPR and BTF_MAGIC_SWAP
>
> Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Applied to bpf-next, thanks Martin!
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: fix virtio-net's length calc for XDP_PASS
From: Daniel Borkmann @ 2018-04-23 9:30 UTC (permalink / raw)
To: Jason Wang, Nikita V. Shirokov, Alexei Starovoitov,
Michael S. Tsirkin
Cc: netdev, David Ahern
In-Reply-To: <eced76a9-5480-8180-7e5a-84a62d0fdc8b@redhat.com>
On 04/23/2018 08:33 AM, Jason Wang wrote:
> On 2018年04月23日 12:16, Nikita V. Shirokov wrote:
>> In commit 6870de435b90 ("bpf: make virtio compatible w/
>> bpf_xdp_adjust_tail") i didn't account for vi->hdr_len during new
>> packet's length calculation after bpf_prog_run in receive_mergeable.
>> because of this all packets, if they were passed to the kernel,
>> were truncated by 12 bytes.
>>
>> Fixes:6870de435b90 ("bpf: make virtio compatible w/ bpf_xdp_adjust_tail")
>> Reported-by: David Ahern <dsahern@gmail.com>
>>
>> Signed-off-by: Nikita V. Shirokov <tehnerd@tehnerd.com>
[...]
>
> Acked-by: Jason Wang <jasowang@redhat.com>
Applied to bpf-next, thanks everyone!
^ permalink raw reply
* Re: [PATCH/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol
From: Simon Horman @ 2018-04-23 9:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: alsa-devel, Kuninori Morimoto, Catalin Marinas, Will Deacon,
Liam Girdwood, Laurent Pinchart, devel, Mauro Carvalho Chehab,
Vinod Koul, Magnus Damm, Russell King, linux-media, Arnd Bergmann,
Mark Brown, Dan Williams, Jaroslav Kysela, linux-arm-kernel,
Sergei Shtylyov, Greg Kroah-Hartman, Takashi Iwai, linux-kernel,
linux-renesas-soc, netdev, dmaengine
In-Reply-To: <1524230914-10175-8-git-send-email-geert+renesas@glider.be>
On Fri, Apr 20, 2018 at 03:28:33PM +0200, Geert Uytterhoeven wrote:
> All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
> platform dependencies. Hence finish the conversion from ARCH_SHMOBILE
> to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
> 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> This depends on the previous patches in this series, hence the RFC.
Thanks, I have marked this and the following patch as deferred.
Please repost or otherwise ping me once the dependencies are in place.
^ permalink raw reply
* Re: [RFC v2] virtio: support packed ring
From: Tiwei Bie @ 2018-04-23 9:29 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, wexu, virtualization, linux-kernel, netdev, jfreimann
In-Reply-To: <515e635b-bc80-9b8d-72f9-b390ae5103ec@redhat.com>
On Mon, Apr 23, 2018 at 01:42:14PM +0800, Jason Wang wrote:
> On 2018年04月01日 22:12, Tiwei Bie wrote:
> > Hello everyone,
> >
> > This RFC implements packed ring support for virtio driver.
> >
> > The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented
> > by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html
> > Minor changes are needed for the vhost code, e.g. to kick the guest.
> >
> > TODO:
> > - Refinements and bug fixes;
> > - Split into small patches;
> > - Test indirect descriptor support;
> > - Test/fix event suppression support;
> > - Test devices other than net;
> >
> > RFC v1 -> RFC v2:
> > - Add indirect descriptor support - compile test only;
> > - Add event suppression supprt - compile test only;
> > - Move vring_packed_init() out of uapi (Jason, MST);
> > - Merge two loops into one in virtqueue_add_packed() (Jason);
> > - Split vring_unmap_one() for packed ring and split ring (Jason);
> > - Avoid using '%' operator (Jason);
> > - Rename free_head -> next_avail_idx (Jason);
> > - Add comments for virtio_wmb() in virtqueue_add_packed() (Jason);
> > - Some other refinements and bug fixes;
> >
> > Thanks!
> >
> > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > ---
> > drivers/virtio/virtio_ring.c | 1094 +++++++++++++++++++++++++++++-------
> > include/linux/virtio_ring.h | 8 +-
> > include/uapi/linux/virtio_config.h | 12 +-
> > include/uapi/linux/virtio_ring.h | 61 ++
> > 4 files changed, 980 insertions(+), 195 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index 71458f493cf8..0515dca34d77 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -58,14 +58,15 @@
>
> [...]
>
> > +
> > + if (vq->indirect) {
> > + u32 len;
> > +
> > + desc = vq->desc_state[head].indir_desc;
> > + /* Free the indirect table, if any, now that it's unmapped. */
> > + if (!desc)
> > + goto out;
> > +
> > + len = virtio32_to_cpu(vq->vq.vdev,
> > + vq->vring_packed.desc[head].len);
> > +
> > + BUG_ON(!(vq->vring_packed.desc[head].flags &
> > + cpu_to_virtio16(vq->vq.vdev, VRING_DESC_F_INDIRECT)));
>
> It looks to me spec does not force to keep VRING_DESC_F_INDIRECT here. So we
> can safely remove this BUG_ON() here.
>
> > + BUG_ON(len == 0 || len % sizeof(struct vring_packed_desc));
>
> Len could be ignored for used descriptor according to the spec, so we need
> remove this BUG_ON() too.
Yeah, you're right! The BUG_ON() isn't right. I'll remove it.
And I think something related to this in the spec isn't very
clear currently.
In the spec, there are below words:
https://github.com/oasis-tcs/virtio-spec/blob/d4fec517dfcf/packed-ring.tex#L272
"""
In descriptors with VIRTQ_DESC_F_INDIRECT set VIRTQ_DESC_F_WRITE
is reserved and is ignored by the device.
"""
So when device writes back an used descriptor in this case,
device may not set the VIRTQ_DESC_F_WRITE flag as the flag
is reserved and should be ignored.
https://github.com/oasis-tcs/virtio-spec/blob/d4fec517dfcf/packed-ring.tex#L170
"""
Element Length is reserved for used descriptors without the
VIRTQ_DESC_F_WRITE flag, and is ignored by drivers.
"""
And this is the way how driver ignores the `len` in an used
descriptor.
https://github.com/oasis-tcs/virtio-spec/blob/d4fec517dfcf/packed-ring.tex#L241
"""
To increase ring capacity the driver can store a (read-only
by the device) table of indirect descriptors anywhere in memory,
and insert a descriptor in the main virtqueue (with \field{Flags}
bit VIRTQ_DESC_F_INDIRECT on) that refers to a buffer element
containing this indirect descriptor table;
"""
So the indirect descriptors in the table are read-only by
the device. And the only descriptor which is writeable by
the device is the descriptor in the main virtqueue (with
Flags bit VIRTQ_DESC_F_INDIRECT on). So if we ignore the
`len` in this descriptor, we won't be able to get the
length of the data written by the device.
So I think the `len` in this descriptor will carry the
length of the data written by the device (if the buffers
are writable to the device) even if the VIRTQ_DESC_F_WRITE
isn't set by the device. How do you think?
>
> The reason is we don't touch descriptor ring in the case of split, so
> BUG_ON()s may help there.
>
> > +
> > + for (j = 0; j < len / sizeof(struct vring_packed_desc); j++)
> > + vring_unmap_one_packed(vq, &desc[j]);
> > +
> > + kfree(desc);
> > + vq->desc_state[head].indir_desc = NULL;
> > + } else if (ctx) {
> > + *ctx = vq->desc_state[head].indir_desc;
> > + }
> > +
> > +out:
> > + return vq->desc_state[head].num;
> > +}
> > +
> > +static inline bool more_used_split(const struct vring_virtqueue *vq)
> > {
> > return vq->last_used_idx != virtio16_to_cpu(vq->vq.vdev, vq->vring.used->idx);
> > }
> > +static inline bool more_used_packed(const struct vring_virtqueue *vq)
> > +{
> > + u16 last_used, flags;
> > + bool avail, used;
> > +
> > + if (vq->vq.num_free == vq->vring_packed.num)
> > + return false;
> > +
> > + last_used = vq->last_used_idx;
> > + flags = virtio16_to_cpu(vq->vq.vdev,
> > + vq->vring_packed.desc[last_used].flags);
> > + avail = flags & VRING_DESC_F_AVAIL(1);
> > + used = flags & VRING_DESC_F_USED(1);
> > +
> > + return avail == used;
> > +}
>
> This looks interesting, spec said:
>
> "
> Thus VIRTQ_DESC_F_AVAIL and VIRTQ_DESC_F_USED bits are different for an
> available descriptor and
> equal for a used descriptor.
> Note that this observation is mostly useful for sanity-checking as these are
> necessary but not sufficient
> conditions - for example, all descriptors are zero-initialized. To detect
> used and available descriptors it is
> possible for drivers and devices to keep track of the last observed value of
> VIRTQ_DESC_F_USED/VIRTQ_-
> DESC_F_AVAIL. Other techniques to detect
> VIRTQ_DESC_F_AVAIL/VIRTQ_DESC_F_USED bit changes
> might also be possible.
> "
>
> So it looks to me it was not sufficient, looking at the example codes in
> spec, do we need to track last seen used_wrap_counter here?
I don't think we have to track used_wrap_counter in
driver. There was a discussion on this:
https://lists.oasis-open.org/archives/virtio-dev/201802/msg00177.html
And after that, below sentence was added (it's also
in the above words you quoted):
"""
Other techniques to detect
VIRTQ_DESC_F_AVAIL/VIRTQ_DESC_F_USED bit changes
might also be possible.
"""
Best regards,
Tiwei Bie
>
> Thanks
^ permalink raw reply
* Re: [PATCH/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol
From: Simon Horman @ 2018-04-23 9:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: alsa-devel, Kuninori Morimoto, Catalin Marinas, Will Deacon,
Liam Girdwood, Laurent Pinchart, devel, Mauro Carvalho Chehab,
Vinod Koul, Magnus Damm, Russell King, linux-media, Arnd Bergmann,
Mark Brown, Dan Williams, Jaroslav Kysela, linux-arm-kernel,
Sergei Shtylyov, Greg Kroah-Hartman, Takashi Iwai, linux-kernel,
linux-renesas-soc, netdev, dmaengine
In-Reply-To: <1524230914-10175-8-git-send-email-geert+renesas@glider.be>
On Fri, Apr 20, 2018 at 03:28:33PM +0200, Geert Uytterhoeven wrote:
> All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
> platform dependencies. Hence finish the conversion from ARCH_SHMOBILE
> to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
> 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> This depends on the previous patches in this series, hence the RFC.
>
> JFTR, after this, the following symbols for drivers supporting only
> Renesas SuperH "SH-Mobile" SoCs can no longer be selected:
> - CONFIG_KEYBOARD_SH_KEYSC,
> - CONFIG_VIDEO_SH_VOU,
> - CONFIG_VIDEO_SH_MOBILE_CEU,
> - CONFIG_DRM_SHMOBILE[*],
> - CONFIG_FB_SH_MOBILE_MERAM.
> (changes for a shmobile_defconfig .config)
>
> [*] CONFIG_DRM_SHMOBILE has a dependency on ARM, but it was never wired
> up. From the use of sh_mobile_meram, I guess it was meant for
> SH-Mobile AP4 on Mackerel or AP4EVB, which are long gone.
> So the only remaining upstream platforms that could make use of it
> are legacy SuperH SH-Mobile SoCs?
That sounds about right. If there is interest I can sift through my mail
archive and see if it yields any answers.
^ permalink raw reply
* Re: [PATCH bpf-next v3 4/8] bpf: add documentation for eBPF helpers (23-32)
From: Daniel Borkmann @ 2018-04-23 9:11 UTC (permalink / raw)
To: Quentin Monnet, ast; +Cc: netdev, oss-drivers, linux-doc, linux-man
In-Reply-To: <b7ef2bc0-90f7-8bd9-2dd2-3b5ba2a6d4b0@netronome.com>
On 04/20/2018 08:54 PM, Quentin Monnet wrote:
> 2018-04-19 13:16 UTC+0200 ~ Daniel Borkmann <daniel@iogearbox.net>
>> On 04/17/2018 04:34 PM, Quentin Monnet wrote:
>>> Add documentation for eBPF helper functions to bpf.h user header file.
>>> This documentation can be parsed with the Python script provided in
>>> another commit of the patch series, in order to provide a RST document
>>> that can later be converted into a man page.
>>>
>>> The objective is to make the documentation easily understandable and
>>> accessible to all eBPF developers, including beginners.
>>>
>>> This patch contains descriptions for the following helper functions, all
>>> written by Daniel:
>>>
>>> - bpf_get_prandom_u32()
>>> - bpf_get_smp_processor_id()
>>> - bpf_get_cgroup_classid()
>>> - bpf_get_route_realm()
>>> - bpf_skb_load_bytes()
>>> - bpf_csum_diff()
>>> - bpf_skb_get_tunnel_opt()
>>> - bpf_skb_set_tunnel_opt()
>>> - bpf_skb_change_proto()
>>> - bpf_skb_change_type()
>>>
>>> v3:
>>> - bpf_get_prandom_u32(): Fix helper name :(. Add description, including
>>> a note on the internal random state.
>>> - bpf_get_smp_processor_id(): Add description, including a note on the
>>> processor id remaining stable during program run.
>>> - bpf_get_cgroup_classid(): State that CONFIG_CGROUP_NET_CLASSID is
>>> required to use the helper. Add a reference to related documentation.
>>> State that placing a task in net_cls controller disables cgroup-bpf.
>>> - bpf_get_route_realm(): State that CONFIG_CGROUP_NET_CLASSID is
>>> required to use this helper.
>>> - bpf_skb_load_bytes(): Fix comment on current use cases for the helper.
>>>
>>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>>> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
>>> ---
>>> include/uapi/linux/bpf.h | 152 +++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 152 insertions(+)
>>>
>>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>>> index c59bf5b28164..d748f65a8f58 100644
>>> --- a/include/uapi/linux/bpf.h
>>> +++ b/include/uapi/linux/bpf.h
>
> [...]
>
>>> @@ -615,6 +632,27 @@ union bpf_attr {
>>> * Return
>>> * 0 on success, or a negative error in case of failure.
>>> *
>>> + * u32 bpf_get_cgroup_classid(struct sk_buff *skb)
>>> + * Description
>>> + * Retrieve the classid for the current task, i.e. for the
>>> + * net_cls (network classifier) cgroup to which *skb* belongs.
>>> + *
>>> + * This helper is only available is the kernel was compiled with
>>> + * the **CONFIG_CGROUP_NET_CLASSID** configuration option set to
>>> + * "**y**" or to "**m**".
>>> + *
>>> + * Note that placing a task into the net_cls controller completely
>>> + * disables the execution of eBPF programs with the cgroup.
>>
>> I'm not sure I follow the above sentence, what do you mean by that?
>
> Please see comment below.
>
>> I would definitely also add here that this helper is limited to cgroups v1
>> only, and that it works on clsact TC egress hook but not the ingress one.
>>
>>> + * Also note that, in the above description, the "network
>>> + * classifier" cgroup does not designate a generic classifier, but
>>> + * a particular mechanism that provides an interface to tag
>>> + * network packets with a specific class identifier. See also the
>>
>> The "generic classifier" part is a bit strange to parse. I would probably
>> leave the first part out and explain that this provides a means to tag
>> packets based on a user-provided ID for all traffic coming from the tasks
>> belonging to the related cgroup.
>
> In this paragraph and in the one above, I am trying to address Alexei
> comments to the RFC v2:
>
> please add that kernel should be configured with
> CONFIG_NET_CLS_CGROUP=y|m
> and mention Documentation/cgroup-v1/net_cls.txt
> Otherwise 'network classifier' is way too generic.
> I'd also mention that placing a task into net_cls controller
> disables all of cgroup-bpf.
>
> But I must admit I am struggling a bit on this helper. If I understand
> correctly, "network classifier" is too generic and could be confused
> with TC classifiers? Hence the attempt to avoid that in the second
I think if you just name it "net_cls cgroup" it should be good enough in case
the concern is that "network classifier" name would be misunderstood.
> paragraph... As for "placing a task into net_cls controller disables all
> of cgroup-bpf", again if I understand correctly, I think it refers to
> cgroup_sk_alloc_disable() being called in write_classid() in file
> net/core/netclassid_cgroup.c. But I am not familiar with it and cannot
> find a nice way to explain that in the doc :/.
Point here should be that there's cgroups v1 and v2 infra. Both are available
and you can use a mixture of them, but net_cls is v1 only whereas bpf progs on
cgroups is v2 only feature. And if you look at struct sock_cgroup_data, it's
a union for the socket, so you can only use one of them with regards to sockets.
>>> + * related kernel documentation, available from the Linux sources
>>> + * in file *Documentation/cgroup-v1/net_cls.txt*.
>>> + * Return
>>> + * The classid, or 0 for the default unconfigured classid.
>>> + *
>>> * int bpf_skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
>>> * Description
>>> * Push a *vlan_tci* (VLAN tag control information) of protocol
>>> @@ -734,6 +772,16 @@ union bpf_attr {
>>> * are **TC_ACT_REDIRECT** on success or **TC_ACT_SHOT** on
>>> * error.
>>> *
>>> + * u32 bpf_get_route_realm(struct sk_buff *skb)
>>> + * Description
>>> + * Retrieve the realm or the route, that is to say the
>>> + * **tclassid** field of the destination for the *skb*. This
>>> + * helper is available only if the kernel was compiled with
>>> + * **CONFIG_IP_ROUTE_CLASSID** configuration option.
>>
>> Could mention that this is a similar user provided tag like in the net_cls
>> case with cgroups only that this applies to routes here (dst entries) which
>> hold this tag.
>>
>> Also, should say that this works with clsact TC egress hook or alternatively
>> conventional classful egress qdiscs, but not on TC ingress. In case of clsact
>> TC egress hook this has the advantage that the dst entry has not been dropped
>> yet in the xmit path. Therefore, the dst entry does not need to be artificially
>> held via netif_keep_dst() for a classful qdisc until the skb is freed.
>
> Here I am not sure to follow, the advantage is for clsact, but this is
> only for a classful qdisc that we can avoid holding the dst entry? How
No, it's only for sch_clsact where we don't need to hold it. Take a look at
__dev_queue_xmit(), and where sch_handle_egress() is called. It's right before
the dev->priv_flags & IFF_XMIT_DST_RELEASE check where we either hold or drop
the dst from skb.
In cls_bpf_prog_from_efd() the tcf_block_netif_keep_dst() will handle this.
If you call cls_bpf e.g. out of htb via htb_classify() -> tcf_classify()
then you would have to hold it and thus call netif_keep_dst() so that the
test in __dev_queue_xmit() results in holding the dst via skb_dst_force().
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH] iptables: Per-net ns lock
From: Kirill Tkhai @ 2018-04-23 9:03 UTC (permalink / raw)
To: Andrei Vagin; +Cc: fw, netdev, pablo, rstoyanov1, ptikhomirov
In-Reply-To: <20180420230620.GA23540@outlook.office365.com>
On 21.04.2018 02:06, Andrei Vagin wrote:
> On Fri, Apr 20, 2018 at 04:42:47PM +0300, Kirill Tkhai wrote:
>> Containers want to restore their own net ns,
>> while they may have no their own mnt ns.
>> This case they share host's /run/xtables.lock
>> file, but they may not have permission to open
>> it.
>>
>> Patch makes /run/xtables.lock to be per-namespace,
>> i.e., to refer to the caller task's net ns.
>>
>> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
>> ---
>> iptables/xshared.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/iptables/xshared.c b/iptables/xshared.c
>> index 06db72d4..b6dbe4e7 100644
>> --- a/iptables/xshared.c
>> +++ b/iptables/xshared.c
>> @@ -254,7 +254,12 @@ static int xtables_lock(int wait, struct timeval *wait_interval)
>> time_left.tv_sec = wait;
>> time_left.tv_usec = 0;
>>
>> - fd = open(XT_LOCK_NAME, O_CREAT, 0600);
>> + if (symlink("/proc/self/ns/net", XT_LOCK_NAME) != 0 &&
>
> Any user can open this file and take the lock. Before this patch, the
> lock file could be opened only by the root user. It means that any user
> will be able to block all iptables operations. Do I miss something?
Yes, this is the idea. It looks like the only way to save compatibility
with old iptables and to allow to set rules from nested net namespaces.
Also, this allows to synchronize with containers, which have its own mount
namespace.
Comparing to existing interfaces in kernel, there is an example. Ordinary user
can open a file RO on a partition, and this prevents root from umounting it
But this is never considered as a problem, and nobody makes partitions available
only for root in 0600 mode to prevent this. There is lsof, and it's easy to find
the lock owner. The same with iptables. The lock is not a critical protection,
it's just a try for different users to synchronize between each other. Real protection
happens in setsockopt() path.
> [root@fc24 ~]# ln -s /proc/self/ns/net /run/xtables.lock2
> [root@fc24 ~]# ls -l /run/xtables.lock2
> lrwxrwxrwx 1 root root 17 Apr 21 01:52 /run/xtables.lock2 ->
> /proc/self/ns/net
> [root@fc24 ~]# ls -l /proc/self/ns/net
> lrwxrwxrwx 1 root root 0 Apr 21 01:52 /proc/self/ns/net ->
> net:[4026531993]
>
> Thanks,
> Andrei
>
>> + errno != EEXIST) {
>> + fprintf(stderr, "Fatal: can't create lock file\n");
>
> fprintf(stderr, "Fatal: can't create lock file %s: %s\n",
> XT_LOCK_NAME, strerror(errno));
>
>> + return XT_LOCK_FAILED;
>> + }
>> + fd = open(XT_LOCK_NAME, O_RDONLY);
>> if (fd < 0) {
>> fprintf(stderr, "Fatal: can't open lock file %s: %s\n",
>> XT_LOCK_NAME, strerror(errno));
Kirill
^ permalink raw reply
* Re: Page allocator bottleneck
From: Tariq Toukan @ 2018-04-23 8:54 UTC (permalink / raw)
To: Aaron Lu
Cc: Linux Kernel Network Developers, linux-mm, Mel Gorman,
David Miller, Jesper Dangaard Brouer, Eric Dumazet,
Alexei Starovoitov, Saeed Mahameed, Eran Ben Elisha,
Andrew Morton, Michal Hocko
In-Reply-To: <127df719-b978-60b7-5d77-3c8efbf2ecff@mellanox.com>
On 22/04/2018 7:43 PM, Tariq Toukan wrote:
>
>
> On 21/04/2018 11:15 AM, Aaron Lu wrote:
>> Sorry to bring up an old thread...
>>
>
> I want to thank you very much for bringing this up!
>
>> On Thu, Nov 02, 2017 at 07:21:09PM +0200, Tariq Toukan wrote:
>>>
>>>
>>> On 18/09/2017 12:16 PM, Tariq Toukan wrote:
>>>>
>>>>
>>>> On 15/09/2017 1:23 PM, Mel Gorman wrote:
>>>>> On Thu, Sep 14, 2017 at 07:49:31PM +0300, Tariq Toukan wrote:
>>>>>> Insights: Major degradation between #1 and #2, not getting any
>>>>>> close to linerate! Degradation is fixed between #2 and #3. This is
>>>>>> because page allocator cannot stand the higher allocation rate. In
>>>>>> #2, we also see that the addition of rings (cores) reduces BW (!!),
>>>>>> as result of increasing congestion over shared resources.
>>>>>>
>>>>>
>>>>> Unfortunately, no surprises there.
>>>>>
>>>>>> Congestion in this case is very clear. When monitored in perf
>>>>>> top: 85.58% [kernel] [k] queued_spin_lock_slowpath
>>>>>>
>>>>>
>>>>> While it's not proven, the most likely candidate is the zone lock
>>>>> and that should be confirmed using a call-graph profile. If so, then
>>>>> the suggestion to tune to the size of the per-cpu allocator would
>>>>> mitigate the problem.
>>>>>
>>>> Indeed, I tuned the per-cpu allocator and bottleneck is released.
>>>>
>>>
>>> Hi all,
>>>
>>> After leaving this task for a while doing other tasks, I got back to
>>> it now
>>> and see that the good behavior I observed earlier was not stable.
>>
>> I posted a patchset to improve zone->lock contention for order-0 pages
>> recently, it can almost eliminate 80% zone->lock contention for
>> will-it-scale/page_fault1 testcase when tested on a 2 sockets Intel
>> Skylake server and it doesn't require PCP size tune, so should have
>> some effects on your workload where one CPU does allocation while
>> another does free.
>>
>
> That is great news. In our driver's memory scheme (and many others as
> well) we allocate only order-0 pages (the only flow that does not do
> that yet in upstream will do so very soon, we already have the patches
> in our internal branch).
> Allocation of order-0 pages is not only the common case, but is the only
> type of allocation in our data-path. Let's optimize it!
>
>
>> It did this by some disruptive changes:
>> 1 on free path, it skipped doing merge(so could be bad for mixed
>> workloads where both 4K and high order pages are needed);
>
> I think there are so many advantages to not using high order
> allocations, especially in production servers that are not rebooted for
> long periods and become fragmented.
> AFAIK, the community direction (at least in networking) is using order-0
> pages in datapath, so optimizing their allocaiton is a very good idea.
> Need of course to perf evaluate possible degradations, and see how
> important these use cases are.
>
>> 2 on allocation path, it avoided touching multiple cachelines.
>>
>
> Great!
>
>> RFC v2 patchset:
>> https://lkml.org/lkml/2018/3/20/171
>>
>> repo:
>> https://github.com/aaronlu/linux zone_lock_rfc_v2
>>
>
> I will check them out first thing tomorrow!
>
> p.s., I will be on vacation for a week starting Tuesday.
> I hope I can make some progress before that :)
>
> Thanks,
> Tariq
>
Hi,
I ran my tests with your patches.
Initial BW numbers are significantly higher than I documented back then
in this mail-thread.
For example, in driver #2 (see original mail thread), with 6 rings, I
now get 92Gbps (slightly less than linerate) in comparison to 64Gbps
back then.
However, there were many kernel changes since then, I need to isolate
your changes. I am not sure I can finish this today, but I will surely
get to it next week after I'm back from vacation.
Still, when I increase the scale (more rings, i.e. more cpus), I see
that queued_spin_lock_slowpath gets to 60%+ cpu. Still high, but lower
than it used to be.
This should be root solved by the (orthogonal) changes planned in
network subsystem, which will change the SKB allocation/free scheme so
that SKBs are released on the originating cpu.
Thanks,
Tariq
>>> Recall: I work with a modified driver that allocates a page (4K) per
>>> packet
>>> (MTU=1500), in order to simulate the stress on page-allocator in 200Gbps
>>> NICs.
>>>
>>> Performance is good as long as pages are available in the allocating
>>> cores's
>>> PCP.
>>> Issue is that pages are allocated in one core, then free'd in another,
>>> making it's hard for the PCP to work efficiently, and both the allocator
>>> core and the freeing core need to access the buddy allocator very often.
>>>
>>> I'd like to share with you some testing numbers:
>>>
>>> Test: ./super_netperf 128 -H 24.134.0.51 -l 1000
>>>
>>> 100% cpu on all cores, top func in perf:
>>> 84.98% [kernel] [k] queued_spin_lock_slowpath
>>>
>>> system wide (all cores)
>>> 1135941 kmem:mm_page_alloc
>>>
>>> 2606629 kmem:mm_page_free
>>>
>>> 0 kmem:mm_page_alloc_extfrag
>>> 4784616 kmem:mm_page_alloc_zone_locked
>>>
>>> 1337 kmem:mm_page_free_batched
>>>
>>> 6488213 kmem:mm_page_pcpu_drain
>>>
>>> 8925503 net:napi_gro_receive_entry
>>>
>>>
>>> Two types of cores:
>>> A core mostly running napi (8 such cores):
>>> 221875 kmem:mm_page_alloc
>>>
>>> 17100 kmem:mm_page_free
>>>
>>> 0 kmem:mm_page_alloc_extfrag
>>> 766584 kmem:mm_page_alloc_zone_locked
>>>
>>> 16 kmem:mm_page_free_batched
>>>
>>> 35 kmem:mm_page_pcpu_drain
>>>
>>> 1340139 net:napi_gro_receive_entry
>>>
>>>
>>> Other core, mostly running user application (40 such):
>>> 2 kmem:mm_page_alloc
>>>
>>> 38922 kmem:mm_page_free
>>>
>>> 0 kmem:mm_page_alloc_extfrag
>>> 1 kmem:mm_page_alloc_zone_locked
>>>
>>> 8 kmem:mm_page_free_batched
>>>
>>> 107289 kmem:mm_page_pcpu_drain
>>>
>>> 34 net:napi_gro_receive_entry
>>>
>>>
>>> As you can see, sync overhead is enormous.
>>>
>>> PCP-wise, a key improvement in such scenarios would be reached if we
>>> could
>>> (1) keep and handle the allocated page on same cpu, or (2) somehow
>>> get the
>>> page back to the allocating core's PCP in a fast-path, without going
>>> through
>>> the regular buddy allocator paths.
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: implement and use per cpu rx skbs cache
From: Jesper Dangaard Brouer @ 2018-04-23 8:52 UTC (permalink / raw)
To: Paolo Abeni
Cc: Eric Dumazet, Willem de Bruijn, netdev, David S. Miller,
Tariq Toukan, brouer
In-Reply-To: <1524396178.10317.18.camel@redhat.com>
On Sun, 22 Apr 2018 13:22:58 +0200
Paolo Abeni <pabeni@redhat.com> wrote:
> On Fri, 2018-04-20 at 15:48 +0200, Jesper Dangaard Brouer wrote:
> > On Thu, 19 Apr 2018 06:47:10 -0700 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > On 04/19/2018 12:40 AM, Paolo Abeni wrote:
> > > > On Wed, 2018-04-18 at 12:21 -0700, Eric Dumazet wrote:
> > > > > On 04/18/2018 10:15 AM, Paolo Abeni wrote:
> >
> > [...]
> > > >
> > > > Any suggestions for better results are more than welcome!
> > >
> > > Yes, remote skb freeing. I mentioned this idea to Jesper and Tariq in
> > > Seoul (netdev conference). Not tied to UDP, but a generic solution.
> >
> > Yes, I remember. I think... was it the idea, where you basically
> > wanted to queue back SKBs to the CPU that allocated them, right?
> >
> > Freeing an SKB on the same CPU that allocated it, have multiple
> > advantages. (1) the SLUB allocator can use a non-atomic
> > "cpu-local" (double)cmpxchg. (2) the 4 cache-lines memset cleared of
> > the SKB stay local. (3) the atomic SKB refcnt/users stay local.
>
> By the time the skb is returned to the ingress cpu, isn't that skb most
> probably out of the cache?
This is a too simplistic view. You have to look at the cache
coherence state[1] of the individual cache lines (SKB consist of 4
cache-lines). And newer Intel CPUs [2] can "Forward(F)" cache-lines
between caches. The SKB cache-line that have atomic refcnt/users
important to analyze (Read For Ownership (RFO) case). Analyzing the
other cache-lines is actually more complicated due to techniques like
"Store Buffer" and "Invalidate Queues".
[1] https://en.wikipedia.org/wiki/MESI_protocol
[2] https://en.wikipedia.org/wiki/MESIF_protocol
There is also a lot of detail in point (1) about how the SLUB
alloactor works internally, and how it avoids bouncing the struct-page
cache-line. Some of the performance benefit from you current patch
also comes from this...
> > We just have to avoid that queue back SKB's mechanism, doesn't cost
> > more than the operations we expect to save. Bulk transfer is an
> > obvious approach. For storing SKBs until they are returned, we already
> > have a fast mechanism see napi_consume_skb calling _kfree_skb_defer,
> > which SLUB/SLAB-bulk free to amortize cost (1).
> >
> > I guess, the missing information is that we don't know what CPU the SKB
> > were created on...
> >
> > Where to store this CPU info?
> >
> > (a) In struct sk_buff, in a cache-line that is already read on remote
> > CPU in UDP code?
> >
> > (b) In struct page, as SLUB alloc hand-out objects/SKBs on a per page
> > basis, we could have SLUB store a hint about the CPU it was allocated
> > on, and bet on returning to that CPU ? (might be bad to read the
> > struct-page cache-line)
>
> Bulking would be doable only for connected sockets, elsewhere would be
> difficult to assemble a burst long enough to amortize the handshake
> with the remote CPU (spinlock + ipi needed ?!?)
We obviously need some level of bulking.
I would likely try to avoid any explicit IPI calls, but instead use a
queue like the ptr_ring queue, because it have good separation between
cache-lines used by consumer and producer (but it might be overkill
for this use-case).
> Would be good enough for unconnected sockets sending a whole skb burst
> back to one of the (several) ingress CPU? e.g. peeking the CPU
> associated with the first skb inside the burst, we would somewhat
> balance the load between the ingress CPUs.
See, Willem de Bruijn suggestions...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net] team: check team dev npinfo when adding a port only
From: Xin Long @ 2018-04-23 8:46 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, network dev, davem, Jiri Pirko, stephen hemminger
In-Reply-To: <CADvbK_esxb+WG-ute1nNwDVkMrKargxCt1_HeQZv8D4CLskVsA@mail.gmail.com>
On Mon, Apr 23, 2018 at 1:40 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Mon, Apr 23, 2018 at 12:20 PM, kbuild test robot <lkp@intel.com> wrote:
>> Hi Xin,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on net/master]
>>
>> url: https://github.com/0day-ci/linux/commits/Xin-Long/team-check-team-dev-npinfo-when-adding-a-port-only/20180423-114310
>> config: i386-randconfig-x071-201816 (attached as .config)
>> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=i386
>>
>> All errors (new ones prefixed by >>):
>>
>> drivers/net/team/team.c: In function 'team_port_add':
>>>> drivers/net/team/team.c:1221:15: error: 'struct net_device' has no member named 'npinfo'
>> if (team->dev->npinfo) {
>> ^~
> Oops, this is different from bonding, we probably should
> just revert 0fb52a27a04a ("team: cleanup netpoll clode")
> for this fix.
or do the same as bridge netpoll does.
+static int team_port_enable_netpoll(struct team *team, struct team_port *port)
+{
+ if (!team->dev->npinfo)
+ return 0;
+
+ return __team_port_enable_netpoll(port);
+}
which looks better.
^ permalink raw reply
* Re: [PATCH 09/15] net: irda: pxaficp_ir: remove the dmaengine compat need
From: Greg Kroah-Hartman @ 2018-04-23 8:37 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Ulf Hansson, alsa-devel, Takashi Iwai, linux-ide, Pravin Shedge,
linux-mtd, devel, Boris Brezillon, Mauro Carvalho Chehab,
Vinod Koul, Richard Weinberger, Marek Vasut, Ezequiel Garcia,
linux-media, Samuel Ortiz, Arnd Bergmann,
Bartlomiej Zolnierkiewicz, Haojian Zhuang, dmaengine, Mark Brown,
Jaroslav Kysela, linux-arm-kernel, Nicolas Pitre, netdev,
linux-mmc
In-Reply-To: <20180402142656.26815-10-robert.jarzmik@free.fr>
On Mon, Apr 02, 2018 at 04:26:50PM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
>
> This patch simplifies the dma resource acquisition, using the more
> generic function dma_request_slave_channel().
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> drivers/staging/irda/drivers/pxaficp_ir.c | 14 ++------------
> 1 file changed, 2 insertions(+), 12 deletions(-)
This file is no longer in Linus's tree :)
thanks,
greg k-h
^ permalink raw reply
* KMSAN: uninit-value in pppoe_connect
From: syzbot @ 2018-04-23 8:24 UTC (permalink / raw)
To: linux-kernel, mostrows, netdev, syzkaller-bugs
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +0000)
kmsan: disable assembly checksums
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=4f03bdf92fdf9ef5ddab
So far this crash happened 2 times on
https://github.com/google/kmsan.git/master.
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5233317381144576
Kernel config: https://syzkaller.appspot.com/x/.config?id=328654897048964367
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4f03bdf92fdf9ef5ddab@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
==================================================================
BUG: KMSAN: uninit-value in pppoe_connect+0xe9a/0x2360
drivers/net/ppp/pppoe.c:662
CPU: 1 PID: 8338 Comm: syz-executor2 Not tainted 4.16.0+ #85
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
pppoe_connect+0xe9a/0x2360 drivers/net/ppp/pppoe.c:662
SYSC_connect+0x41a/0x510 net/socket.c:1639
SyS_connect+0x54/0x80 net/socket.c:1620
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x455389
RSP: 002b:00007f5c253ecc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007f5c253ed6d4 RCX: 0000000000455389
RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000063 R14: 00000000006f39e8 R15: 0000000000000000
Local variable description: ----address@SYSC_connect
Variable was created at:
SYSC_connect+0x6f/0x510 net/socket.c:1622
SyS_connect+0x54/0x80 net/socket.c:1620
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* WARNING: suspicious RCU usage in rt6_check_expired
From: syzbot @ 2018-04-23 8:24 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot hit the following crash on net-next commit
0638eb573cde5888c0886c7f35da604e5db209a6 (Sat Apr 21 20:06:14 2018 +0000)
Merge branch 'ipv6-Another-followup-to-the-fib6_info-change'
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=2422c9e35796659d2273
So far this crash happened 3 times on net-next.
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6081013801287680
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-8412024688694752032
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2422c9e35796659d2273@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
netlink: 'syz-executor4': attribute type 6 has an invalid length.
netlink: 'syz-executor4': attribute type 1 has an invalid length.
netlink: 'syz-executor4': attribute type 6 has an invalid length.
=============================
WARNING: suspicious RCU usage
4.16.0+ #11 Not tainted
-----------------------------
net/ipv6/route.c:410 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by syz-executor7/25958:
#0: 00000000d1963139 (sk_lock-AF_INET6){+.+.}, at: lock_sock
include/net/sock.h:1469 [inline]
#0: 00000000d1963139 (sk_lock-AF_INET6){+.+.}, at:
sock_setsockopt+0x19c/0x1fe0 net/core/sock.c:717
stack backtrace:
CPU: 1 PID: 25958 Comm: syz-executor7 Not tainted 4.16.0+ #11
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+0x1b9/0x294 lib/dump_stack.c:113
lockdep_rcu_suspicious+0x14a/0x153 kernel/locking/lockdep.c:4592
rt6_check_expired+0x38b/0x3e0 net/ipv6/route.c:410
ip6_negative_advice+0x67/0xc0 net/ipv6/route.c:2204
dst_negative_advice include/net/sock.h:1786 [inline]
sock_setsockopt+0x138f/0x1fe0 net/core/sock.c:1051
__sys_setsockopt+0x2df/0x390 net/socket.c:1899
SYSC_setsockopt net/socket.c:1914 [inline]
SyS_setsockopt+0x34/0x50 net/socket.c:1911
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x455389
RSP: 002b:00007f7556e30c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007f7556e316d4 RCX: 0000000000455389
RDX: 0000000000000035 RSI: 0000000000000001 RDI: 0000000000000013
RBP: 000000000072bf58 R08: 0000000000000004 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000005ff R14: 00000000006fc088 R15: 0000000000000001
netlink: 'syz-executor4': attribute type 4 has an invalid length.
netlink: 'syz-executor4': attribute type 4 has an invalid length.
IPVS: set_ctl: invalid protocol: 59 127.0.0.1:20000 lc
IPVS: set_ctl: invalid protocol: 127 224.0.0.1:20000 rr
IPVS: sync thread started: state = BACKUP, mcast_ifn = ip6tnl0, syncid = 4,
id = 0
IPVS: set_ctl: invalid protocol: 127 224.0.0.1:20000 rr
netlink: 72 bytes leftover after parsing attributes in process
`syz-executor2'.
netlink: 72 bytes leftover after parsing attributes in process
`syz-executor2'.
dccp_xmit_packet: Payload too large (65423) for featneg.
IPVS: set_ctl: invalid protocol: 29 1.0.0.0:2 wlc
IPVS: set_ctl: invalid protocol: 29 1.0.0.0:2 wlc
netlink: 32 bytes leftover after parsing attributes in process
`syz-executor7'.
netlink: 12 bytes leftover after parsing attributes in process
`syz-executor1'.
netlink: 12 bytes leftover after parsing attributes in process
`syz-executor1'.
netlink: 'syz-executor1': attribute type 29 has an invalid length.
netlink: 8 bytes leftover after parsing attributes in process
`syz-executor1'.
IPVS: set_ctl: invalid protocol: 108 224.0.0.1:20004 lblc
netlink: 'syz-executor1': attribute type 29 has an invalid length.
netlink: 8 bytes leftover after parsing attributes in process
`syz-executor1'.
IPVS: set_ctl: invalid protocol: 108 224.0.0.1:20004 lblc
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* KMSAN: uninit-value in pppol2tp_connect
From: syzbot @ 2018-04-23 8:24 UTC (permalink / raw)
To: davem, jchapman, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +0000)
kmsan: disable assembly checksums
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=a70ac890b23b1bf29f5c
So far this crash happened 3 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4946656566968320
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5395971013869568
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5936570024591360
Kernel config: https://syzkaller.appspot.com/x/.config?id=328654897048964367
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a70ac890b23b1bf29f5c@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
==================================================================
BUG: KMSAN: uninit-value in pppol2tp_connect+0x258/0x1c50
net/l2tp/l2tp_ppp.c:622
CPU: 1 PID: 4524 Comm: syzkaller735385 Not tainted 4.16.0+ #85
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
pppol2tp_connect+0x258/0x1c50 net/l2tp/l2tp_ppp.c:622
SYSC_connect+0x41a/0x510 net/socket.c:1639
SyS_connect+0x54/0x80 net/socket.c:1620
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x445559
RSP: 002b:00007f0b96f0ddb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 0000000000445559
RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffec2b0929f R14: 00007f0b96f0e9c0 R15: 0000000000000001
Local variable description: ----address@SYSC_connect
Variable was created at:
SYSC_connect+0x6f/0x510 net/socket.c:1622
SyS_connect+0x54/0x80 net/socket.c:1620
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* KMSAN: uninit-value in strnlen
From: syzbot @ 2018-04-23 8:23 UTC (permalink / raw)
To: linux-kernel, mostrows, netdev, syzkaller-bugs
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +0000)
kmsan: disable assembly checksums
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=cd06c321e7147d03a65e
So far this crash happened 5 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5785171018121216
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5117671628603392
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6310764688179200
Kernel config: https://syzkaller.appspot.com/x/.config?id=328654897048964367
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cd06c321e7147d03a65e@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
==================================================================
BUG: KMSAN: uninit-value in strnlen+0xc4/0x110 lib/string.c:499
CPU: 1 PID: 4507 Comm: syzkaller579712 Not tainted 4.16.0+ #85
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
strnlen+0xc4/0x110 lib/string.c:499
dev_name_hash net/core/dev.c:209 [inline]
dev_get_by_name_rcu net/core/dev.c:764 [inline]
dev_get_by_name+0x6e/0x350 net/core/dev.c:791
pppoe_connect+0xcb7/0x2360 drivers/net/ppp/pppoe.c:665
SYSC_connect+0x41a/0x510 net/socket.c:1639
SyS_connect+0x54/0x80 net/socket.c:1620
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43fcf9
RSP: 002b:00007ffca4bd4978 EFLAGS: 00000213 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fcf9
RDX: 0000000000000007 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401620
R13: 00000000004016b0 R14: 0000000000000000 R15: 0000000000000000
Local variable description: ----address@SYSC_connect
Variable was created at:
SYSC_connect+0x6f/0x510 net/socket.c:1622
SyS_connect+0x54/0x80 net/socket.c:1620
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* KMSAN: uninit-value in ebt_stp_mt_check
From: syzbot @ 2018-04-23 8:23 UTC (permalink / raw)
To: bridge, coreteam, davem, fw, kadlec, linux-kernel, netdev,
netfilter-devel, pablo, stephen, syzkaller-bugs
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +0000)
kmsan: disable assembly checksums
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=5c06e318fc558cc27823
So far this crash happened 3 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5411555638247424
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=6309829995921408
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=4546610964987904
Kernel config: https://syzkaller.appspot.com/x/.config?id=328654897048964367
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5c06e318fc558cc27823@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
==================================================================
BUG: KMSAN: uninit-value in ebt_stp_mt_check+0x248/0x410
net/bridge/netfilter/ebt_stp.c:164
CPU: 0 PID: 4520 Comm: syzkaller565841 Not tainted 4.16.0+ #85
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
ebt_stp_mt_check+0x248/0x410 net/bridge/netfilter/ebt_stp.c:164
xt_check_match+0x1449/0x1660 net/netfilter/x_tables.c:499
ebt_check_match net/bridge/netfilter/ebtables.c:374 [inline]
ebt_check_entry net/bridge/netfilter/ebtables.c:704 [inline]
translate_table+0x3ffd/0x5e10 net/bridge/netfilter/ebtables.c:945
do_replace_finish+0x1258/0x2ea0 net/bridge/netfilter/ebtables.c:1002
do_replace+0x707/0x770 net/bridge/netfilter/ebtables.c:1141
do_ebt_set_ctl+0x2ab/0x3c0 net/bridge/netfilter/ebtables.c:1518
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x476/0x4d0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0x24b/0x2b0 net/ipv4/ip_sockglue.c:1261
dccp_setsockopt+0x1c3/0x1f0 net/dccp/proto.c:576
sock_common_setsockopt+0x136/0x170 net/core/sock.c:2975
SYSC_setsockopt+0x4b8/0x570 net/socket.c:1849
SyS_setsockopt+0x76/0xa0 net/socket.c:1828
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x445d39
RSP: 002b:00007efff4e14da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 0000000000445d39
RDX: 0000000000000080 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000358 R09: 0000000000000000
R10: 00000000200008c0 R11: 0000000000000246 R12: 00000000006dac20
R13: 006567646972625f R14: 6f745f3168746576 R15: 0000000000000002
Local variable description: ----mtpar.i@translate_table
Variable was created at:
translate_table+0xb9/0x5e10 net/bridge/netfilter/ebtables.c:833
do_replace_finish+0x1258/0x2ea0 net/bridge/netfilter/ebtables.c:1002
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: implement and use per cpu rx skbs cache
From: Tariq Toukan @ 2018-04-23 8:13 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Eric Dumazet
Cc: Paolo Abeni, netdev, David S. Miller, Tariq Toukan
In-Reply-To: <20180420154836.3690a39e@redhat.com>
On 20/04/2018 4:48 PM, Jesper Dangaard Brouer wrote:
>
> On Thu, 19 Apr 2018 06:47:10 -0700 Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On 04/19/2018 12:40 AM, Paolo Abeni wrote:
>>> On Wed, 2018-04-18 at 12:21 -0700, Eric Dumazet wrote:
>>>> On 04/18/2018 10:15 AM, Paolo Abeni wrote:
> [...]
>>>
>>> Any suggestions for better results are more than welcome!
>>
>> Yes, remote skb freeing. I mentioned this idea to Jesper and Tariq in
>> Seoul (netdev conference). Not tied to UDP, but a generic solution.
>
> Yes, I remember. I think... was it the idea, where you basically
> wanted to queue back SKBs to the CPU that allocated them, right?
>
> Freeing an SKB on the same CPU that allocated it, have multiple
> advantages. (1) the SLUB allocator can use a non-atomic
> "cpu-local" (double)cmpxchg. (2) the 4 cache-lines memset cleared of
> the SKB stay local. (3) the atomic SKB refcnt/users stay local.
>
> We just have to avoid that queue back SKB's mechanism, doesn't cost
> more than the operations we expect to save. Bulk transfer is an
> obvious approach. For storing SKBs until they are returned, we already
> have a fast mechanism see napi_consume_skb calling _kfree_skb_defer,
> which SLUB/SLAB-bulk free to amortize cost (1).
>
> I guess, the missing information is that we don't know what CPU the SKB
> were created on...
>
> Where to store this CPU info?
>
> (a) In struct sk_buff, in a cache-line that is already read on remote
> CPU in UDP code?
>
> (b) In struct page, as SLUB alloc hand-out objects/SKBs on a per page
> basis, we could have SLUB store a hint about the CPU it was allocated
> on, and bet on returning to that CPU ? (might be bad to read the
> struct-page cache-line)
>
I'm in favor of (a).
Pages of an SKB originates on the same cpu (guaranteed by NAPI).
So a single field in SKB is good for all of its fragments, no need to
read this info from every single page. This also keeps the change local
to the networking subsystem.
Best if we find a hole in struct SKB (for u16?), or union it with a
mutually exclusive field.
Regards,
Tariq
^ permalink raw reply
* Re: [PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS
From: Geert Uytterhoeven @ 2018-04-23 8:08 UTC (permalink / raw)
To: Laurent Pinchart
Cc: ALSA Development Mailing List, Kuninori Morimoto, Catalin Marinas,
Will Deacon, Liam Girdwood, driverdevel, Mauro Carvalho Chehab,
Geert Uytterhoeven, Vinod Koul, Magnus Damm, Russell King,
Linux Media Mailing List, Arnd Bergmann, Mark Brown, Dan Williams,
Linux ARM, Sergei Shtylyov, Greg Kroah-Hartman, Takashi Iwai,
Linux Kernel Mailing List, Linux-
In-Reply-To: <1700954.Qkp7xggMnX@avalon>
Hi Laurent,
On Sun, Apr 22, 2018 at 10:46 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Saturday, 21 April 2018 11:07:11 EEST Laurent Pinchart wrote:
>> On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote:
>> > The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
>> > only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
>> > ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
>> > than the legacy ARCH_SHMOBILE, hence use the former.
>> >
>> > This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
>> > future.
>> >
>> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>
>> How would you like to get this merged ?
>
> Unless you would like to merge the whole series in one go, I'll take this in
> my tree as I have a conflicting patch I would like to submit for v4.18.
Please take it in your tree, thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 6/6] rhashtable: add rhashtable_walk_prev()
From: Herbert Xu @ 2018-04-23 8:07 UTC (permalink / raw)
To: NeilBrown; +Cc: Thomas Graf, netdev, linux-kernel
In-Reply-To: <87bmegqfjc.fsf@notabene.neil.brown.name>
On Thu, Apr 19, 2018 at 09:08:07AM +1000, NeilBrown wrote:
>
> The need is essentially the same as the need for
> rhashtable_walk_peek(). The difference is that the actual behaviour can
> be documented briefly (and so understood easily) without enumerating
> multiple special cases.
> rhashtable_walk_peek() is much the same as
> rhashtable_walk_prev() ?: rhashtable_walk_next()
>
> The need arises when you need to "stop" a walk and then restart at the
> same object, not the next one. i.e. the last object returned before the
> "stop" wasn't acted on.
> This happens with seq_file if the buffer space for ->show() is not
> sufficient to format an object. In the case, seq_file will stop() the
> iteration, make more space available (either by flushing or by
> reallocing) and will start again at the same location.
> If the seq_file client stored the rhashtable_iter in the seq_file
> private data, it can use rhasthable_walk_prev() to recover its position
> if that object is still in the hash table. If it isn't still present,
> rhashtable_walk_next() can be used to get the next one. In some cases
> it can be useful for the client to know whether it got the previous one
> or not.
I see. I'm OK with this provided that you will also remove/convert
users of rhashtable_walk_peek.
I don't think we need two functions that do almost the same thing.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/6] rhashtable: remove incorrect comment on r{hl, hash}table_walk_enter()
From: Herbert Xu @ 2018-04-23 8:06 UTC (permalink / raw)
To: NeilBrown; +Cc: Thomas Graf, netdev, linux-kernel
In-Reply-To: <87d0yqog56.fsf@notabene.neil.brown.name>
On Mon, Apr 23, 2018 at 11:39:17AM +1000, NeilBrown wrote:
>
> Sound fair. Could you Ack the following? Then I'll resend all the
> patches that have an ack.
> I've realised that the "further improve stability of rhashtable_walk"
> patch isn't actually complete, so I'll withdraw that for now.
Looks good to me.
> From e16c037398b6c057787437f3a0aaa7fd44c3bee3 Mon Sep 17 00:00:00 2001
> From: NeilBrown <neilb@suse.com>
> Date: Mon, 16 Apr 2018 11:05:39 +1000
> Subject: [PATCH] rhashtable: Revise incorrect comment on
> r{hl,hash}table_walk_enter()
>
> Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, though
> they do take a spinlock without irq protection.
> So revise the comments to accurately state the contexts in which
> these functions can be called.
>
> Signed-off-by: NeilBrown <neilb@suse.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox