Permalink
Commits on Mar 27, 2018
  1. Makefile: linux4sam_5.8

    noglitch committed Mar 27, 2018
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Commits on Mar 20, 2018
  1. Makefile: linux4sam_5.8-rc4

    ldesroches committed Mar 20, 2018
    Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
  2. spi: atmel: init FIFOs before spi enable

    ehristev authored and ldesroches committed Feb 27, 2018
    The datasheet recommends initializing FIFOs before
    SPI enable. If we do not do it like this, there may be
    a strange behavior. We noticed that DMA does not work properly
    with FIFOs if we do not clear them beforehand or enable them
    before SPIEN.
    
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Commits on Mar 15, 2018
  1. ARM: dts: at91: sama5d2_ptc_ek: add ULP1 wakeup sources

    ldesroches committed Mar 15, 2018
    Add the RTC, the wakeup button and GMAC as wakeup sources for the
    ULP1 power mode.
    
    Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Commits on Mar 14, 2018
  1. Makefile: linux4sam_5.8-rc3

    ldesroches committed Mar 14, 2018
    Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
  2. ARM: dts: at91: sama5d2_ptc_ek: add PB_USER as wakeup source

    ldesroches committed Mar 14, 2018
    Add the push button PB_USER as wakeup source
    
    Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Commits on Mar 13, 2018
  1. input: atmel_ptc: update path and names of firmware file

    ldesroches committed Mar 13, 2018
    Update the name of the firmware files which are located in a
    microchip folder.
    
    Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
  2. ARM: dts: at91: at91sam9g25: fix mux-mask pinctrl property

    noglitch committed Mar 13, 2018
    There are only 19 PIOB pins having primary names PB0-PB18. Not all of them
    have a 'C' function. So the pinctrl property mask ends up being the same as the
    other SoC of the at91sam9x5 series.
    
    Reported-by: Marek Sieranski <marek.sieranski@microchip.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Cc: <stable@vger.kernel.org> # v3.8+
  3. net: macb: add new compatibility string for macb on sama5d3

    noglitch committed Mar 13, 2018
    We need this new compatibility string as we experienced different behavior
    for this 10/100Mbits/s macb interface on this particular SoC.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
  4. net: macb: add new compatibility string for macb on sama5d3

    noglitch committed Mar 13, 2018
    We need this new compatibility string as we experienced different behavior
    for this 10/100Mbits/s macb interface on this particular SoC.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
  5. net: macb: disable scatter-gather for macb on sama5d3

    noglitch committed Mar 13, 2018
    Create a new configuration for the sama5d3-macb new compatibility string.
    This configuration disables scatter-gather because we experienced lock down
    of the macb interface of this particular SoC under very high load.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
  6. ARM: dts: at91: sama5d2_ptc_ek: fix sdmmc0 node description

    ldesroches committed Mar 13, 2018
    Remove non-removable and mmc-ddr-1_8v properties from the sdmmc0
    node which come probably from an unchecked copy/paste.
    
    Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Commits on Mar 12, 2018
  1. Merge tag 'v4.9.87' into linux-4.9-at91

    noglitch committed Mar 12, 2018
    This is the 4.9.87 stable release
