1. 26 Dec, 2019 17 commits
    • David S. Miller's avatar
      Merge branch 'bnx2x-Bug-fixes' · 4e55a11a
      David S. Miller authored
      Manish Chopra says:
      
      ====================
      bnx2x: Bug fixes
      
      This series has changes in the area of vlan resources
      management APIs to fix fw assert issue reported in max
      vlan configuration testing over the PF.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e55a11a
    • Manish Chopra's avatar
      bnx2x: Fix accounting of vlan resources among the PFs · 5cdc40c7
      Manish Chopra authored
      While testing max vlan configuration on the PF, firmware gets
      assert as driver was configuring number of vlans more than what
      is supported per port/engine, it was figured out that there is an
      implicit vlan (hidden default vlan consuming hardware cam entry resource)
      which is configured default for all the clients (PF/VFs) on client_init
      ramrod by the adapter implicitly, so when allocating resources among the
      PFs this implicit vlan should be considered or total vlan entries should
      be reduced by one to accommodate that default/implicit vlan entry.
      Signed-off-by: default avatarManish Chopra <manishc@marvell.com>
      Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5cdc40c7
    • Manish Chopra's avatar
      bnx2x: Use appropriate define for vlan credit · 0444716a
      Manish Chopra authored
      Although it has same value as MAX_MAC_CREDIT_E2,
      use MAX_VLAN_CREDIT_E2 appropriately.
      Signed-off-by: default avatarManish Chopra <manishc@marvell.com>
      Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0444716a
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 3c2f450e
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2019-12-23
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 2 non-merge commits during the last 1 day(s) which contain
      a total of 4 files changed, 34 insertions(+), 31 deletions(-).
      
      The main changes are:
      
      1) Fix libbpf build when building on a read-only filesystem with O=dir
         option, from Namhyung Kim.
      
      2) Fix a precision tracking bug for unknown scalars, from Daniel Borkmann.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c2f450e
    • Geert Uytterhoeven's avatar
      of: mdio: Add missing inline to of_mdiobus_child_is_phy() dummy · 7df2281a
      Geert Uytterhoeven authored
      If CONFIG_OF_MDIO=n:
      
          drivers/net/phy/mdio_bus.c:23:
          include/linux/of_mdio.h:58:13: warning: ‘of_mdiobus_child_is_phy’ defined but not used [-Wunused-function]
           static bool of_mdiobus_child_is_phy(struct device_node *child)
      		 ^~~~~~~~~~~~~~~~~~~~~~~
      
      Fix this by adding the missing "inline" keyword.
      
      Fixes: 0aa4d016 ("of: mdio: export of_mdiobus_child_is_phy")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7df2281a
    • Madalin Bucur's avatar
      net: phy: aquantia: add suspend / resume ops for AQR105 · 1c93fb45
      Madalin Bucur authored
      The suspend/resume code for AQR107 works on AQR105 too.
      This patch fixes issues with the partner not seeing the link down
      when the interface using AQR105 is brought down.
      
      Fixes: bee8259d ("net: phy: add driver for aquantia phy")
      Signed-off-by: default avatarMadalin Bucur <madalin.bucur@oss.nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c93fb45
    • Madalin Bucur's avatar
      dpaa_eth: fix DMA mapping leak · c27569fc
      Madalin Bucur authored
      On the error path some fragments remain DMA mapped. Adding a fix
      that unmaps all the fragments. Rework cleanup path to be simpler.
      
      Fixes: 8151ee88 ("dpaa_eth: use page backed rx buffers")
      Signed-off-by: default avatarMadalin Bucur <madalin.bucur@oss.nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c27569fc
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · ec34c015
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for net:
      
      1) Fix endianness issue in flowtable TCP flags dissector,
         from Arnd Bergmann.
      
      2) Extend flowtable test script with dnat rules, from Florian Westphal.
      
      3) Reject padding in ebtables user entries and validate computed user
         offset, reported by syzbot, from Florian Westphal.
      
      4) Fix endianness in nft_tproxy, from Phil Sutter.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec34c015
    • Vladyslav Tarasiuk's avatar
      net/mlxfw: Fix out-of-memory error in mfa2 flash burning · a5bcd72e
      Vladyslav Tarasiuk authored
      The burning process requires to perform internal allocations of large
      chunks of memory. This memory doesn't need to be contiguous and can be
      safely allocated by vzalloc() instead of kzalloc(). This patch changes
      such allocation to avoid possible out-of-memory failure.
      
      Fixes: 410ed13c ("Add the mlxfw module for Mellanox firmware flash process")
      Signed-off-by: default avatarVladyslav Tarasiuk <vladyslavt@mellanox.com>
      Reviewed-by: default avatarAya Levin <ayal@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Tested-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5bcd72e
    • David S. Miller's avatar
      Merge branch 'hsr-fix-several-bugs-in-hsr-module' · 095e90e0
      David S. Miller authored
      Taehee Yoo says:
      
      ====================
      hsr: fix several bugs in hsr module
      
      1. The first patch fixes debugfs warning when it's opened when hsr module
      is being removed. debugfs file is opened, it tries to hold .owner module,
      but it would print warning messages if it couldn't hold .owner module.
      In order to avoid the warning message, this patch makes hsr module does
      not set .owner. Unsetting .owner is safe because these are protected by
      inode_lock().
      
      2. The second patch fixes wrong error handling of hsr_dev_finalize()
      a) hsr_dev_finalize() calls debugfs_create_{dir/file} to create debugfs.
      it checks NULL pointer but debugfs don't return NULL so it's wrong code.
      b) hsr_dev_finalize() calls register_netdevice(). so if it fails after
      register_netdevice(), it should call unregister_netdevice().
      But it doesn't.
      c) debugfs doesn't affect any actual logic of hsr module.
      So, the failure of creating of debugfs could be ignored.
      
      3. The third patch adds hsr root debugfs directory.
      When hsr interface is created, it creates debugfs directory in
      /sys/kernel/debug/<interface name>.
      It's a little bit faulty path because if an interface is the same with
      another directory name in the same path, it will fail. If hsr root
      directory is existing, the possibility of failure of creating debugfs
      file will be reduced.
      
      4. The fourth patch adds debugfs rename routine.
      debugfs directory name is the same with hsr interface name.
      So hsr interface name is changed, debugfs directory name should be
      changed too.
      
      5. The fifth patch fixes a race condition in node list add and del.
      hsr nodes are protected by RCU and there is no write side lock.
      But node insertions and deletions could be being operated concurrently.
      So write side locking is needed.
      
      6. The Sixth patch resets network header
      Tap routine is enabled, below message will be printed.
      
      [  175.852292][    C3] protocol 88fb is buggy, dev veth0
      
      hsr module doesn't set network header for supervision frame.
      But tap routine validates network header.
      If network header wasn't set, it resets and warns about it.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      095e90e0
    • Taehee Yoo's avatar
      hsr: reset network header when supervision frame is created · 3ed0a1d5
      Taehee Yoo authored
      The supervision frame is L2 frame.
      When supervision frame is created, hsr module doesn't set network header.
      If tap routine is enabled, dev_queue_xmit_nit() is called and it checks
      network_header. If network_header pointer wasn't set(or invalid),
      it resets network_header and warns.
      In order to avoid unnecessary warning message, resetting network_header
      is needed.
      
      Test commands:
          ip netns add nst
          ip link add veth0 type veth peer name veth1
          ip link add veth2 type veth peer name veth3
          ip link set veth1 netns nst
          ip link set veth3 netns nst
          ip link set veth0 up
          ip link set veth2 up
          ip link add hsr0 type hsr slave1 veth0 slave2 veth2
          ip a a 192.168.100.1/24 dev hsr0
          ip link set hsr0 up
          ip netns exec nst ip link set veth1 up
          ip netns exec nst ip link set veth3 up
          ip netns exec nst ip link add hsr1 type hsr slave1 veth1 slave2 veth3
          ip netns exec nst ip a a 192.168.100.2/24 dev hsr1
          ip netns exec nst ip link set hsr1 up
          tcpdump -nei veth0
      
      Splat looks like:
      [  175.852292][    C3] protocol 88fb is buggy, dev veth0
      
      Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ed0a1d5
    • Taehee Yoo's avatar
      hsr: fix a race condition in node list insertion and deletion · 92a35678
      Taehee Yoo authored
      hsr nodes are protected by RCU and there is no write side lock.
      But node insertions and deletions could be being operated concurrently.
      So write side locking is needed.
      
      Test commands:
          ip netns add nst
          ip link add veth0 type veth peer name veth1
          ip link add veth2 type veth peer name veth3
          ip link set veth1 netns nst
          ip link set veth3 netns nst
          ip link set veth0 up
          ip link set veth2 up
          ip link add hsr0 type hsr slave1 veth0 slave2 veth2
          ip a a 192.168.100.1/24 dev hsr0
          ip link set hsr0 up
          ip netns exec nst ip link set veth1 up
          ip netns exec nst ip link set veth3 up
          ip netns exec nst ip link add hsr1 type hsr slave1 veth1 slave2 veth3
          ip netns exec nst ip a a 192.168.100.2/24 dev hsr1
          ip netns exec nst ip link set hsr1 up
      
          for i in {0..9}
          do
              for j in {0..9}
      	do
      	    for k in {0..9}
      	    do
      	        for l in {0..9}
      		do
      	        arping 192.168.100.2 -I hsr0 -s 00:01:3$i:4$j:5$k:6$l -c1 &
      		done
      	    done
      	done
          done
      
      Splat looks like:
      [  236.066091][ T3286] list_add corruption. next->prev should be prev (ffff8880a5940300), but was ffff8880a5940d0.
      [  236.069617][ T3286] ------------[ cut here ]------------
      [  236.070545][ T3286] kernel BUG at lib/list_debug.c:25!
      [  236.071391][ T3286] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [  236.072343][ T3286] CPU: 0 PID: 3286 Comm: arping Tainted: G        W         5.5.0-rc1+ #209
      [  236.073463][ T3286] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  236.074695][ T3286] RIP: 0010:__list_add_valid+0x74/0xd0
      [  236.075499][ T3286] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 b
      [  236.078277][ T3286] RSP: 0018:ffff8880aaa97648 EFLAGS: 00010286
      [  236.086991][ T3286] RAX: 0000000000000075 RBX: ffff8880d4624c20 RCX: 0000000000000000
      [  236.088000][ T3286] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed1015552ebf
      [  236.098897][ T3286] RBP: ffff88809b53d200 R08: ffffed101b3c04f9 R09: ffffed101b3c04f9
      [  236.099960][ T3286] R10: 00000000308769a1 R11: ffffed101b3c04f8 R12: ffff8880d4624c28
      [  236.100974][ T3286] R13: ffff8880d4624c20 R14: 0000000040310100 R15: ffff8880ce17ee02
      [  236.138967][ T3286] FS:  00007f23479fa680(0000) GS:ffff8880d9c00000(0000) knlGS:0000000000000000
      [  236.144852][ T3286] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  236.145720][ T3286] CR2: 00007f4a14bab210 CR3: 00000000a61c6001 CR4: 00000000000606f0
      [  236.146776][ T3286] Call Trace:
      [  236.147222][ T3286]  hsr_add_node+0x314/0x490 [hsr]
      [  236.153633][ T3286]  hsr_forward_skb+0x2b6/0x1bc0 [hsr]
      [  236.154362][ T3286]  ? rcu_read_lock_sched_held+0x90/0xc0
      [  236.155091][ T3286]  ? rcu_read_lock_bh_held+0xa0/0xa0
      [  236.156607][ T3286]  hsr_dev_xmit+0x70/0xd0 [hsr]
      [  236.157254][ T3286]  dev_hard_start_xmit+0x160/0x740
      [  236.157941][ T3286]  __dev_queue_xmit+0x1961/0x2e10
      [  236.158565][ T3286]  ? netdev_core_pick_tx+0x2e0/0x2e0
      [ ... ]
      
      Reported-by: syzbot+3924327f9ad5f4d2b343@syzkaller.appspotmail.com
      Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92a35678
    • Taehee Yoo's avatar
      hsr: rename debugfs file when interface name is changed · 4c2d5e33
      Taehee Yoo authored
      hsr interface has own debugfs file, which name is same with interface name.
      So, interface name is changed, debugfs file name should be changed too.
      
      Fixes: fc4ecaee ("net: hsr: add debugfs support for display node list")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c2d5e33
    • Taehee Yoo's avatar
      hsr: add hsr root debugfs directory · c6c4ccd7
      Taehee Yoo authored
      In current hsr code, when hsr interface is created, it creates debugfs
      directory /sys/kernel/debug/<interface name>.
      If there is same directory or file name in there, it fails.
      In order to reduce possibility of failure of creation of debugfs,
      this patch adds root directory.
      
      Test commands:
          ip link add dummy0 type dummy
          ip link add dummy1 type dummy
          ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1
      
      Before this patch:
          /sys/kernel/debug/hsr0/node_table
      
      After this patch:
          /sys/kernel/debug/hsr/hsr0/node_table
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6c4ccd7
    • Taehee Yoo's avatar
      hsr: fix error handling routine in hsr_dev_finalize() · 1d19e2d5
      Taehee Yoo authored
      hsr_dev_finalize() is called to create new hsr interface.
      There are some wrong error handling codes.
      
      1. wrong checking return value of debugfs_create_{dir/file}.
      These function doesn't return NULL. If error occurs in there,
      it returns error pointer.
      So, it should check error pointer instead of NULL.
      
      2. It doesn't unregister interface if it fails to setup hsr interface.
      If it fails to initialize hsr interface after register_netdevice(),
      it should call unregister_netdevice().
      
      3. Ignore failure of creation of debugfs
      If creating of debugfs dir and file is failed, creating hsr interface
      will be failed. But debugfs doesn't affect actual logic of hsr module.
      So, ignoring this is more correct and this behavior is more general.
      
      Fixes: c5a75911 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d19e2d5
    • Taehee Yoo's avatar
      hsr: avoid debugfs warning message when module is remove · 84bb59d7
      Taehee Yoo authored
      When hsr module is being removed, debugfs_remove() is called to remove
      both debugfs directory and file.
      
      When module is being removed, module state is changed to
      MODULE_STATE_GOING then exit() is called.
      At this moment, module couldn't be held so try_module_get()
      will be failed.
      
      debugfs's open() callback tries to hold the module if .owner is existing.
      If it fails, warning message is printed.
      
      CPU0				CPU1
      delete_module()
          try_stop_module()
          hsr_exit()			open() <-- WARNING
              debugfs_remove()
      
      In order to avoid the warning message, this patch makes hsr module does
      not set .owner. Unsetting .owner is safe because these are protected by
      inode_lock().
      
      Test commands:
          #SHELL1
          ip link add dummy0 type dummy
          ip link add dummy1 type dummy
          while :
          do
              ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1
      	modprobe -rv hsr
          done
      
          #SHELL2
          while :
          do
              cat /sys/kernel/debug/hsr0/node_table
          done
      
      Splat looks like:
      [  101.223783][ T1271] ------------[ cut here ]------------
      [  101.230309][ T1271] debugfs file owner did not clean up at exit: node_table
      [  101.230380][ T1271] WARNING: CPU: 3 PID: 1271 at fs/debugfs/file.c:309 full_proxy_open+0x10f/0x650
      [  101.233153][ T1271] Modules linked in: hsr(-) dummy veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_d]
      [  101.237112][ T1271] CPU: 3 PID: 1271 Comm: cat Tainted: G        W         5.5.0-rc1+ #204
      [  101.238270][ T1271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  101.240379][ T1271] RIP: 0010:full_proxy_open+0x10f/0x650
      [  101.241166][ T1271] Code: 48 c1 ea 03 80 3c 02 00 0f 85 c1 04 00 00 49 8b 3c 24 e8 04 86 7e ff 84 c0 75 2d 4c 8
      [  101.251985][ T1271] RSP: 0018:ffff8880ca22fa38 EFLAGS: 00010286
      [  101.273355][ T1271] RAX: dffffc0000000008 RBX: ffff8880cc6e6200 RCX: 0000000000000000
      [  101.274466][ T1271] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8880c4dd5c14
      [  101.275581][ T1271] RBP: 0000000000000000 R08: fffffbfff2922f5d R09: 0000000000000000
      [  101.276733][ T1271] R10: 0000000000000001 R11: 0000000000000000 R12: ffffffffc0551bc0
      [  101.277853][ T1271] R13: ffff8880c4059a48 R14: ffff8880be50a5e0 R15: ffffffff941adaa0
      [  101.278956][ T1271] FS:  00007f8871cda540(0000) GS:ffff8880da800000(0000) knlGS:0000000000000000
      [  101.280216][ T1271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  101.282832][ T1271] CR2: 00007f88717cfd10 CR3: 00000000b9440005 CR4: 00000000000606e0
      [  101.283974][ T1271] Call Trace:
      [  101.285328][ T1271]  do_dentry_open+0x63c/0xf50
      [  101.286077][ T1271]  ? open_proxy_open+0x270/0x270
      [  101.288271][ T1271]  ? __x64_sys_fchdir+0x180/0x180
      [  101.288987][ T1271]  ? inode_permission+0x65/0x390
      [  101.289682][ T1271]  path_openat+0x701/0x2810
      [  101.290294][ T1271]  ? path_lookupat+0x880/0x880
      [  101.290957][ T1271]  ? check_chain_key+0x236/0x5d0
      [  101.291676][ T1271]  ? __lock_acquire+0xdfe/0x3de0
      [  101.292358][ T1271]  ? sched_clock+0x5/0x10
      [  101.292962][ T1271]  ? sched_clock_cpu+0x18/0x170
      [  101.293644][ T1271]  ? find_held_lock+0x39/0x1d0
      [  101.305616][ T1271]  do_filp_open+0x17a/0x270
      [  101.306061][ T1271]  ? may_open_dev+0xc0/0xc0
      [ ... ]
      
      Fixes: fc4ecaee ("net: hsr: add debugfs support for display node list")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84bb59d7
    • Netanel Belgazal's avatar
  2. 25 Dec, 2019 19 commits
    • David S. Miller's avatar
      Merge branch 's390-qeth-fixes' · 7f936f2a
      David S. Miller authored
      Julian Wiedmann says:
      
      ====================
      s390/qeth: fixes 2019-12-23
      
      please apply the following patch series for qeth to your net tree.
      
      This brings two fixes for errors during device initialization, deals with
      several issues in the vnicc control code, and adds a missing lock.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f936f2a
    • Julian Wiedmann's avatar
      s390/qeth: fix initialization on old HW · 0b698c83
      Julian Wiedmann authored
      I stumbled over an old OSA model that claims to support DIAG_ASSIST,
      but then rejects the cmd to query its DIAG capabilities.
      
      In the old code this was ok, as the returned raw error code was > 0.
      Now that we translate the raw codes to errnos, the "rc < 0" causes us
      to fail the initialization of the device.
      
      The fix is trivial: don't bail out when the DIAG query fails. Such an
      error is not critical, we can still use the device (with a slightly
      reduced set of features).
      
      Fixes: 742d4d40 ("s390/qeth: convert remaining legacy cmd callbacks")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b698c83
    • Alexandra Winter's avatar
      s390/qeth: vnicc Fix init to default · d1b9ae18
      Alexandra Winter authored
      During vnicc_init wanted_char should be compared to cur_char and not
      to QETH_VNICC_DEFAULT. Without this patch there is no way to enforce
      the default values as desired values.
      
      Note, that it is expected, that a card comes online with default values.
      This patch was tested with private card firmware.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: default avatarAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1b9ae18
    • Alexandra Winter's avatar
      s390/qeth: Fix vnicc_is_in_use if rx_bcast not set · e8a66d80
      Alexandra Winter authored
      Symptom: After vnicc/rx_bcast has been manually set to 0,
      	bridge_* sysfs parameters can still be set or written.
      Only occurs on HiperSockets, as OSA doesn't support changing rx_bcast.
      
      Vnic characteristics and bridgeport settings are mutually exclusive.
      rx_bcast defaults to 1, so manually setting it to 0 should disable
      bridge_* parameters.
      
      Instead it makes sense here to check the supported mask. If the card
      does not support vnicc at all, bridge commands are always allowed.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: default avatarAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8a66d80
    • Alexandra Winter's avatar
      s390/qeth: fix false reporting of VNIC CHAR config failure · 68c57bfd
      Alexandra Winter authored
      Symptom: Error message "Configuring the VNIC characteristics failed"
      in dmesg whenever an OSA interface on z15 is set online.
      
      The VNIC characteristics get re-programmed when setting a L2 device
      online. This follows the selected 'wanted' characteristics - with the
      exception that the INVISIBLE characteristic unconditionally gets
      switched off.
      
      For devices that don't support INVISIBLE (ie. OSA), the resulting
      IO failure raises a noisy error message
      ("Configuring the VNIC characteristics failed").
      For IQD, INVISIBLE is off by default anyways.
      
      So don't unnecessarily special-case the INVISIBLE characteristic, and
      thereby suppress the misleading error message on OSA devices.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: default avatarAlexandra Winter <wintera@linux.ibm.com>
      Reviewed-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68c57bfd
    • Julian Wiedmann's avatar
      s390/qeth: lock the card while changing its hsuid · 5b6c7b55
      Julian Wiedmann authored
      qeth_l3_dev_hsuid_store() initially checks the card state, but doesn't
      take the conf_mutex to ensure that the card stays in this state while
      being reconfigured.
      
      Rework the code to take this lock, and drop a redundant state check in a
      helper function.
      
      Fixes: b3332930 ("qeth: add support for af_iucv HiperSockets transport")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b6c7b55
    • Julian Wiedmann's avatar
      s390/qeth: fix qdio teardown after early init error · 8b5026bc
      Julian Wiedmann authored
      qeth_l?_set_online() goes through a number of initialization steps, and
      on any error uses qeth_l?_stop_card() to tear down the residual state.
      
      The first initialization step is qeth_core_hardsetup_card(). When this
      fails after having established a QDIO context on the device
      (ie. somewhere after qeth_mpc_initialize()), qeth_l?_stop_card() doesn't
      shut down this QDIO context again (since the card state hasn't
      progressed from DOWN at this stage).
      
      Even worse, we then call qdio_free() as final teardown step to free the
      QDIO data structures - while some of them are still hooked into wider
      QDIO infrastructure such as the IRQ list. This is inevitably followed by
      use-after-frees and other nastyness.
      
      Fix this by unconditionally calling qeth_qdio_clear_card() to shut down
      the QDIO context, and also to halt/clear any pending activity on the
      various IO channels.
      Remove the naive attempt at handling the teardown in
      qeth_mpc_initialize(), it clearly doesn't suffice and we're handling it
      properly now in the wider teardown code.
      
      Fixes: 4a71df50 ("qeth: new qeth device driver")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b5026bc
    • David S. Miller's avatar
      Merge branch 'disable-neigh-update-for-tunnels-during-pmtu-update' · 47d0b2fe
      David S. Miller authored
      Hangbin Liu says:
      
      ====================
      disable neigh update for tunnels during pmtu update
      
      When we setup a pair of gretap, ping each other and create neighbour cache.
      Then delete and recreate one side. We will never be able to ping6 to the new
      created gretap.
      
      The reason is when we ping6 remote via gretap, we will call like
      
      gre_tap_xmit()
       - ip_tunnel_xmit()
         - tnl_update_pmtu()
           - skb_dst_update_pmtu()
             - ip6_rt_update_pmtu()
               - __ip6_rt_update_pmtu()
                 - dst_confirm_neigh()
                   - ip6_confirm_neigh()
                     - __ipv6_confirm_neigh()
                       - n->confirmed = now
      
      As the confirmed time updated, in neigh_timer_handler() the check for
      NUD_DELAY confirm time will pass and the neigh state will back to
      NUD_REACHABLE. So the old/wrong mac address will be used again.
      
      If we do not update the confirmed time, the neigh state will go to
      neigh->nud_state = NUD_PROBE; then go to NUD_FAILED and re-create the
      neigh later, which is what IPv4 does.
      
      We couldn't remove the ip6_confirm_neigh() directly as we still need it
      for TCP flows. To fix it, we have to pass a bool parameter to
      dst_ops.update_pmtu() and only disable neighbor update for tunnels.
      
      v5: No code change, upate some commits description
      v4: No code change, upate some commits description
      v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
          dst_ops.update_pmtu to control whether we should do neighbor confirm.
          Also split the big patch to small ones for each area.
      v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47d0b2fe
    • Hangbin Liu's avatar
      net/dst: do not confirm neighbor for vxlan and geneve pmtu update · f081042d
      Hangbin Liu authored
      When do IPv6 tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end,
      we should not call dst_confirm_neigh() as there is no two-way communication.
      
      So disable the neigh confirm for vxlan and geneve pmtu update.
      
      v5: No change.
      v4: No change.
      v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
          dst_ops.update_pmtu to control whether we should do neighbor confirm.
          Also split the big patch to small ones for each area.
      v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
      
      Fixes: a93bf0ff ("vxlan: update skb dst pmtu on tx path")
      Fixes: 52a589d5 ("geneve: update skb dst pmtu on tx path")
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Tested-by: default avatarGuillaume Nault <gnault@redhat.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f081042d
    • Hangbin Liu's avatar
      sit: do not confirm neighbor when do pmtu update · 4d42df46
      Hangbin Liu authored
      When do IPv6 tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end,
      we should not call dst_confirm_neigh() as there is no two-way communication.
      
      v5: No change.
      v4: No change.
      v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
          dst_ops.update_pmtu to control whether we should do neighbor confirm.
          Also split the big patch to small ones for each area.
      v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4d42df46
    • Hangbin Liu's avatar
      vti: do not confirm neighbor when do pmtu update · 8247a79e
      Hangbin Liu authored
      When do IPv6 tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end,
      we should not call dst_confirm_neigh() as there is no two-way communication.
      
      Although vti and vti6 are immune to this problem because they are IFF_NOARP
      interfaces, as Guillaume pointed. There is still no sense to confirm neighbour
      here.
      
      v5: Update commit description.
      v4: No change.
      v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
          dst_ops.update_pmtu to control whether we should do neighbor confirm.
          Also split the big patch to small ones for each area.
      v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8247a79e
    • Hangbin Liu's avatar
      tunnel: do not confirm neighbor when do pmtu update · 7a1592bc
      Hangbin Liu authored
      When do tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end,
      we should not call dst_confirm_neigh() as there is no two-way communication.
      
      v5: No Change.
      v4: Update commit description
      v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
          dst_ops.update_pmtu to control whether we should do neighbor confirm.
          Also split the big patch to small ones for each area.
      v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
      
      Fixes: 0dec879f ("net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP")
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Tested-by: default avatarGuillaume Nault <gnault@redhat.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a1592bc
    • Hangbin Liu's avatar
      net/dst: add new function skb_dst_update_pmtu_no_confirm · 07dc35c6
      Hangbin Liu authored
      Add a new function skb_dst_update_pmtu_no_confirm() for callers who need
      update pmtu but should not do neighbor confirm.
      
      v5: No change.
      v4: No change.
      v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
          dst_ops.update_pmtu to control whether we should do neighbor confirm.
          Also split the big patch to small ones for each area.
      v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07dc35c6
    • Hangbin Liu's avatar
      gtp: do not confirm neighbor when do pmtu update · 6e9105c7
      Hangbin Liu authored
      When do IPv6 tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end,
      we should not call dst_confirm_neigh() as there is no two-way communication.
      
      Although GTP only support ipv4 right now, and __ip_rt_update_pmtu() does not
      call dst_confirm_neigh(), we still set it to false to keep consistency with
      IPv6 code.
      
      v5: No change.
      v4: No change.
      v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
          dst_ops.update_pmtu to control whether we should do neighbor confirm.
          Also split the big patch to small ones for each area.
      v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e9105c7
    • Hangbin Liu's avatar
      ip6_gre: do not confirm neighbor when do pmtu update · 675d76ad
      Hangbin Liu authored
      When we do ipv6 gre pmtu update, we will also do neigh confirm currently.
      This will cause the neigh cache be refreshed and set to REACHABLE before
      xmit.
      
      But if the remote mac address changed, e.g. device is deleted and recreated,
      we will not able to notice this and still use the old mac address as the neigh
      cache is REACHABLE.
      
      Fix this by disable neigh confirm when do pmtu update
      
      v5: No change.
      v4: No change.
      v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
          dst_ops.update_pmtu to control whether we should do neighbor confirm.
          Also split the big patch to small ones for each area.
      v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      675d76ad
    • Hangbin Liu's avatar
      net: add bool confirm_neigh parameter for dst_ops.update_pmtu · bd085ef6
      Hangbin Liu authored
      The MTU update code is supposed to be invoked in response to real
      networking events that update the PMTU. In IPv6 PMTU update function
      __ip6_rt_update_pmtu() we called dst_confirm_neigh() to update neighbor
      confirmed time.
      
      But for tunnel code, it will call pmtu before xmit, like:
        - tnl_update_pmtu()
          - skb_dst_update_pmtu()
            - ip6_rt_update_pmtu()
              - __ip6_rt_update_pmtu()
                - dst_confirm_neigh()
      
      If the tunnel remote dst mac address changed and we still do the neigh
      confirm, we will not be able to update neigh cache and ping6 remote
      will failed.
      
      So for this ip_tunnel_xmit() case, _EVEN_ if the MTU is changed, we
      should not be invoking dst_confirm_neigh() as we have no evidence
      of successful two-way communication at this point.
      
      On the other hand it is also important to keep the neigh reachability fresh
      for TCP flows, so we cannot remove this dst_confirm_neigh() call.
      
      To fix the issue, we have to add a new bool parameter for dst_ops.update_pmtu
      to choose whether we should do neigh update or not. I will add the parameter
      in this patch and set all the callers to true to comply with the previous
      way, and fix the tunnel code one by one on later patches.
      
      v5: No change.
      v4: No change.
      v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
          dst_ops.update_pmtu to control whether we should do neighbor confirm.
          Also split the big patch to small ones for each area.
      v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
      Suggested-by: default avatarDavid Miller <davem@davemloft.net>
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd085ef6
    • David S. Miller's avatar
      Merge tag 'rxrpc-fixes-20191220' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · ff43ae4b
      David S. Miller authored
      David Howells says:
      
      ====================
      rxrpc: Fixes
      
      Here are a couple of bugfixes plus a patch that makes one of the bugfixes
      easier:
      
       (1) Move the ping and mutex unlock on a new call from rxrpc_input_packet()
           into rxrpc_new_incoming_call(), which it calls.  This means the
           lock-unlock section is entirely within the latter function.  This
           simplifies patch (2).
      
       (2) Don't take the call->user_mutex at all in the softirq path.  Mutexes
           aren't allowed to be taken or released there and a patch was merged
           that caused a warning to be emitted every time this happened.  Looking
           at the code again, it looks like that taking the mutex isn't actually
           necessary, as the value of call->state will block access to the call.
      
       (3) Fix the incoming call path to check incoming calls earlier to reject
           calls to RPC services for which we don't have a security key of the
           appropriate class.  This avoids an assertion failure if YFS tries
           making a secure call to the kafs cache manager RPC service.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff43ae4b
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Fix IP fragment location and behavior · 7c3125f0
      Florian Fainelli authored
      The IP fragment is specified through user-defined field as the first
      bit of the first user-defined word. We were previously trying to extract
      it from the user-defined mask which could not possibly work. The ip_frag
      is also supposed to be a boolean, if we do not cast it as such, we risk
      overwriting the next fields in CFP_DATA(6) which would render the rule
      inoperative.
      
      Fixes: 7318166c ("net: dsa: bcm_sf2: Add support for ethtool::rxnfc")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c3125f0
    • Marcelo Ricardo Leitner's avatar
      sctp: fix err handling of stream initialization · 61d5d406
      Marcelo Ricardo Leitner authored
      The fix on 951c6db9 fixed the issued reported there but introduced
      another. When the allocation fails within sctp_stream_init() it is
      okay/necessary to free the genradix. But it is also called when adding
      new streams, from sctp_send_add_streams() and
      sctp_process_strreset_addstrm_in() and in those situations it cannot
      just free the genradix because by then it is a fully operational
      association.
      
      The fix here then is to only free the genradix in sctp_stream_init()
      and on those other call sites  move on with what it already had and let
      the subsequent error handling to handle it.
      
      Tested with the reproducers from this report and the previous one,
      with lksctp-tools and sctp-tests.
      
      Reported-by: syzbot+9a1bc632e78a1a98488b@syzkaller.appspotmail.com
      Fixes: 951c6db9 ("sctp: fix memleak on err handling of stream initialization")
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61d5d406
  3. 24 Dec, 2019 1 commit
  4. 23 Dec, 2019 2 commits
    • Namhyung Kim's avatar
      libbpf: Fix build on read-only filesystems · fa633a0f
      Namhyung Kim authored
      I got the following error when I tried to build perf on a read-only
      filesystem with O=dir option.
      
        $ cd /some/where/ro/linux/tools/perf
        $ make O=$HOME/build/perf
        ...
          CC       /home/namhyung/build/perf/lib.o
        /bin/sh: bpf_helper_defs.h: Read-only file system
        make[3]: *** [Makefile:184: bpf_helper_defs.h] Error 1
        make[2]: *** [Makefile.perf:778: /home/namhyung/build/perf/libbpf.a] Error 2
        make[2]: *** Waiting for unfinished jobs....
          LD       /home/namhyung/build/perf/libperf-in.o
          AR       /home/namhyung/build/perf/libperf.a
          PERF_VERSION = 5.4.0
        make[1]: *** [Makefile.perf:225: sub-make] Error 2
        make: *** [Makefile:70: all] Error 2
      
      It was becaused bpf_helper_defs.h was generated in current directory.
      Move it to OUTPUT directory.
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Tested-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/20191223061326.843366-1-namhyung@kernel.org
      fa633a0f
    • Daniel Borkmann's avatar
      bpf: Fix precision tracking for unbounded scalars · f54c7898
      Daniel Borkmann authored
      Anatoly has been fuzzing with kBdysch harness and reported a hang in one
      of the outcomes. Upon closer analysis, it turns out that precise scalar
      value tracking is missing a few precision markings for unknown scalars:
      
        0: R1=ctx(id=0,off=0,imm=0) R10=fp0
        0: (b7) r0 = 0
        1: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        1: (35) if r0 >= 0xf72e goto pc+0
        --> only follow fallthrough
        2: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        2: (35) if r0 >= 0x80fe0000 goto pc+0
        --> only follow fallthrough
        3: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        3: (14) w0 -= -536870912
        4: R0_w=invP536870912 R1=ctx(id=0,off=0,imm=0) R10=fp0
        4: (0f) r1 += r0
        5: R0_w=invP536870912 R1_w=inv(id=0) R10=fp0
        5: (55) if r1 != 0x104c1500 goto pc+0
        --> push other branch for later analysis
        R0_w=invP536870912 R1_w=inv273421568 R10=fp0
        6: R0_w=invP536870912 R1_w=inv273421568 R10=fp0
        6: (b7) r0 = 0
        7: R0=invP0 R1=inv273421568 R10=fp0
        7: (76) if w1 s>= 0xffffff00 goto pc+3
        --> only follow goto
        11: R0=invP0 R1=inv273421568 R10=fp0
        11: (95) exit
        6: R0_w=invP536870912 R1_w=inv(id=0) R10=fp0
        6: (b7) r0 = 0
        propagating r0
        7: safe
        processed 11 insns [...]
      
      In the analysis of the second path coming after the successful exit above,
      the path is being pruned at line 7. Pruning analysis found that both r0 are
      precise P0 and both R1 are non-precise scalars and given prior path with
      R1 as non-precise scalar succeeded, this one is therefore safe as well.
      
      However, problem is that given condition at insn 7 in the first run, we only
      followed goto and didn't push the other branch for later analysis, we've
      never walked the few insns in there and therefore dead-code sanitation
      rewrites it as goto pc-1, causing the hang depending on the skb address
      hitting these conditions. The issue is that R1 should have been marked as
      precise as well such that pruning enforces range check and conluded that new
      R1 is not in range of old R1. In insn 4, we mark R1 (skb) as unknown scalar
      via __mark_reg_unbounded() but not mark_reg_unbounded() and therefore
      regs->precise remains as false.
      
      Back in b5dc0163 ("bpf: precise scalar_value tracking"), this was not
      the case since marking out of __mark_reg_unbounded() had this covered as well.
      Once in both are set as precise in 4 as they should have been, we conclude
      that given R1 was in prior fall-through path 0x104c1500 and now is completely
      unknown, the check at insn 7 concludes that we need to continue walking.
      Analysis after the fix:
      
        0: R1=ctx(id=0,off=0,imm=0) R10=fp0
        0: (b7) r0 = 0
        1: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        1: (35) if r0 >= 0xf72e goto pc+0
        2: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        2: (35) if r0 >= 0x80fe0000 goto pc+0
        3: R0_w=invP0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        3: (14) w0 -= -536870912
        4: R0_w=invP536870912 R1=ctx(id=0,off=0,imm=0) R10=fp0
        4: (0f) r1 += r0
        5: R0_w=invP536870912 R1_w=invP(id=0) R10=fp0
        5: (55) if r1 != 0x104c1500 goto pc+0
        R0_w=invP536870912 R1_w=invP273421568 R10=fp0
        6: R0_w=invP536870912 R1_w=invP273421568 R10=fp0
        6: (b7) r0 = 0
        7: R0=invP0 R1=invP273421568 R10=fp0
        7: (76) if w1 s>= 0xffffff00 goto pc+3
        11: R0=invP0 R1=invP273421568 R10=fp0
        11: (95) exit
        6: R0_w=invP536870912 R1_w=invP(id=0) R10=fp0
        6: (b7) r0 = 0
        7: R0_w=invP0 R1_w=invP(id=0) R10=fp0
        7: (76) if w1 s>= 0xffffff00 goto pc+3
        R0_w=invP0 R1_w=invP(id=0) R10=fp0
        8: R0_w=invP0 R1_w=invP(id=0) R10=fp0
        8: (a5) if r0 < 0x2007002a goto pc+0
        9: R0_w=invP0 R1_w=invP(id=0) R10=fp0
        9: (57) r0 &= -16316416
        10: R0_w=invP0 R1_w=invP(id=0) R10=fp0
        10: (a6) if w0 < 0x1201 goto pc+0
        11: R0_w=invP0 R1_w=invP(id=0) R10=fp0
        11: (95) exit
        11: R0=invP0 R1=invP(id=0) R10=fp0
        11: (95) exit
        processed 16 insns [...]
      
      Fixes: 6754172c ("bpf: fix precision tracking in presence of bpf2bpf calls")
      Reported-by: default avatarAnatoly Trosinenko <anatoly.trosinenko@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20191222223740.25297-1-daniel@iogearbox.net
      f54c7898
  5. 22 Dec, 2019 1 commit
    • Linus Torvalds's avatar
      Merge tag 'xfs-5.5-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · c6017471
      Linus Torvalds authored
      Pull xfs fixes from Darrick Wong:
       "Fix a few bugs that could lead to corrupt files, fsck complaints, and
        filesystem crashes:
      
         - Minor documentation fixes
      
         - Fix a file corruption due to read racing with an insert range
           operation.
      
         - Fix log reservation overflows when allocating large rt extents
      
         - Fix a buffer log item flags check
      
         - Don't allow administrators to mount with sunit= options that will
           cause later xfs_repair complaints about the root directory being
           suspicious because the fs geometry appeared inconsistent
      
         - Fix a non-static helper that should have been static"
      
      * tag 'xfs-5.5-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: Make the symbol 'xfs_rtalloc_log_count' static
        xfs: don't commit sunit/swidth updates to disk if that would cause repair failures
        xfs: split the sunit parameter update into two parts
        xfs: refactor agfl length computation function
        libxfs: resync with the userspace libxfs
        xfs: use bitops interface for buf log item AIL flag check
        xfs: fix log reservation overflows when allocating large rt extents
        xfs: stabilize insert range start boundary to avoid COW writeback race
        xfs: fix Sphinx documentation warning
      c6017471