1. 28 May, 2018 8 commits
    • Andrey Ignatov's avatar
      selftests/bpf: Prepare test_sock_addr for extension · 9be71aa6
      Andrey Ignatov authored
      test_sock_addr was not easy to extend since it was focused on sys_bind
      and sys_connect quite a bit.
      
      Reorganized it so that it'll be easier to cover new test-cases for
      `BPF_PROG_TYPE_CGROUP_SOCK_ADDR`:
      
      - decouple test-cases so that only one BPF prog is tested at a time;
      
      - check programmatically that local IP:port for sys_bind, source IP and
        destination IP:port for sys_connect are rewritten property by tested
        BPF programs.
      
      The output of new version:
        # test_sock_addr.sh 2>/dev/null
        Wait for testing IPv4/IPv6 to become available ... OK
        Test case: bind4: load prog with wrong expected attach type .. [PASS]
        Test case: bind4: attach prog with wrong attach type .. [PASS]
        Test case: bind4: rewrite IP & TCP port in .. [PASS]
        Test case: bind4: rewrite IP & UDP port in .. [PASS]
        Test case: bind6: load prog with wrong expected attach type .. [PASS]
        Test case: bind6: attach prog with wrong attach type .. [PASS]
        Test case: bind6: rewrite IP & TCP port in .. [PASS]
        Test case: bind6: rewrite IP & UDP port in .. [PASS]
        Test case: connect4: load prog with wrong expected attach type .. [PASS]
        Test case: connect4: attach prog with wrong attach type .. [PASS]
        Test case: connect4: rewrite IP & TCP port .. [PASS]
        Test case: connect4: rewrite IP & UDP port .. [PASS]
        Test case: connect6: load prog with wrong expected attach type .. [PASS]
        Test case: connect6: attach prog with wrong attach type .. [PASS]
        Test case: connect6: rewrite IP & TCP port .. [PASS]
        Test case: connect6: rewrite IP & UDP port .. [PASS]
        Summary: 16 PASSED, 0 FAILED
      
      (stderr contains errors from libbpf when testing load/attach with
      invalid arguments)
      Signed-off-by: default avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      9be71aa6
    • Andrey Ignatov's avatar
      libbpf: Support guessing sendmsg{4,6} progs · 72481f39
      Andrey Ignatov authored
      libbpf can guess prog type and expected attach type based on section
      name. Add hints for "cgroup/sendmsg4" and "cgroup/sendmsg6" section
      names.
      Signed-off-by: default avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      72481f39
    • Andrey Ignatov's avatar
      bpf: Sync bpf.h to tools/ · 3024cf82
      Andrey Ignatov authored
      Sync new `BPF_CGROUP_UDP4_SENDMSG` and `BPF_CGROUP_UDP6_SENDMSG`
      attach types to tools/.
      Signed-off-by: default avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      3024cf82
    • Andrey Ignatov's avatar
      bpf: Hooks for sys_sendmsg · 1cedee13
      Andrey Ignatov authored
      In addition to already existing BPF hooks for sys_bind and sys_connect,
      the patch provides new hooks for sys_sendmsg.
      
      It leverages existing BPF program type `BPF_PROG_TYPE_CGROUP_SOCK_ADDR`
      that provides access to socket itlself (properties like family, type,
      protocol) and user-passed `struct sockaddr *` so that BPF program can
      override destination IP and port for system calls such as sendto(2) or
      sendmsg(2) and/or assign source IP to the socket.
      
      The hooks are implemented as two new attach types:
      `BPF_CGROUP_UDP4_SENDMSG` and `BPF_CGROUP_UDP6_SENDMSG` for UDPv4 and
      UDPv6 correspondingly.
      
      UDPv4 and UDPv6 separate attach types for same reason as sys_bind and
      sys_connect hooks, i.e. to prevent reading from / writing to e.g.
      user_ip6 fields when user passes sockaddr_in since it'd be out-of-bound.
      
      The difference with already existing hooks is sys_sendmsg are
      implemented only for unconnected UDP.
      
      For TCP it doesn't make sense to change user-provided `struct sockaddr *`
      at sendto(2)/sendmsg(2) time since socket either was already connected
      and has source/destination set or wasn't connected and call to
      sendto(2)/sendmsg(2) would lead to ENOTCONN anyway.
      
      Connected UDP is already handled by sys_connect hooks that can override
      source/destination at connect time and use fast-path later, i.e. these
      hooks don't affect UDP fast-path.
      
      Rewriting source IP is implemented differently than that in sys_connect
      hooks. When sys_sendmsg is used with unconnected UDP it doesn't work to
      just bind socket to desired local IP address since source IP can be set
      on per-packet basis by using ancillary data (cmsg(3)). So no matter if
      socket is bound or not, source IP has to be rewritten on every call to
      sys_sendmsg.
      
      To do so two new fields are added to UAPI `struct bpf_sock_addr`;
      * `msg_src_ip4` to set source IPv4 for UDPv4;
      * `msg_src_ip6` to set source IPv6 for UDPv6.
      Signed-off-by: default avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      1cedee13
    • Andrey Ignatov's avatar
      bpf: Define cgroup_bpf_enabled for CONFIG_CGROUP_BPF=n · 13193b0f
      Andrey Ignatov authored
      Static key is used to enable/disable cgroup-bpf related code paths at
      run time.
      
      Though it's not defined when cgroup-bpf is disabled at compile time,
      i.e. CONFIG_CGROUP_BPF=n, and if some code wants to use it, it has to do
      this:
      
      	#ifdef CONFIG_CGROUP_BPF
      		if (cgroup_bpf_enabled) {
      			/* ... some work ... */
      		}
      	#endif
      
      This code can be simplified by setting cgroup_bpf_enabled to 0 for
      CONFIG_CGROUP_BPF=n case:
      
      	if (cgroup_bpf_enabled) {
      		/* ... some work ... */
      	}
      
      And it aligns well with existing BPF_CGROUP_RUN_PROG_* macros that
      defined for both states of CONFIG_CGROUP_BPF.
      Signed-off-by: default avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      13193b0f
    • Mathieu Xhonneux's avatar
      selftests/bpf: missing headers test_lwt_seg6local · 3b296633
      Mathieu Xhonneux authored
      Previous patch "selftests/bpf: test for seg6local End.BPF action" lacks
      some UAPI headers in tools/.
      
      clang -I. -I./include/uapi -I../../../include/uapi -idirafter
      /usr/local/include -idirafter
      /data/users/yhs/work/llvm/build/install/lib/clang/7.0.0/include
      -idirafter /usr/include -Wno-compare-distinct-pointer-types \
               -O2 -target bpf -emit-llvm -c test_lwt_seg6local.c -o - |      \
      llc -march=bpf -mcpu=generic  -filetype=obj -o
      [...]/net-next/tools/testing/selftests/bpf/test_lwt_seg6local.o
      test_lwt_seg6local.c:4:10: fatal error: 'linux/seg6_local.h' file not found
               ^~~~~~~~~~~~~~~~~~~~
      1 error generated.
      make: Leaving directory
      `/data/users/yhs/work/net-next/tools/testing/selftests/bpf'
      
      v2: moving the headers to tools/include/uapi/.
      Reported-by: default avatarY Song <ys114321@gmail.com>
      Signed-off-by: default avatarMathieu Xhonneux <m.xhonneux@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      3b296633
    • Arnd Bergmann's avatar
      bpf: avoid -Wmaybe-uninitialized warning · dc3b8ae9
      Arnd Bergmann authored
      The stack_map_get_build_id_offset() function is too long for gcc to track
      whether 'work' may or may not be initialized at the end of it, leading
      to a false-positive warning:
      
      kernel/bpf/stackmap.c: In function 'stack_map_get_build_id_offset':
      kernel/bpf/stackmap.c:334:13: error: 'work' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      This removes the 'in_nmi_ctx' flag and uses the state of that variable
      itself to see if it got initialized.
      
      Fixes: bae77c5e ("bpf: enable stackmap with build_id in nmi context")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      dc3b8ae9
    • Arnd Bergmann's avatar
      bpf: btf: avoid -Wreturn-type warning · 53c8036c
      Arnd Bergmann authored
      gcc warns about a noreturn function possibly returning in
      some configurations:
      
      kernel/bpf/btf.c: In function 'env_type_is_resolve_sink':
      kernel/bpf/btf.c:729:1: error: control reaches end of non-void function [-Werror=return-type]
      
      Using BUG() instead of BUG_ON() avoids that warning and otherwise
      does the exact same thing.
      
      Fixes: eb3f595d ("bpf: btf: Validate type reference")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      53c8036c
  2. 27 May, 2018 1 commit
  3. 26 May, 2018 19 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 5b79c2af
      David S. Miller authored
      Lots of easy overlapping changes in the confict
      resolutions here.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b79c2af
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · bc2dbc54
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
       "16 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        kasan: fix memory hotplug during boot
        kasan: free allocated shadow memory on MEM_CANCEL_ONLINE
        checkpatch: fix macro argument precedence test
        init/main.c: include <linux/mem_encrypt.h>
        kernel/sys.c: fix potential Spectre v1 issue
        mm/memory_hotplug: fix leftover use of struct page during hotplug
        proc: fix smaps and meminfo alignment
        mm: do not warn on offline nodes unless the specific node is explicitly requested
        mm, memory_hotplug: make has_unmovable_pages more robust
        mm/kasan: don't vfree() nonexistent vm_area
        MAINTAINERS: change hugetlbfs maintainer and update files
        ipc/shm: fix shmat() nil address after round-down when remapping
        Revert "ipc/shm: Fix shmat mmap nil-page protection"
        idr: fix invalid ptr dereference on item delete
        ocfs2: revert "ocfs2/o2hb: check len for bio_add_page() to avoid getting incorrect bio"
        mm: fix nr_rotate_swap leak in swapon() error case
      bc2dbc54
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 03250e10
      Linus Torvalds authored
      Pull networking fixes from David Miller:
       "Let's begin the holiday weekend with some networking fixes:
      
         1) Whoops need to restrict cfg80211 wiphy names even more to 64
            bytes. From Eric Biggers.
      
         2) Fix flags being ignored when using kernel_connect() with SCTP,
            from Xin Long.
      
         3) Use after free in DCCP, from Alexey Kodanev.
      
         4) Need to check rhltable_init() return value in ipmr code, from Eric
            Dumazet.
      
         5) XDP handling fixes in virtio_net from Jason Wang.
      
         6) Missing RTA_TABLE in rtm_ipv4_policy[], from Roopa Prabhu.
      
         7) Need to use IRQ disabling spinlocks in mlx4_qp_lookup(), from Jack
            Morgenstein.
      
         8) Prevent out-of-bounds speculation using indexes in BPF, from
            Daniel Borkmann.
      
         9) Fix regression added by AF_PACKET link layer cure, from Willem de
            Bruijn.
      
        10) Correct ENIC dma mask, from Govindarajulu Varadarajan.
      
        11) Missing config options for PMTU tests, from Stefano Brivio"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (48 commits)
        ibmvnic: Fix partial success login retries
        selftests/net: Add missing config options for PMTU tests
        mlx4_core: allocate ICM memory in page size chunks
        enic: set DMA mask to 47 bit
        ppp: remove the PPPIOCDETACH ioctl
        ipv4: remove warning in ip_recv_error
        net : sched: cls_api: deal with egdev path only if needed
        vhost: synchronize IOTLB message with dev cleanup
        packet: fix reserve calculation
        net/mlx5: IPSec, Fix a race between concurrent sandbox QP commands
        net/mlx5e: When RXFCS is set, add FCS data into checksum calculation
        bpf: properly enforce index mask to prevent out-of-bounds speculation
        net/mlx4: Fix irq-unsafe spinlock usage
        net: phy: broadcom: Fix bcm_write_exp()
        net: phy: broadcom: Fix auxiliary control register reads
        net: ipv4: add missing RTA_TABLE to rtm_ipv4_policy
        net/mlx4: fix spelling mistake: "Inrerface" -> "Interface" and rephrase message
        ibmvnic: Only do H_EOI for mobility events
        tuntap: correctly set SOCKWQ_ASYNC_NOSPACE
        virtio-net: fix leaking page for gso packet during mergeable XDP
        ...
      03250e10
    • David Hildenbrand's avatar
      kasan: fix memory hotplug during boot · 3f195972
      David Hildenbrand authored
      Using module_init() is wrong.  E.g.  ACPI adds and onlines memory before
      our memory notifier gets registered.
      
      This makes sure that ACPI memory detected during boot up will not result
      in a kernel crash.
      
      Easily reproducible with QEMU, just specify a DIMM when starting up.
      
      Link: http://lkml.kernel.org/r/20180522100756.18478-3-david@redhat.com
      Fixes: 786a8959 ("kasan: disable memory hotplug")
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3f195972
    • David Hildenbrand's avatar
      kasan: free allocated shadow memory on MEM_CANCEL_ONLINE · ed1596f9
      David Hildenbrand authored
      We have to free memory again when we cancel onlining, otherwise a later
      onlining attempt will fail.
      
      Link: http://lkml.kernel.org/r/20180522100756.18478-2-david@redhat.com
      Fixes: fa69b598 ("mm/kasan: add support for memory hotplug")
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ed1596f9
    • Joe Perches's avatar
      checkpatch: fix macro argument precedence test · d41362ed
      Joe Perches authored
      checkpatch's macro argument precedence test is broken so fix it.
      
      Link: http://lkml.kernel.org/r/5dd900e9197febc1995604bb33c23c136d8b33ce.camel@perches.comSigned-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d41362ed
    • Mathieu Malaterre's avatar
      init/main.c: include <linux/mem_encrypt.h> · ae67d58d
      Mathieu Malaterre authored
      In commit c7753208 ("x86, swiotlb: Add memory encryption support") a
      call to function `mem_encrypt_init' was added.  Include prototype
      defined in header <linux/mem_encrypt.h> to prevent a warning reported
      during compilation with W=1:
      
        init/main.c:494:20: warning: no previous prototype for `mem_encrypt_init' [-Wmissing-prototypes]
      
      Link: http://lkml.kernel.org/r/20180522195533.31415-1-malat@debian.orgSigned-off-by: default avatarMathieu Malaterre <malat@debian.org>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Laura Abbott <lauraa@codeaurora.org>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: Gargi Sharma <gs051095@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ae67d58d
    • Gustavo A. R. Silva's avatar
      kernel/sys.c: fix potential Spectre v1 issue · 23d6aef7
      Gustavo A. R. Silva authored
      `resource' can be controlled by user-space, hence leading to a potential
      exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
        kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
        kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
      
      Fix this by sanitizing *resource* before using it to index
      current->signal->rlim
      
      Notice that given that speculation windows are large, the policy is to
      kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
      
      Link: http://lkml.kernel.org/r/20180515030038.GA11822@embeddedor.comSigned-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      23d6aef7
    • Jonathan Cameron's avatar
      mm/memory_hotplug: fix leftover use of struct page during hotplug · a2155861
      Jonathan Cameron authored
      The case of a new numa node got missed in avoiding using the node info
      from page_struct during hotplug.  In this path we have a call to
      register_mem_sect_under_node (which allows us to specify it is hotplug
      so don't change the node), via link_mem_sections which unfortunately
      does not.
      
      Fix is to pass check_nid through link_mem_sections as well and disable
      it in the new numa node path.
      
      Note the bug only 'sometimes' manifests depending on what happens to be
      in the struct page structures - there are lots of them and it only needs
      to match one of them.
      
      The result of the bug is that (with a new memory only node) we never
      successfully call register_mem_sect_under_node so don't get the memory
      associated with the node in sysfs and meminfo for the node doesn't
      report it.
      
      It came up whilst testing some arm64 hotplug patches, but appears to be
      universal.  Whilst I'm triggering it by removing then reinserting memory
      to a node with no other elements (thus making the node disappear then
      appear again), it appears it would happen on hotplugging memory where
      there was none before and it doesn't seem to be related the arm64
      patches.
      
      These patches call __add_pages (where most of the issue was fixed by
      Pavel's patch).  If there is a node at the time of the __add_pages call
      then all is well as it calls register_mem_sect_under_node from there
      with check_nid set to false.  Without a node that function returns
      having not done the sysfs related stuff as there is no node to use.
      This is expected but it is the resulting path that fails...
      
      Exact path to the problem is as follows:
      
       mm/memory_hotplug.c: add_memory_resource()
      
         The node is not online so we enter the 'if (new_node)' twice, on the
         second such block there is a call to link_mem_sections which calls
         into
      
        drivers/node.c: link_mem_sections() which calls
      
        drivers/node.c: register_mem_sect_under_node() which calls
           get_nid_for_pfn and keeps trying until the output of that matches
           the expected node (passed all the way down from
           add_memory_resource)
      
      It is effectively the same fix as the one referred to in the fixes tag
      just in the code path for a new node where the comments point out we
      have to rerun the link creation because it will have failed in
      register_new_memory (as there was no node at the time).  (actually that
      comment is wrong now as we don't have register_new_memory any more it
      got renamed to hotplug_memory_register in Pavel's patch).
      
      Link: http://lkml.kernel.org/r/20180504085311.1240-1-Jonathan.Cameron@huawei.com
      Fixes: fc44f7f9 ("mm/memory_hotplug: don't read nid from struct page during hotplug")
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Reviewed-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a2155861
    • Hugh Dickins's avatar
      proc: fix smaps and meminfo alignment · 6c04ab0e
      Hugh Dickins authored
      The 4.17-rc /proc/meminfo and /proc/<pid>/smaps look ugly: single-digit
      numbers (commonly 0) are misaligned.
      
      Remove seq_put_decimal_ull_width()'s leftover optimization for single
      digits: it's wrong now that num_to_str() takes care of the width.
      
      Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805241554210.1326@eggly.anvils
      Fixes: d1be35cb ("proc: add seq_put_decimal_ull_width to speed up /proc/pid/smaps")
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Andrei Vagin <avagin@openvz.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6c04ab0e
    • Michal Hocko's avatar
      mm: do not warn on offline nodes unless the specific node is explicitly requested · 8addc2d0
      Michal Hocko authored
      Oscar has noticed that we splat
      
         WARNING: CPU: 0 PID: 64 at ./include/linux/gfp.h:467 vmemmap_alloc_block+0x4e/0xc9
         [...]
         CPU: 0 PID: 64 Comm: kworker/u4:1 Tainted: G        W   E     4.17.0-rc5-next-20180517-1-default+ #66
         Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
         Workqueue: kacpi_hotplug acpi_hotplug_work_fn
         Call Trace:
          vmemmap_populate+0xf2/0x2ae
          sparse_mem_map_populate+0x28/0x35
          sparse_add_one_section+0x4c/0x187
          __add_pages+0xe7/0x1a0
          add_pages+0x16/0x70
          add_memory_resource+0xa3/0x1d0
          add_memory+0xe4/0x110
          acpi_memory_device_add+0x134/0x2e0
          acpi_bus_attach+0xd9/0x190
          acpi_bus_scan+0x37/0x70
          acpi_device_hotplug+0x389/0x4e0
          acpi_hotplug_work_fn+0x1a/0x30
          process_one_work+0x146/0x340
          worker_thread+0x47/0x3e0
          kthread+0xf5/0x130
          ret_from_fork+0x35/0x40
      
      when adding memory to a node that is currently offline.
      
      The VM_WARN_ON is just too loud without a good reason.  In this
      particular case we are doing
      
      	alloc_pages_node(node, GFP_KERNEL|__GFP_RETRY_MAYFAIL|__GFP_NOWARN, order)
      
      so we do not insist on allocating from the given node (it is more a
      hint) so we can fall back to any other populated node and moreover we
      explicitly ask to not warn for the allocation failure.
      
      Soften the warning only to cases when somebody asks for the given node
      explicitly by __GFP_THISNODE.
      
      Link: http://lkml.kernel.org/r/20180523125555.30039-3-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarOscar Salvador <osalvador@techadventures.net>
      Tested-by: default avatarOscar Salvador <osalvador@techadventures.net>
      Reviewed-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8addc2d0
    • Michal Hocko's avatar
      mm, memory_hotplug: make has_unmovable_pages more robust · 15c30bc0
      Michal Hocko authored
      Oscar has reported:
      : Due to an unfortunate setting with movablecore, memblocks containing bootmem
      : memory (pages marked by get_page_bootmem()) ended up marked in zone_movable.
      : So while trying to remove that memory, the system failed in do_migrate_range
      : and __offline_pages never returned.
      :
      : This can be reproduced by running
      : qemu-system-x86_64 -m 6G,slots=8,maxmem=8G -numa node,mem=4096M -numa node,mem=2048M
      : and movablecore=4G kernel command line
      :
      : linux kernel: BIOS-provided physical RAM map:
      : linux kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
      : linux kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
      : linux kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
      : linux kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000bffdffff] usable
      : linux kernel: BIOS-e820: [mem 0x00000000bffe0000-0x00000000bfffffff] reserved
      : linux kernel: BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
      : linux kernel: BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
      : linux kernel: BIOS-e820: [mem 0x0000000100000000-0x00000001bfffffff] usable
      : linux kernel: NX (Execute Disable) protection: active
      : linux kernel: SMBIOS 2.8 present.
      : linux kernel: DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org
      : linux kernel: Hypervisor detected: KVM
      : linux kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
      : linux kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
      : linux kernel: last_pfn = 0x1c0000 max_arch_pfn = 0x400000000
      :
      : linux kernel: SRAT: PXM 0 -> APIC 0x00 -> Node 0
      : linux kernel: SRAT: PXM 1 -> APIC 0x01 -> Node 1
      : linux kernel: ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x0009ffff]
      : linux kernel: ACPI: SRAT: Node 0 PXM 0 [mem 0x00100000-0xbfffffff]
      : linux kernel: ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0x13fffffff]
      : linux kernel: ACPI: SRAT: Node 1 PXM 1 [mem 0x140000000-0x1bfffffff]
      : linux kernel: ACPI: SRAT: Node 0 PXM 0 [mem 0x1c0000000-0x43fffffff] hotplug
      : linux kernel: NUMA: Node 0 [mem 0x00000000-0x0009ffff] + [mem 0x00100000-0xbfffffff] -> [mem 0x0
      : linux kernel: NUMA: Node 0 [mem 0x00000000-0xbfffffff] + [mem 0x100000000-0x13fffffff] -> [mem 0
      : linux kernel: NODE_DATA(0) allocated [mem 0x13ffd6000-0x13fffffff]
      : linux kernel: NODE_DATA(1) allocated [mem 0x1bffd3000-0x1bfffcfff]
      :
      : zoneinfo shows that the zone movable is placed into both numa nodes:
      : Node 0, zone  Movable
      :   pages free     160140
      :         min      1823
      :         low      2278
      :         high     2733
      :         spanned  262144
      :         present  262144
      :         managed  245670
      : Node 1, zone  Movable
      :   pages free     448427
      :         min      3827
      :         low      4783
      :         high     5739
      :         spanned  524288
      :         present  524288
      :         managed  515766
      
      Note how only Node 0 has a hutplugable memory region which would rule it
      out from the early memblock allocations (most likely memmap).  Node1
      will surely contain memmaps on the same node and those would prevent
      offlining to succeed.  So this is arguably a configuration issue.
      Although one could argue that we should be more clever and rule early
      allocations from the zone movable.  This would be correct but probably
      not worth the effort considering what a hack movablecore is.
      
      Anyway, We could do better for those cases though.  We rely on
      start_isolate_page_range resp.  has_unmovable_pages to do their job.
      The first one isolates the whole range to be offlined so that we do not
      allocate from it anymore and the later makes sure we are not stumbling
      over non-migrateable pages.
      
      has_unmovable_pages is overly optimistic, however.  It doesn't check all
      the pages if we are withing zone_movable because we rely that those
      pages will be always migrateable.  As it turns out we are still not
      perfect there.  While bootmem pages in zonemovable sound like a clear
      bug which should be fixed let's remove the optimization for now and warn
      if we encounter unmovable pages in zone_movable in the meantime.  That
      should help for now at least.
      
      Btw.  this wasn't a real problem until commit 72b39cfc ("mm,
      memory_hotplug: do not fail offlining too early") because we used to
      have a small number of retries and then failed.  This turned out to be
      too fragile though.
      
      Link: http://lkml.kernel.org/r/20180523125555.30039-2-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarOscar Salvador <osalvador@techadventures.net>
      Tested-by: default avatarOscar Salvador <osalvador@techadventures.net>
      Reviewed-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      15c30bc0
    • Andrey Ryabinin's avatar
      mm/kasan: don't vfree() nonexistent vm_area · 0f901dcb
      Andrey Ryabinin authored
      KASAN uses different routines to map shadow for hot added memory and
      memory obtained in boot process.  Attempt to offline memory onlined by
      normal boot process leads to this:
      
          Trying to vfree() nonexistent vm area (000000005d3b34b9)
          WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
      
          Call Trace:
           kasan_mem_notifier+0xad/0xb9
           notifier_call_chain+0x166/0x260
           __blocking_notifier_call_chain+0xdb/0x140
           __offline_pages+0x96a/0xb10
           memory_subsys_offline+0x76/0xc0
           device_offline+0xb8/0x120
           store_mem_state+0xfa/0x120
           kernfs_fop_write+0x1d5/0x320
           __vfs_write+0xd4/0x530
           vfs_write+0x105/0x340
           SyS_write+0xb0/0x140
      
      Obviously we can't call vfree() to free memory that wasn't allocated via
      vmalloc().  Use find_vm_area() to see if we can call vfree().
      
      Unfortunately it's a bit tricky to properly unmap and free shadow
      allocated during boot, so we'll have to keep it.  If memory will come
      online again that shadow will be reused.
      
      Matthew asked: how can you call vfree() on something that isn't a
      vmalloc address?
      
        vfree() is able to free any address returned by
        __vmalloc_node_range().  And __vmalloc_node_range() gives you any
        address you ask.  It doesn't have to be an address in [VMALLOC_START,
        VMALLOC_END] range.
      
        That's also how the module_alloc()/module_memfree() works on
        architectures that have designated area for modules.
      
      [aryabinin@virtuozzo.com: improve comments]
        Link: http://lkml.kernel.org/r/dabee6ab-3a7a-51cd-3b86-5468718e0390@virtuozzo.com
      [akpm@linux-foundation.org: fix typos, reflow comment]
      Link: http://lkml.kernel.org/r/20180201163349.8700-1-aryabinin@virtuozzo.com
      Fixes: fa69b598 ("mm/kasan: add support for memory hotplug")
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reported-by: default avatarPaul Menzel <pmenzel+linux-kasan-dev@molgen.mpg.de>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0f901dcb
    • Mike Kravetz's avatar
      MAINTAINERS: change hugetlbfs maintainer and update files · b9ddff9b
      Mike Kravetz authored
      The current hugetlbfs maintainer has not been active for more than a few
      years.  I have been been active in this area for more than two years and
      plan to remain active in the foreseeable future.
      
      Also, update the hugetlbfs entry to include linux-mm mail list and
      additional hugetlbfs related files.  hugetlb.c and hugetlb.h are not
      100% hugetlbfs, but a majority of their content is hugetlbfs related.
      
      Link: http://lkml.kernel.org/r/20180518225236.19079-1-mike.kravetz@oracle.comSigned-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Nadia Yvette Chambers <nyc@holomorphy.com>
      Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b9ddff9b
    • Davidlohr Bueso's avatar
      ipc/shm: fix shmat() nil address after round-down when remapping · 8f89c007
      Davidlohr Bueso authored
      shmat()'s SHM_REMAP option forbids passing a nil address for; this is in
      fact the very first thing we check for.  Andrea reported that for
      SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check,
      but we need to check again if the address was rounded down to nil.  As
      of this patch, such cases will return -EINVAL.
      
      Link: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805Signed-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Reported-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Cc: Joe Lawrence <joe.lawrence@redhat.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8f89c007
    • Davidlohr Bueso's avatar
      Revert "ipc/shm: Fix shmat mmap nil-page protection" · a73ab244
      Davidlohr Bueso authored
      Patch series "ipc/shm: shmat() fixes around nil-page".
      
      These patches fix two issues reported[1] a while back by Joe and Andrea
      around how shmat(2) behaves with nil-page.
      
      The first reverts a commit that it was incorrectly thought that mapping
      nil-page (address=0) was a no no with MAP_FIXED.  This is not the case,
      with the exception of SHM_REMAP; which is address in the second patch.
      
      I chose two patches because it is easier to backport and it explicitly
      reverts bogus behaviour.  Both patches ought to be in -stable and ltp
      testcases need updated (the added testcase around the cve can be
      modified to just test for SHM_RND|SHM_REMAP).
      
      [1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805
      
      This patch (of 2):
      
      Commit 95e91b83 ("ipc/shm: Fix shmat mmap nil-page protection")
      worked on the idea that we should not be mapping as root addr=0 and
      MAP_FIXED.  However, it was reported that this scenario is in fact
      valid, thus making the patch both bogus and breaks userspace as well.
      
      For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem
      initialization[1].
      
      [1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347
      Link: http://lkml.kernel.org/r/20180503203243.15045-2-dave@stgolabs.net
      Fixes: 95e91b83 ("ipc/shm: Fix shmat mmap nil-page protection")
      Signed-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Reported-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Reported-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a73ab244
    • Matthew Wilcox's avatar
      idr: fix invalid ptr dereference on item delete · 7a4deea1
      Matthew Wilcox authored
      If the radix tree underlying the IDR happens to be full and we attempt
      to remove an id which is larger than any id in the IDR, we will call
      __radix_tree_delete() with an uninitialised 'slot' pointer, at which
      point anything could happen.  This was easiest to hit with a single
      entry at id 0 and attempting to remove a non-0 id, but it could have
      happened with 64 entries and attempting to remove an id >= 64.
      
      Roman said:
      
        The syzcaller test boils down to opening /dev/kvm, creating an
        eventfd, and calling a couple of KVM ioctls. None of this requires
        superuser. And the result is dereferencing an uninitialized pointer
        which is likely a crash. The specific path caught by syzbot is via
        KVM_HYPERV_EVENTD ioctl which is new in 4.17. But I guess there are
        other user-triggerable paths, so cc:stable is probably justified.
      
      Matthew added:
      
        We have around 250 calls to idr_remove() in the kernel today. Many of
        them pass an ID which is embedded in the object they're removing, so
        they're safe. Picking a few likely candidates:
      
        drivers/firewire/core-cdev.c looks unsafe; the ID comes from an ioctl.
        drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c is similar
        drivers/atm/nicstar.c could be taken down by a handcrafted packet
      
      Link: http://lkml.kernel.org/r/20180518175025.GD6361@bombadil.infradead.org
      Fixes: 0a835c4f ("Reimplement IDR and IDA using the radix tree")
      Reported-by: <syzbot+35666cba7f0a337e2e79@syzkaller.appspotmail.com>
      Debugged-by: default avatarRoman Kagan <rkagan@virtuozzo.com>
      Signed-off-by: default avatarMatthew Wilcox <mawilcox@microsoft.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7a4deea1
    • Changwei Ge's avatar
      ocfs2: revert "ocfs2/o2hb: check len for bio_add_page() to avoid getting incorrect bio" · 3373de20
      Changwei Ge authored
      This reverts commit ba16ddfb ("ocfs2/o2hb: check len for
      bio_add_page() to avoid getting incorrect bio").
      
      In my testing, this patch introduces a problem that mkfs can't have
      slots more than 16 with 4k block size.
      
      And the original logic is safe actually with the situation it mentions
      so revert this commit.
      
      Attach test log:
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 0, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 1, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 2, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 3, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 4, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 5, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 6, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 7, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 8, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 9, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 10, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 11, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 12, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 13, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 14, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 15, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:463 page 16, vec_len = 4096, vec_start = 0
        (mkfs.ocfs2,27479,2):o2hb_setup_one_bio:471 ERROR: Adding page[16] to bio failed, page ffffea0002d7ed40, len 0, vec_len 4096, vec_start 0,bi_sector 8192
        (mkfs.ocfs2,27479,2):o2hb_read_slots:500 ERROR: status = -5
        (mkfs.ocfs2,27479,2):o2hb_populate_slot_data:1911 ERROR: status = -5
        (mkfs.ocfs2,27479,2):o2hb_region_dev_write:2012 ERROR: status = -5
      
      Link: http://lkml.kernel.org/r/SIXPR06MB0461721F398A5A92FC68C39ED5920@SIXPR06MB0461.apcprd06.prod.outlook.comSigned-off-by: default avatarChangwei Ge <ge.changwei@h3c.com>
      Cc: Jun Piao <piaojun@huawei.com>
      Cc: Yiwen Jiang <jiangyiwen@huawei.com>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3373de20
    • Omar Sandoval's avatar
      mm: fix nr_rotate_swap leak in swapon() error case · 7cbf3192
      Omar Sandoval authored
      If swapon() fails after incrementing nr_rotate_swap, we don't decrement
      it and thus effectively leak it.  Make sure we decrement it if we
      incremented it.
      
      Link: http://lkml.kernel.org/r/b6fe6b879f17fa68eee6cbd876f459f6e5e33495.1526491581.git.osandov@fb.com
      Fixes: 81a0298b ("mm, swap: don't use VMA based swap readahead if HDD is used as swap")
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Reviewed-by: default avatarRik van Riel <riel@surriel.com>
      Reviewed-by: default avatar"Huang, Ying" <ying.huang@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7cbf3192
  4. 25 May, 2018 12 commits
    • Florian Fainelli's avatar
      net: dsa: dsa_loop: Make dynamic debugging helpful · e52cde71
      Florian Fainelli authored
      Remove redundant debug prints from phy_read/write since we can trace those
      calls through trace events. Enhance dynamic debug prints to print arguments
      which helps figuring how what is going on at the driver level with higher level
      configuration interfaces.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e52cde71
    • David S. Miller's avatar
      Merge branch 'ovs-ct-zone' · 910714f1
      David S. Miller authored
      Yi-Hung Wei says:
      
      ====================
      openvswitch: Support conntrack zone limit
      
      Currently, nf_conntrack_max is used to limit the maximum number of
      conntrack entries in the conntrack table for every network namespace.
      For the VMs and containers that reside in the same namespace,
      they share the same conntrack table, and the total # of conntrack entries
      for all the VMs and containers are limited by nf_conntrack_max.  In this
      case, if one of the VM/container abuses the usage the conntrack entries,
      it blocks the others from committing valid conntrack entries into the
      conntrack table.  Even if we can possibly put the VM in different network
      namespace, the current nf_conntrack_max configuration is kind of rigid
      that we cannot limit different VM/container to have different # conntrack
      entries.
      
      To address the aforementioned issue, this patch proposes to have a
      fine-grained mechanism that could further limit the # of conntrack entries
      per-zone.  For example, we can designate different zone to different VM,
      and set conntrack limit to each zone.  By providing this isolation, a
      mis-behaved VM only consumes the conntrack entries in its own zone, and
      it will not influence other well-behaved VMs.  Moreover, the users can
      set various conntrack limit to different zone based on their preference.
      
      The proposed implementation utilizes Netfilter's nf_conncount backend
      to count the number of connections in a particular zone.  If the number of
      connection is above a configured limitation, OVS will return ENOMEM to the
      userspace.  If userspace does not configure the zone limit, the limit
      defaults to zero that is no limitation, which is backward compatible to
      the behavior without this patch.
      
      The first patch defines the conntrack limit netlink definition, and the
      second patch provides the implementation.
      
      v4->v5:
        - Addresses comments from Parvin that include log error msg in
          ovs_ct_limit_init(), handle deletion for default limit, and
          add a common helper for get zone limit.
        - Rebases to master.
      
      v3->v4:
        - Addresses comments from Parvin that include simplify netlink API,
          and remove unncessary RCU lockings.
        - Rebases to master.
      
      v2->v3:
        - Addresses comments from Parvin that include using static keys to check
          if ovs_ct_limit features is used, only check ct_limit when a ct entry
          is unconfirmed, and reports rate limited warning messages when the ct
          limit is reached.
        - Rebases to master.
      
      v1->v2:
        - Fixes commit log typos suggested by Greg.
        - Fixes memory free issue that Julia found.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      910714f1
    • Yi-Hung Wei's avatar
      openvswitch: Support conntrack zone limit · 11efd5cb
      Yi-Hung Wei authored
      Currently, nf_conntrack_max is used to limit the maximum number of
      conntrack entries in the conntrack table for every network namespace.
      For the VMs and containers that reside in the same namespace,
      they share the same conntrack table, and the total # of conntrack entries
      for all the VMs and containers are limited by nf_conntrack_max.  In this
      case, if one of the VM/container abuses the usage the conntrack entries,
      it blocks the others from committing valid conntrack entries into the
      conntrack table.  Even if we can possibly put the VM in different network
      namespace, the current nf_conntrack_max configuration is kind of rigid
      that we cannot limit different VM/container to have different # conntrack
      entries.
      
      To address the aforementioned issue, this patch proposes to have a
      fine-grained mechanism that could further limit the # of conntrack entries
      per-zone.  For example, we can designate different zone to different VM,
      and set conntrack limit to each zone.  By providing this isolation, a
      mis-behaved VM only consumes the conntrack entries in its own zone, and
      it will not influence other well-behaved VMs.  Moreover, the users can
      set various conntrack limit to different zone based on their preference.
      
      The proposed implementation utilizes Netfilter's nf_conncount backend
      to count the number of connections in a particular zone.  If the number of
      connection is above a configured limitation, ovs will return ENOMEM to the
      userspace.  If userspace does not configure the zone limit, the limit
      defaults to zero that is no limitation, which is backward compatible to
      the behavior without this patch.
      
      The following high leve APIs are provided to the userspace:
        - OVS_CT_LIMIT_CMD_SET:
          * set default connection limit for all zones
          * set the connection limit for a particular zone
        - OVS_CT_LIMIT_CMD_DEL:
          * remove the connection limit for a particular zone
        - OVS_CT_LIMIT_CMD_GET:
          * get the default connection limit for all zones
          * get the connection limit for a particular zone
      Signed-off-by: default avatarYi-Hung Wei <yihung.wei@gmail.com>
      Acked-by: default avatarPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      11efd5cb
    • Yi-Hung Wei's avatar
      openvswitch: Add conntrack limit netlink definition · 5972be6b
      Yi-Hung Wei authored
      Define netlink messages and attributes to support user kernel
      communication that uses the conntrack limit feature.
      Signed-off-by: default avatarYi-Hung Wei <yihung.wei@gmail.com>
      Acked-by: default avatarPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5972be6b
    • David S. Miller's avatar
      Merge tag 'mlx5e-updates-2018-05-19' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · d7c52fc8
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5e-updates-2018-05-19
      
      This series contains updates for mlx5e netdevice driver with one subject,
      DSCP to priority mapping, in the first patch Huy adds the needed API in
      dcbnl, the second patch adds the needed mlx5 core capability bits for the
      feature, and all other patches are mlx5e (netdev) only changes to add
      support for the feature.
      
      From: Huy Nguyen
      
      Dscp to priority mapping for Ethernet packet:
      
      These patches enable differentiated services code point (dscp) to
      priority mapping for Ethernet packet. Once this feature is
      enabled, the packet is routed to the corresponding priority based on its
      dscp. User can combine this feature with priority flow control (pfc)
      feature to have priority flow control based on the dscp.
      
      Firmware interface:
      Mellanox firmware provides two control knobs for this feature:
        QPTS register allow changing the trust state between dscp and
        pcp mode. The default is pcp mode. Once in dscp mode, firmware will
        route the packet based on its dscp value if the dscp field exists.
      
        QPDPM register allow mapping a specific dscp (0 to 63) to a
        specific priority (0 to 7). By default, all the dscps are mapped to
        priority zero.
      
      Software interface:
      This feature is controlled via application priority TLV. IEEE
      specification P802.1Qcd/D2.1 defines priority selector id 5 for
      application priority TLV. This APP TLV selector defines DSCP to priority
      map. This APP TLV can be sent by the switch or can be set locally using
      software such as lldptool. In mlx5 drivers, we add the support for net
      dcb's getapp and setapp call back. Mlx5 driver only handles the selector
      id 5 application entry (dscp application priority application entry).
      If user sends multiple dscp to priority APP TLV entries on the same
      dscp, the last sent one will take effect. All the previous sent will be
      deleted.
      
      This attribute combined with pfc attribute allows advanced user to
      fine tune the qos setting for specific priority queue. For example,
      user can give dedicated buffer for one or more priorities or user
      can give large buffer to certain priorities.
      
      The dcb buffer configuration will be controlled by lldptool.
      >> lldptool -T -i eth2 -V BUFFER prio 0,2,5,7,1,2,3,6
            maps priorities 0,1,2,3,4,5,6,7 to receive buffer 0,2,5,7,1,2,3,6
      >> lldptool -T -i eth2 -V BUFFER size 87296,87296,0,87296,0,0,0,0
            sets receive buffer size for buffer 0,1,2,3,4,5,6,7 respectively
      
      After discussion on mailing list with Jakub, Jiri, Ido and John, we agreed to
      choose dcbnl over devlink interface since this feature is intended to set
      port attributes which are governed by the netdev instance of that port, where
      devlink API is more suitable for global ASIC configurations.
      
      The firmware trust state (in QPTS register) is changed based on the
      number of dscp to priority application entries. When the first dscp to
      priority application entry is added by the user, the trust state is
      changed to dscp. When the last dscp to priority application entry is
      deleted by the user, the trust state is changed to pcp.
      
      When the port is in DSCP trust state, the transmit queue is selected
      based on the dscp of the skb.
      
      When the port is in DSCP trust state and vport inline mode is not NONE,
      firmware requires mlx5 driver to copy the IP header to the
      wqe ethernet segment inline header if the skb has it.
      This is done by changing the transmit queue sq's min inline mode to L3.
      Note that the min inline mode of sqs that belong to other features
      such as xdpsq, icosq are not modified.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7c52fc8
    • Bo Chen's avatar
      8139too: Remove unnecessary netif_napi_del() · a4567579
      Bo Chen authored
      The call to free_netdev() in __rtl8139_cleanup_dev() clears the network device
      napi list, and explicit calls to netif_napi_del() are unnecessary.
      Signed-off-by: default avatarBo Chen <chenbo@pdx.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4567579
    • Thomas Falcon's avatar
      ibmvnic: Fix partial success login retries · eb110410
      Thomas Falcon authored
      In its current state, the driver will handle backing device
      login in a loop for a certain number of retries while the
      device returns a partial success, indicating that the driver
      may need to try again using a smaller number of resources.
      
      The variable it checks to continue retrying may change
      over the course of operations, resulting in reallocation
      of resources but exits without sending the login attempt.
      Guard against this by introducing a boolean variable that
      will retain the state indicating that the driver needs to
      reattempt login with backing device firmware.
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb110410
    • David S. Miller's avatar
      Merge branch 'qed-ethtool-rx-flow-classification-enhancements' · a527af9c
      David S. Miller authored
      Manish Chopra says:
      
      ====================
      qed*: ethtool rx flow classification enhancements.
      
      This series re-structures the driver's ethtool rx flow
      classification flow, following that it adds other flow
      profiles and rx flow classification enhancements
      via "ethtool -N/-U"
      
      Please consider applying this to "net-next"
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a527af9c
    • Manish Chopra's avatar
      qed*: Support drop action classification · 608e00d0
      Manish Chopra authored
      With this patch, User can configure for the supported
      flows to be dropped. Added a stat "gft_filter_drop"
      as well to be populated in ethtool for the dropped flows.
      
      For example -
      
      ethtool -N p5p1 flow-type udp4 dst-port 8000 action -1
      ethtool -N p5p1 flow-type tcp4 scr-ip 192.168.8.1 action -1
      Signed-off-by: default avatarManish Chopra <manish.chopra@cavium.com>
      Signed-off-by: default avatarShahed Shaikh <shahed.shaikh@cavium.com>
      Signed-off-by: default avatarAriel Elior <ariel.elior@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      608e00d0
    • Manish Chopra's avatar
      qede: Support flow classification to the VFs. · 39385ab0
      Manish Chopra authored
      With the supported classification modes [4 tuples based,
      udp port based, src-ip based], flows can be classified
      to the VFs as well. With this patch, flows can be re-directed
      to the requested VF provided in "action" field of command.
      
      Please note that driver doesn't really care about the queue bits
      in "action" field for the VFs. Since queue will be still chosen
      by FW using RSS hash. [I.e., the classification would be done
      according to vport-only]
      
      For examples -
      
      ethtool -N p5p1 flow-type udp4 dst-port 8000 action 0x100000000
      ethtool -N p5p1 flow-type tcp4 src-ip 192.16.6.10 action 0x200000000
      ethtool -U p5p1 flow-type tcp4 src-ip 192.168.40.100 dst-ip \
      	192.168.40.200 src-port 6660 dst-port 5550 \
      	action 0x100000000
      Signed-off-by: default avatarManish Chopra <manish.chopra@cavium.com>
      Signed-off-by: default avatarShahed Shaikh <shahed.shaikh@cavium.com>
      Signed-off-by: default avatarAriel Elior <ariel.elior@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      39385ab0
    • Manish Chopra's avatar
      qed*: Support other classification modes. · 3893fc62
      Manish Chopra authored
      Currently, driver supports flow classification to PF
      receive queues based on TCP/UDP 4 tuples [src_ip, dst_ip,
      src_port, dst_port] only.
      
      This patch enables to configure different flow profiles
      [For example - only UDP dest port or src_ip based] on the
      adapter so that classification can be done according to
      just those fields as well. Although, at a time just one
      type of flow configuration is supported due to limited
      number of flow profiles available on the device.
      
      For example -
      
      ethtool -N enp7s0f0 flow-type udp4 dst-port 45762 action 2
      ethtool -N enp7s0f0 flow-type tcp4 src-ip 192.16.4.10 action 1
      ethtool -N enp7s0f0 flow-type udp6 dst-port 45762 action 3
      Signed-off-by: default avatarManish Chopra <manish.chopra@cavium.com>
      Signed-off-by: default avatarShahed Shaikh <shahed.shaikh@cavium.com>
      Signed-off-by: default avatarAriel Elior <ariel.elior@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3893fc62
    • Manish Chopra's avatar
      qede: Validate unsupported configurations · 89ffd14e
      Manish Chopra authored
      Validate and prevent some of the configurations for
      unsupported [by firmware] inputs [for example - mac ext,
      vlans, masks/prefix, tos/tclass] via ethtool -N/-U.
      Signed-off-by: default avatarManish Chopra <manish.chopra@cavium.com>
      Signed-off-by: default avatarShahed Shaikh <shahed.shaikh@cavium.com>
      Signed-off-by: default avatarAriel Elior <ariel.elior@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89ffd14e