Commits on Mar 11, 2018
  1. Linux 4.9.87

    gregkh committed Mar 11, 2018
  2. btrfs: preserve i_mode if __btrfs_set_acl() fails

    eafer authored and gregkh committed Aug 2, 2017
    commit d7d8249 upstream.
    
    When changing a file's acl mask, btrfs_set_acl() will first set the
    group bits of i_mode to the value of the mask, and only then set the
    actual extended attribute representing the new acl.
    
    If the second part fails (due to lack of space, for example) and the
    file had no acl attribute to begin with, the system will from now on
    assume that the mask permission bits are actual group permission bits,
    potentially granting access to the wrong users.
    
    Prevent this by restoring the original mode bits if __btrfs_set_acl
    fails.
    
    Signed-off-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. bpf, ppc64: fix out of bounds access in tail call

    borkmann authored and gregkh committed Mar 8, 2018
    [ upstream commit d269176 ]
    
    While working on 16338a9 ("bpf, arm64: fix out of bounds access in
    tail call") I noticed that ppc64 JIT is partially affected as well. While
    the bound checking is correctly performed as unsigned comparison, the
    register with the index value however, is never truncated into 32 bit
    space, so e.g. a index value of 0x100000000ULL with a map of 1 element
    would pass with PPC_CMPLW() whereas we later on continue with the full
    64 bit register value. Therefore, as we do in interpreter and other JITs
    truncate the value to 32 bit initially in order to fix access.
    
    Fixes: ce07614 ("powerpc/bpf: Implement support for tail calls")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. bpf: add schedule points in percpu arrays management

    Eric Dumazet authored and gregkh committed Mar 8, 2018
    [ upstream commit 32fff23 ]
    
    syszbot managed to trigger RCU detected stalls in
    bpf_array_free_percpu()
    
    It takes time to allocate a huge percpu map, but even more time to free
    it.
    
    Since we run in process context, use cond_resched() to yield cpu if
    needed.
    
    Fixes: a10423b ("bpf: introduce BPF_MAP_TYPE_PERCPU_ARRAY map")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. bpf, arm64: fix out of bounds access in tail call

    borkmann authored and gregkh committed Mar 8, 2018
    [ upstream commit 16338a9 ]
    
    I recently noticed a crash on arm64 when feeding a bogus index
    into BPF tail call helper. The crash would not occur when the
    interpreter is used, but only in case of JIT. Output looks as
    follows:
    
      [  347.007486] Unable to handle kernel paging request at virtual address fffb850e96492510
      [...]
      [  347.043065] [fffb850e96492510] address between user and kernel address ranges
      [  347.050205] Internal error: Oops: 96000004 [#1] SMP
      [...]
      [  347.190829] x13: 0000000000000000 x12: 0000000000000000
      [  347.196128] x11: fffc047ebe782800 x10: ffff808fd7d0fd10
      [  347.201427] x9 : 0000000000000000 x8 : 0000000000000000
      [  347.206726] x7 : 0000000000000000 x6 : 001c991738000000
      [  347.212025] x5 : 0000000000000018 x4 : 000000000000ba5a
      [  347.217325] x3 : 00000000000329c4 x2 : ffff808fd7cf0500
      [  347.222625] x1 : ffff808fd7d0fc00 x0 : ffff808fd7cf0500
      [  347.227926] Process test_verifier (pid: 4548, stack limit = 0x000000007467fa61)
      [  347.235221] Call trace:
      [  347.237656]  0xffff000002f3a4fc
      [  347.240784]  bpf_test_run+0x78/0xf8
      [  347.244260]  bpf_prog_test_run_skb+0x148/0x230
      [  347.248694]  SyS_bpf+0x77c/0x1110
      [  347.251999]  el0_svc_naked+0x30/0x34
      [  347.255564] Code: 9100075a d280220a 8b0a002a d37df04b (f86b694b)
      [...]
    
    In this case the index used in BPF r3 is the same as in r1
    at the time of the call, meaning we fed a pointer as index;
    here, it had the value 0xffff808fd7cf0500 which sits in x2.
    
    While I found tail calls to be working in general (also for
    hitting the error cases), I noticed the following in the code
    emission:
    
      # bpftool p d j i 988
      [...]
      38:   ldr     w10, [x1,x10]
      3c:   cmp     w2, w10
      40:   b.ge    0x000000000000007c              <-- signed cmp
      44:   mov     x10, #0x20                      // #32
      48:   cmp     x26, x10
      4c:   b.gt    0x000000000000007c
      50:   add     x26, x26, #0x1
      54:   mov     x10, #0x110                     // #272
      58:   add     x10, x1, x10
      5c:   lsl     x11, x2, #3
      60:   ldr     x11, [x10,x11]                  <-- faulting insn (f86b694b)
      64:   cbz     x11, 0x000000000000007c
      [...]
    
    Meaning, the tests passed because commit ddb5599 ("arm64:
    bpf: implement bpf_tail_call() helper") was using signed compares
    instead of unsigned which as a result had the test wrongly passing.
    
    Change this but also the tail call count test both into unsigned
    and cap the index as u32. Latter we did as well in 90caccd
    ("bpf: fix bpf_tail_call() x64 JIT") and is needed in addition here,
    too. Tested on HiSilicon Hi1616.
    
    Result after patch:
    
      # bpftool p d j i 268
      [...]
      38:	ldr	w10, [x1,x10]
      3c:	add	w2, w2, #0x0
      40:	cmp	w2, w10
      44:	b.cs	0x0000000000000080
      48:	mov	x10, #0x20                  	// #32
      4c:	cmp	x26, x10
      50:	b.hi	0x0000000000000080
      54:	add	x26, x26, #0x1
      58:	mov	x10, #0x110                 	// #272
      5c:	add	x10, x1, x10
      60:	lsl	x11, x2, #3
      64:	ldr	x11, [x10,x11]
      68:	cbz	x11, 0x0000000000000080
      [...]
    
    Fixes: ddb5599 ("arm64: bpf: implement bpf_tail_call() helper")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. bpf, x64: implement retpoline for tail call

    borkmann authored and gregkh committed Mar 8, 2018
    [ upstream commit a493a87 ]
    
    Implement a retpoline [0] for the BPF tail call JIT'ing that converts
    the indirect jump via jmp %rax that is used to make the long jump into
    another JITed BPF image. Since this is subject to speculative execution,
    we need to control the transient instruction sequence here as well
    when CONFIG_RETPOLINE is set, and direct it into a pause + lfence loop.
    The latter aligns also with what gcc / clang emits (e.g. [1]).
    
    JIT dump after patch:
    
      # bpftool p d x i 1
       0: (18) r2 = map[id:1]
       2: (b7) r3 = 0
       3: (85) call bpf_tail_call#12
       4: (b7) r0 = 2
       5: (95) exit
    
    With CONFIG_RETPOLINE:
    
      # bpftool p d j i 1
      [...]
      33:	cmp    %edx,0x24(%rsi)
      36:	jbe    0x0000000000000072  |*
      38:	mov    0x24(%rbp),%eax
      3e:	cmp    $0x20,%eax
      41:	ja     0x0000000000000072  |
      43:	add    $0x1,%eax
      46:	mov    %eax,0x24(%rbp)
      4c:	mov    0x90(%rsi,%rdx,8),%rax
      54:	test   %rax,%rax
      57:	je     0x0000000000000072  |
      59:	mov    0x28(%rax),%rax
      5d:	add    $0x25,%rax
      61:	callq  0x000000000000006d  |+
      66:	pause                      |
      68:	lfence                     |
      6b:	jmp    0x0000000000000066  |
      6d:	mov    %rax,(%rsp)         |
      71:	retq                       |
      72:	mov    $0x2,%eax
      [...]
    
      * relative fall-through jumps in error case
      + retpoline for indirect jump
    
    Without CONFIG_RETPOLINE:
    
      # bpftool p d j i 1
      [...]
      33:	cmp    %edx,0x24(%rsi)
      36:	jbe    0x0000000000000063  |*
      38:	mov    0x24(%rbp),%eax
      3e:	cmp    $0x20,%eax
      41:	ja     0x0000000000000063  |
      43:	add    $0x1,%eax
      46:	mov    %eax,0x24(%rbp)
      4c:	mov    0x90(%rsi,%rdx,8),%rax
      54:	test   %rax,%rax
      57:	je     0x0000000000000063  |
      59:	mov    0x28(%rax),%rax
      5d:	add    $0x25,%rax
      61:	jmpq   *%rax               |-
      63:	mov    $0x2,%eax
      [...]
    
      * relative fall-through jumps in error case
      - plain indirect jump as before
    
      [0] https://support.google.com/faqs/answer/7625886
      [1] gcc-mirror/gcc@a31e654
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. bpf: fix mlock precharge on arraymaps

    borkmann authored and gregkh committed Mar 8, 2018
    [ upstream commit 9c2d63b ]
    
    syzkaller recently triggered OOM during percpu map allocation;
    while there is work in progress by Dennis Zhou to add __GFP_NORETRY
    semantics for percpu allocator under pressure, there seems also a
    missing bpf_map_precharge_memlock() check in array map allocation.
    
    Given today the actual bpf_map_charge_memlock() happens after the
    find_and_alloc_map() in syscall path, the bpf_map_precharge_memlock()
    is there to bail out early before we go and do the map setup work
    when we find that we hit the limits anyway. Therefore add this for
    array map as well.
    
    Fixes: 6c90598 ("bpf: pre-allocate hash map elements")
    Fixes: a10423b ("bpf: introduce BPF_MAP_TYPE_PERCPU_ARRAY map")
    Reported-by: syzbot+adb03f3f0bb57ce3acda@syzkaller.appspotmail.com
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Dennis Zhou <dennisszhou@gmail.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. bpf: fix wrong exposure of map_flags into fdinfo for lpm

    borkmann authored and gregkh committed Mar 8, 2018
    [ upstream commit a316338 ]
    
    trie_alloc() always needs to have BPF_F_NO_PREALLOC passed in via
    attr->map_flags, since it does not support preallocation yet. We
    check the flag, but we never copy the flag into trie->map.map_flags,
    which is later on exposed into fdinfo and used by loaders such as
    iproute2. Latter uses this in bpf_map_selfcheck_pinned() to test
    whether a pinned map has the same spec as the one from the BPF obj
    file and if not, bails out, which is currently the case for lpm
    since it exposes always 0 as flags.
    
    Also copy over flags in array_map_alloc() and stack_map_alloc().
    They always have to be 0 right now, but we should make sure to not
    miss to copy them over at a later point in time when we add actual
    flags for them to use.
    
    Fixes: b95a5c4 ("bpf: add a longest prefix match trie map implementation")
    Reported-by: Jarno Rajahalme <jarno@covalent.io>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. mpls, nospec: Sanitize array index in mpls_label_ok()

    djbw authored and gregkh committed Mar 8, 2018
    commit 3968523 upstream.
    
    mpls_label_ok() validates that the 'platform_label' array index from a
    userspace netlink message payload is valid. Under speculation the
    mpls_label_ok() result may not resolve in the CPU pipeline until after
    the index is used to access an array element. Sanitize the index to zero
    to prevent userspace-controlled arbitrary out-of-bounds speculation, a
    precursor for a speculative execution side channel vulnerability.
    
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 4.4:
     - mpls_label_ok() doesn't take an extack parameter
     - Drop change in mpls_getroute()]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. net: mpls: Pull common label check into helper

    dsahern authored and gregkh committed Mar 8, 2018
    commit b7b386f upstream.
    
    mpls_route_add and mpls_route_del have the same checks on the label.
    Move to a helper. Avoid duplicate extack messages in the next patch.
    
    Signed-off-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. sctp: verify size of a new chunk in _sctp_make_chunk()

    akodanev authored and gregkh committed Feb 9, 2018
    [ Upstream commit 07f2c7a ]
    
    When SCTP makes INIT or INIT_ACK packet the total chunk length
    can exceed SCTP_MAX_CHUNK_LEN which leads to kernel panic when
    transmitting these packets, e.g. the crash on sending INIT_ACK:
    
    [  597.804948] skbuff: skb_over_panic: text:00000000ffae06e4 len:120168
                   put:120156 head:000000007aa47635 data:00000000d991c2de
                   tail:0x1d640 end:0xfec0 dev:<NULL>
    ...
    [  597.976970] ------------[ cut here ]------------
    [  598.033408] kernel BUG at net/core/skbuff.c:104!
    [  600.314841] Call Trace:
    [  600.345829]  <IRQ>
    [  600.371639]  ? sctp_packet_transmit+0x2095/0x26d0 [sctp]
    [  600.436934]  skb_put+0x16c/0x200
    [  600.477295]  sctp_packet_transmit+0x2095/0x26d0 [sctp]
    [  600.540630]  ? sctp_packet_config+0x890/0x890 [sctp]
    [  600.601781]  ? __sctp_packet_append_chunk+0x3b4/0xd00 [sctp]
    [  600.671356]  ? sctp_cmp_addr_exact+0x3f/0x90 [sctp]
    [  600.731482]  sctp_outq_flush+0x663/0x30d0 [sctp]
    [  600.788565]  ? sctp_make_init+0xbf0/0xbf0 [sctp]
    [  600.845555]  ? sctp_check_transmitted+0x18f0/0x18f0 [sctp]
    [  600.912945]  ? sctp_outq_tail+0x631/0x9d0 [sctp]
    [  600.969936]  sctp_cmd_interpreter.isra.22+0x3be1/0x5cb0 [sctp]
    [  601.041593]  ? sctp_sf_do_5_1B_init+0x85f/0xc30 [sctp]
    [  601.104837]  ? sctp_generate_t1_cookie_event+0x20/0x20 [sctp]
    [  601.175436]  ? sctp_eat_data+0x1710/0x1710 [sctp]
    [  601.233575]  sctp_do_sm+0x182/0x560 [sctp]
    [  601.284328]  ? sctp_has_association+0x70/0x70 [sctp]
    [  601.345586]  ? sctp_rcv+0xef4/0x32f0 [sctp]
    [  601.397478]  ? sctp6_rcv+0xa/0x20 [sctp]
    ...
    
    Here the chunk size for INIT_ACK packet becomes too big, mostly
    because of the state cookie (INIT packet has large size with
    many address parameters), plus additional server parameters.
    
    Later this chunk causes the panic in skb_put_data():
    
      skb_packet_transmit()
          sctp_packet_pack()
              skb_put_data(nskb, chunk->skb->data, chunk->skb->len);
    
    'nskb' (head skb) was previously allocated with packet->size
    from u16 'chunk->chunk_hdr->length'.
    
    As suggested by Marcelo we should check the chunk's length in
    _sctp_make_chunk() before trying to allocate skb for it and
    discard a chunk if its size bigger than SCTP_MAX_CHUNK_LEN.
    
    Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leinter@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. s390/qeth: fix IPA command submission race

    julianwiedmann authored and gregkh committed Feb 27, 2018
    [ Upstream commit d22ffb5 ]
    
    If multiple IPA commands are build & sent out concurrently,
    fill_ipacmd_header() may assign a seqno value to a command that's
    different from what send_control_data() later assigns to this command's
    reply.
    This is due to other commands passing through send_control_data(),
    and incrementing card->seqno.ipa along the way.
    
    So one IPA command has no reply that's waiting for its seqno, while some
    other IPA command has multiple reply objects waiting for it.
    Only one of those waiting replies wins, and the other(s) times out and
    triggers a recovery via send_ipa_cmd().
    
    Fix this by making sure that the same seqno value is assigned to
    a command and its reply object.
    Do so immediately before submitting the command & while holding the
    irq_pending "lock", to produce nicely ascending seqnos.
    
    As a side effect, *all* IPA commands now use a reply object that's
    waiting for its actual seqno. Previously, early IPA commands that were
    submitted while the card was still DOWN used the "catch-all" IDX seqno.
    
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. s390/qeth: fix IP address lookup for L3 devices

    julianwiedmann authored and gregkh committed Feb 27, 2018
    [ Upstream commit c5c48c5 ]
    
    Current code ("qeth_l3_ip_from_hash()") matches a queried address object
    against objects in the IP table by IP address, Mask/Prefix Length and
    MAC address ("qeth_l3_ipaddrs_is_equal()"). But what callers actually
    require is either
    a) "is this IP address registered" (ie. match by IP address only),
    before adding a new address.
    b) or "is this address object registered" (ie. match all relevant
       attributes), before deleting an address.
    
    Right now
    1. the ADD path is too strict in its lookup, and eg. doesn't detect
    conflicts between an existing NORMAL address and a new VIPA address
    (because the NORMAL address will have mask != 0, while VIPA has
    a mask == 0),
    2. the DELETE path is not strict enough, and eg. allows del_rxip() to
    delete a VIPA address as long as the IP address matches.
    
    Fix all this by adding helpers (_addr_match_ip() and _addr_match_all())
    that do the appropriate checking.
    
    Note that the ADD path for NORMAL addresses is special, as qeth keeps
    track of how many times such an address is in use (and there is no
    immediate way of returning errors to the caller). So when a requested
    NORMAL address _fully_ matches an existing one, it's not considered a
    conflict and we merely increment the refcount.
    
    Fixes: 5f78e29 ("qeth: optimize IP handling in rx_mode callback")
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. s390/qeth: fix double-free on IP add/remove race

    julianwiedmann authored and gregkh committed Feb 27, 2018
    [ Upstream commit 14d066c ]
    
    Registering an IPv4 address with the HW takes quite a while, so we
    temporarily drop the ip_htable lock. Any concurrent add/remove of the
    same IP adjusts the IP's use count, and (on remove) is then blocked by
    addr->in_progress.
    After the register call has completed, we check the use count for
    concurrently attempted add/remove calls - and possibly straight-away
    deregister the IP again. This happens via l3_delete_ip(), which
    1) looks up the queried IP in the htable (getting a reference to the
       *same* queried object),
    2) deregisters the IP from the HW, and
    3) frees the IP object.
    
    The caller in l3_add_ip() then does a second free on the same object.
    
    For this case, skip all the extra checks and lookups in l3_delete_ip()
    and just deregister & free the IP object ourselves.
    
    Fixes: 5f78e29 ("qeth: optimize IP handling in rx_mode callback")
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. s390/qeth: fix IP removal on offline cards

    julianwiedmann authored and gregkh committed Feb 27, 2018
    [ Upstream commit 98d823a ]
    
    If the HW is not reachable, then none of the IPs in qeth's internal
    table has been registered with the HW yet. So when deleting such an IP,
    there's no need to stage it for deregistration - just drop it from
    the table.
    
    This fixes the "add-delete-add" scenario on an offline card, where the
    the second "add" merely increments the IP's use count. But as the IP is
    still set to DISP_ADDR_DELETE from the previous "delete" step,
    l3_recover_ip() won't register it with the HW when the card goes online.
    
    Fixes: 5f78e29 ("qeth: optimize IP handling in rx_mode callback")
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. s390/qeth: fix overestimated count of buffer elements

    julianwiedmann authored and gregkh committed Feb 27, 2018
    [ Upstream commit 12472af ]
    
    qeth_get_elements_for_range() doesn't know how to handle a 0-length
    range (ie. start == end), and returns 1 when it should return 0.
    Such ranges occur on TSO skbs, where the L2/L3/L4 headers (and thus all
    of the skb's linear data) are skipped when mapping the skb into regular
    buffer elements.
    
    This overestimation may cause several performance-related issues:
    1. sub-optimal IO buffer selection, where the next buffer gets selected
       even though the skb would actually still fit into the current buffer.
    2. forced linearization, if the element count for a non-linear skb
       exceeds QETH_MAX_BUFFER_ELEMENTS.
    
    Rather than modifying qeth_get_elements_for_range() and adding overhead
    to every caller, fix up those callers that are in risk of passing a
    0-length range.
    
    Fixes: 2863c61 ("qeth: refactor calculation of SBALE count")
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. s390/qeth: fix SETIP command handling

    julianwiedmann authored and gregkh committed Feb 9, 2018
    [ Upstream commit 1c5b221 ]
    
    send_control_data() applies some special handling to SETIP v4 IPA
    commands. But current code parses *all* command types for the SETIP
    command code. Limit the command code check to IPA commands.
    
    Fixes: 5b54e16 ("qeth: do not spin for SETIP ip assist command")
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>