1. 26 Jul, 2019 9 commits
  2. 25 Jul, 2019 9 commits
  3. 24 Jul, 2019 15 commits
    • Cong Wang's avatar
      netrom: hold sock when setting skb->destructor · 4638faac
      Cong Wang authored
      sock_efree() releases the sock refcnt, if we don't hold this refcnt
      when setting skb->destructor to it, the refcnt would not be balanced.
      This leads to several bug reports from syzbot.
      
      I have checked other users of sock_efree(), all of them hold the
      sock refcnt.
      
      Fixes: c8c8218e ("netrom: fix a memory leak in nr_rx_frame()")
      Reported-and-tested-by: <syzbot+622bdabb128acc33427d@syzkaller.appspotmail.com>
      Reported-and-tested-by: <syzbot+6eaef7158b19e3fec3a0@syzkaller.appspotmail.com>
      Reported-and-tested-by: <syzbot+9399c158fcc09b21d0d2@syzkaller.appspotmail.com>
      Reported-and-tested-by: <syzbot+a34e5f3d0300163f0c87@syzkaller.appspotmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4638faac
    • Arnd Bergmann's avatar
      ovs: datapath: hide clang frame-overflow warnings · 26063790
      Arnd Bergmann authored
      Some functions in the datapath code are factored out so that each
      one has a stack frame smaller than 1024 bytes with gcc. However,
      when compiling with clang, the functions are inlined more aggressively
      and combined again so we get
      
      net/openvswitch/datapath.c:1124:12: error: stack frame size of 1528 bytes in function 'ovs_flow_cmd_set' [-Werror,-Wframe-larger-than=]
      
      Marking both get_flow_actions() and ovs_nla_init_match_and_action()
      as 'noinline_for_stack' gives us the same behavior that we see with
      gcc, and no warning. Note that this does not mean we actually use
      less stack, as the functions call each other, and we still get
      three copies of the large 'struct sw_flow_key' type on the stack.
      
      The comment tells us that this was previously considered safe,
      presumably since the netlink parsing functions are called with
      a known backchain that does not also use a lot of stack space.
      
      Fixes: 9cc9a5cb ("datapath: Avoid using stack larger than 1024.")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26063790
    • Jakub Kicinski's avatar
      net/tls: add myself as a co-maintainer · 47b79bbb
      Jakub Kicinski authored
      I've been spending quite a bit of time fixing and
      preventing bit rot in the core TLS code. TLS seems
      to only be growing in importance, I'd like to help
      ensuring the quality of our implementation.
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47b79bbb
    • Andreas Schwab's avatar
      net: phy: mscc: initialize stats array · f972037e
      Andreas Schwab authored
      The memory allocated for the stats array may contain arbitrary data.
      
      Fixes: e4f9ba64 ("net: phy: mscc: add support for VSC8514 PHY.")
      Fixes: 00d70d8e ("net: phy: mscc: add support for VSC8574 PHY")
      Fixes: a5afc167 ("net: phy: mscc: add support for VSC8584 PHY")
      Fixes: f76178dc ("net: phy: mscc: add ethtool statistics counters")
      Signed-off-by: default avatarAndreas Schwab <schwab@suse.de>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f972037e
    • Arseny Solokha's avatar
      net: phylink: don't start and stop SGMII PHYs in SFP modules twice · c7fa7f56
      Arseny Solokha authored
      SFP modules connected using the SGMII interface have their own PHYs which
      are handled by the struct phylink's phydev field. On the other hand, for
      the modules connected using 1000Base-X interface that field is not set.
      
      Since commit ce0aa27f ("sfp: add sfp-bus to bridge between network
      devices and sfp cages") phylink_start() ends up setting the phydev field
      using the sfp-bus infrastructure, which eventually calls phy_start() on it,
      and then calling phy_start() again on the same phydev from phylink_start()
      itself. Similar call sequence holds for phylink_stop(), only in the reverse
      order. This results in WARNs during network interface bringup and shutdown
      when a copper SFP module is connected, as phy_start() and phy_stop() are
      called twice in a row for the same phy_device:
      
        % ip link set up dev eth0
        ------------[ cut here ]------------
        called from state UP
        WARNING: CPU: 1 PID: 155 at drivers/net/phy/phy.c:895 phy_start+0x74/0xc0
        Modules linked in:
        CPU: 1 PID: 155 Comm: backend Not tainted 5.2.0+ #1
        NIP:  c0227bf0 LR: c0227bf0 CTR: c004d224
        REGS: df547720 TRAP: 0700   Not tainted  (5.2.0+)
        MSR:  00029000 <CE,EE,ME>  CR: 24002822  XER: 00000000
      
        GPR00: c0227bf0 df5477d8 df5d7080 00000014 df9d2370 df9d5ac4 1f4eb000 00000001
        GPR08: c061fe58 00000000 00000000 df5477d8 0000003c 100c8768 00000000 00000000
        GPR16: df486a00 c046f1c8 c046eea0 00000000 c046e904 c0239604 db68449c 00000000
        GPR24: e9083204 00000000 00000001 db684460 e9083404 00000000 db6dce00 db6dcc00
        NIP [c0227bf0] phy_start+0x74/0xc0
        LR [c0227bf0] phy_start+0x74/0xc0
        Call Trace:
        [df5477d8] [c0227bf0] phy_start+0x74/0xc0 (unreliable)
        [df5477e8] [c023cad0] startup_gfar+0x398/0x3f4
        [df547828] [c023cf08] gfar_enet_open+0x364/0x374
        [df547898] [c029d870] __dev_open+0xe4/0x140
        [df5478c8] [c029db70] __dev_change_flags+0xf0/0x188
        [df5478f8] [c029dc28] dev_change_flags+0x20/0x54
        [df547918] [c02ae304] do_setlink+0x310/0x818
        [df547a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0
        [df547c28] [c02b222c] rtnl_newlink+0x48/0x68
        [df547c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c
        [df547c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0
        [df547cd8] [c02cba3c] netlink_unicast+0x114/0x19c
        [df547d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0
        [df547d58] [c027b668] sock_sendmsg_nosec+0x20/0x40
        [df547d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc
        [df547e98] [c027df7c] __sys_sendmsg+0x68/0x84
        [df547ef8] [c027e430] sys_socketcall+0x1a0/0x204
        [df547f38] [c000d1d8] ret_from_syscall+0x0/0x38
        --- interrupt: c01 at 0xfd4e030
            LR = 0xfd4e010
        Instruction dump:
        813f0188 38800000 2b890005 419d0014 3d40c046 5529103a 394aa208 7c8a482e
        3c60c046 3863a1b8 4cc63182 4be009a1 <0fe00000> 48000030 3c60c046 3863a1d0
        ---[ end trace d4c095aeaf6ea998 ]---
      
      and
      
        % ip link set down dev eth0
        ------------[ cut here ]------------
        called from state HALTED
        WARNING: CPU: 1 PID: 184 at drivers/net/phy/phy.c:858 phy_stop+0x3c/0x88
      
        <...>
      
        Call Trace:
        [df581788] [c0228450] phy_stop+0x3c/0x88 (unreliable)
        [df581798] [c022d548] sfp_sm_phy_detach+0x1c/0x44
        [df5817a8] [c022e8cc] sfp_sm_event+0x4b0/0x87c
        [df581848] [c022f04c] sfp_upstream_stop+0x34/0x44
        [df581858] [c0225608] phylink_stop+0x7c/0xe4
        [df581868] [c023c57c] stop_gfar+0x7c/0x94
        [df581888] [c023c5b8] gfar_close+0x24/0x94
        [df5818a8] [c0298688] __dev_close_many+0xdc/0xf8
        [df5818c8] [c029db58] __dev_change_flags+0xd8/0x188
        [df5818f8] [c029dc28] dev_change_flags+0x20/0x54
        [df581918] [c02ae304] do_setlink+0x310/0x818
        [df581a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0
        [df581c28] [c02b222c] rtnl_newlink+0x48/0x68
        [df581c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c
        [df581c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0
        [df581cd8] [c02cba3c] netlink_unicast+0x114/0x19c
        [df581d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0
        [df581d58] [c027b668] sock_sendmsg_nosec+0x20/0x40
        [df581d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc
        [df581e98] [c027df7c] __sys_sendmsg+0x68/0x84
        [df581ef8] [c027e430] sys_socketcall+0x1a0/0x204
        [df581f38] [c000d1d8] ret_from_syscall+0x0/0x38
      
        <...>
      
        ---[ end trace d4c095aeaf6ea999 ]---
      
      SFP modules with the 1000Base-X interface are not affected.
      
      Place explicit calls to phy_start() and phy_stop() before enabling or after
      disabling an attached SFP module, where phydev is not yet set (or is
      already unset), so they will be made only from the inside of sfp-bus, if
      needed.
      
      Fixes: 21796261 ("net: phy: warn if phy_start is called from invalid state")
      Signed-off-by: default avatarArseny Solokha <asolokha@kb.kras.ru>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7fa7f56
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-5.3-20190724' of... · 09ea2679
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-5.3-20190724' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2019-07-24
      
      this is a pull reqeust of 7 patches for net/master.
      
      The first patch is by Rasmus Villemoes add a missing netif_carrier_off() to
      register_candev() so that generic netdev trigger based LEDs are initially off.
      
      Nikita Yushchenko's patch for the rcar_canfd driver fixes a possible IRQ storm
      on high load.
      
      The patch by Weitao Hou for the mcp251x driver add missing error checking to
      the work queue allocation.
      
      Both Wen Yang's and Joakim Zhang's patch for the flexcan driver fix a problem
      with the stop-mode.
      
      Stephane Grosjean contributes a patch for the peak_usb driver to fix a
      potential double kfree_skb().
      
      The last patch is by YueHaibing and fixes the error path in can-gw's
      cgw_module_init() function.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09ea2679
    • Haishuang Yan's avatar
      ip6_gre: reload ipv6h in prepare_ip6gre_xmit_ipv6 · 3bc817d6
      Haishuang Yan authored
      Since ip6_tnl_parse_tlv_enc_lim() can call pskb_may_pull()
      which may change skb->data, so we need to re-load ipv6h at
      the right place.
      
      Fixes: 898b2979 ("ip6_gre: Refactor ip6gre xmit codes")
      Cc: William Tu <u9012063@gmail.com>
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Acked-by: default avatarWilliam Tu <u9012063@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bc817d6
    • Pavel Machek's avatar
      net/ipv4: cleanup error condition testing · c7148c03
      Pavel Machek authored
      Cleanup testing for error condition.
      Signed-off-by: default avatarPavel Machek <pavel@denx.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7148c03
    • YueHaibing's avatar
      can: gw: Fix error path of cgw_module_init · b7a14297
      YueHaibing authored
      This patch add error path for cgw_module_init to avoid possible crash if
      some error occurs.
      
      Fixes: c1aabdf3 ("can-gw: add netlink based CAN routing")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      b7a14297
    • Stephane Grosjean's avatar
      can: peak_usb: fix potential double kfree_skb() · fee6a892
      Stephane Grosjean authored
      When closing the CAN device while tx skbs are inflight, echo skb could
      be released twice. By calling close_candev() before unlinking all
      pending tx urbs, then the internal echo_skb[] array is fully and
      correctly cleared before the USB write callback and, therefore,
      can_get_echo_skb() are called, for each aborted URB.
      
      Fixes: bb478555 ("can: usb: PEAK-System Technik USB adapters driver core")
      Signed-off-by: default avatarStephane Grosjean <s.grosjean@peak-system.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      fee6a892
    • Joakim Zhang's avatar
      can: flexcan: fix stop mode acknowledgment · 5f186c25
      Joakim Zhang authored
      To enter stop mode, the CPU should manually assert a global Stop Mode
      request and check the acknowledgment asserted by FlexCAN. The CPU must
      only consider the FlexCAN in stop mode when both request and
      acknowledgment conditions are satisfied.
      
      Fixes: de3578c1 ("can: flexcan: add self wakeup support")
      Reported-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarJoakim Zhang <qiangqing.zhang@nxp.com>
      Cc: linux-stable <stable@vger.kernel.org> # >= v5.0
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      5f186c25
    • Wen Yang's avatar
      can: flexcan: fix an use-after-free in flexcan_setup_stop_mode() · e9f2a856
      Wen Yang authored
      The gpr_np variable is still being used in dev_dbg() after the
      of_node_put() call, which may result in use-after-free.
      
      Fixes: de3578c1 ("can: flexcan: add self wakeup support")
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: linux-stable <stable@vger.kernel.org> # >= v5.0
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      e9f2a856
    • Weitao Hou's avatar
      can: mcp251x: add error check when wq alloc failed · 375f7558
      Weitao Hou authored
      add error check when workqueue alloc failed, and remove redundant code
      to make it clear.
      
      Fixes: e0000163 ("can: Driver for the Microchip MCP251x SPI CAN controllers")
      Signed-off-by: default avatarWeitao Hou <houweitaoo@gmail.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Tested-by: default avatarSean Nyekjaer <sean@geanix.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      375f7558
    • Nikita Yushchenko's avatar
      can: rcar_canfd: fix possible IRQ storm on high load · d4b890ae
      Nikita Yushchenko authored
      We have observed rcar_canfd driver entering IRQ storm under high load,
      with following scenario:
      - rcar_canfd_global_interrupt() in entered due to Rx available,
      - napi_schedule_prep() is called, and sets NAPIF_STATE_SCHED in state
      - Rx fifo interrupts are masked,
      - rcar_canfd_global_interrupt() is entered again, this time due to
        error interrupt (e.g. due to overflow),
      - since scheduled napi poller has not yet executed, condition for calling
        napi_schedule_prep() from rcar_canfd_global_interrupt() remains true,
        thus napi_schedule_prep() gets called and sets NAPIF_STATE_MISSED flag
        in state,
      - later, napi poller function rcar_canfd_rx_poll() gets executed, and
        calls napi_complete_done(),
      - due to NAPIF_STATE_MISSED flag in state, this call does not clear
        NAPIF_STATE_SCHED flag from state,
      - on return from napi_complete_done(), rcar_canfd_rx_poll() unmasks Rx
        interrutps,
      - Rx interrupt happens, rcar_canfd_global_interrupt() gets called
        and calls napi_schedule_prep(),
      - since NAPIF_STATE_SCHED is set in state at this time, this call
        returns false,
      - due to that false return, rcar_canfd_global_interrupt() returns
        without masking Rx interrupt
      - and this results into IRQ storm: unmasked Rx interrupt happens again
        and again is misprocessed in the same way.
      
      This patch fixes that scenario by unmasking Rx interrupts only when
      napi_complete_done() returns true, which means it has cleared
      NAPIF_STATE_SCHED in state.
      
      Fixes: dd3bd23e ("can: rcar_canfd: Add Renesas R-Car CAN FD driver")
      Signed-off-by: default avatarNikita Yushchenko <nikita.yoush@cogentembedded.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      d4b890ae
    • Rasmus Villemoes's avatar
      can: dev: call netif_carrier_off() in register_candev() · c6384560
      Rasmus Villemoes authored
      CONFIG_CAN_LEDS is deprecated. When trying to use the generic netdev
      trigger as suggested, there's a small inconsistency with the link
      property: The LED is on initially, stays on when the device is brought
      up, and then turns off (as expected) when the device is brought down.
      
      Make sure the LED always reflects the state of the CAN device.
      Signed-off-by: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      c6384560
  4. 23 Jul, 2019 7 commits
    • Ilya Maximets's avatar
      libbpf: fix using uninitialized ioctl results · decb705e
      Ilya Maximets authored
      'channels.max_combined' initialized only on ioctl success and
      errno is only valid on ioctl failure.
      
      The code doesn't produce any runtime issues, but makes memory
      sanitizers angry:
      
       Conditional jump or move depends on uninitialised value(s)
          at 0x55C056F: xsk_get_max_queues (xsk.c:336)
          by 0x55C05B2: xsk_create_bpf_maps (xsk.c:354)
          by 0x55C089F: xsk_setup_xdp_prog (xsk.c:447)
          by 0x55C0E57: xsk_socket__create (xsk.c:601)
        Uninitialised value was created by a stack allocation
          at 0x55C04CD: xsk_get_max_queues (xsk.c:318)
      
      Additionally fixed warning on uninitialized bytes in ioctl arguments:
      
       Syscall param ioctl(SIOCETHTOOL) points to uninitialised byte(s)
          at 0x648D45B: ioctl (in /usr/lib64/libc-2.28.so)
          by 0x55C0546: xsk_get_max_queues (xsk.c:330)
          by 0x55C05B2: xsk_create_bpf_maps (xsk.c:354)
          by 0x55C089F: xsk_setup_xdp_prog (xsk.c:447)
          by 0x55C0E57: xsk_socket__create (xsk.c:601)
        Address 0x1ffefff378 is on thread 1's stack
        in frame #1, created by xsk_get_max_queues (xsk.c:318)
        Uninitialised value was created by a stack allocation
          at 0x55C04CD: xsk_get_max_queues (xsk.c:318)
      
      CC: Magnus Karlsson <magnus.karlsson@intel.com>
      Fixes: 1cad0788 ("libbpf: add support for using AF_XDP sockets")
      Signed-off-by: default avatarIlya Maximets <i.maximets@samsung.com>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      decb705e
    • Alexei Starovoitov's avatar
      Merge branch 'fix-gso_segs' · 7c8b87f0
      Alexei Starovoitov authored
      Eric Dumazet says:
      
      ====================
      First patch changes the kernel, second patch
      adds a new test.
      
      Note that other patches might be needed to take
      care of similar issues in sock_ops_convert_ctx_access()
      and SOCK_OPS_GET_FIELD()
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      7c8b87f0
    • Eric Dumazet's avatar
      selftests/bpf: add another gso_segs access · be69483b
      Eric Dumazet authored
      Use BPF_REG_1 for source and destination of gso_segs read,
      to exercise "bpf: fix access to skb_shared_info->gso_segs" fix.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Suggested-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      be69483b
    • Eric Dumazet's avatar
      bpf: fix access to skb_shared_info->gso_segs · 06a22d89
      Eric Dumazet authored
      It is possible we reach bpf_convert_ctx_access() with
      si->dst_reg == si->src_reg
      
      Therefore, we need to load BPF_REG_AX before eventually
      mangling si->src_reg.
      
      syzbot generated this x86 code :
         3:   55                      push   %rbp
         4:   48 89 e5                mov    %rsp,%rbp
         7:   48 81 ec 00 00 00 00    sub    $0x0,%rsp // Might be avoided ?
         e:   53                      push   %rbx
         f:   41 55                   push   %r13
        11:   41 56                   push   %r14
        13:   41 57                   push   %r15
        15:   6a 00                   pushq  $0x0
        17:   31 c0                   xor    %eax,%eax
        19:   48 8b bf c0 00 00 00    mov    0xc0(%rdi),%rdi
        20:   44 8b 97 bc 00 00 00    mov    0xbc(%rdi),%r10d
        27:   4c 01 d7                add    %r10,%rdi
        2a:   48 0f b7 7f 06          movzwq 0x6(%rdi),%rdi // Crash
        2f:   5b                      pop    %rbx
        30:   41 5f                   pop    %r15
        32:   41 5e                   pop    %r14
        34:   41 5d                   pop    %r13
        36:   5b                      pop    %rbx
        37:   c9                      leaveq
        38:   c3                      retq
      
      Fixes: d9ff286a ("bpf: allow BPF programs access skb_shared_info->gso_segs field")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      06a22d89
    • Andy Shevchenko's avatar
      net: thunderx: Use fwnode_get_mac_address() · d86afb89
      Andy Shevchenko authored
      Replace the custom implementation with fwnode_get_mac_address,
      which works on both DT and ACPI platforms.
      
      While here, replace memcpy() by ether_addr_copy().
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d86afb89
    • Ilya Leoshkevich's avatar
      bpf: fix narrower loads on s390 · d9b8aada
      Ilya Leoshkevich authored
      The very first check in test_pkt_md_access is failing on s390, which
      happens because loading a part of a struct __sk_buff field produces
      an incorrect result.
      
      The preprocessed code of the check is:
      
      {
      	__u8 tmp = *((volatile __u8 *)&skb->len +
      		((sizeof(skb->len) - sizeof(__u8)) / sizeof(__u8)));
      	if (tmp != ((*(volatile __u32 *)&skb->len) & 0xFF)) return 2;
      };
      
      clang generates the following code for it:
      
            0:	71 21 00 03 00 00 00 00	r2 = *(u8 *)(r1 + 3)
            1:	61 31 00 00 00 00 00 00	r3 = *(u32 *)(r1 + 0)
            2:	57 30 00 00 00 00 00 ff	r3 &= 255
            3:	5d 23 00 1d 00 00 00 00	if r2 != r3 goto +29 <LBB0_10>
      
      Finally, verifier transforms it to:
      
        0: (61) r2 = *(u32 *)(r1 +104)
        1: (bc) w2 = w2
        2: (74) w2 >>= 24
        3: (bc) w2 = w2
        4: (54) w2 &= 255
        5: (bc) w2 = w2
      
      The problem is that when verifier emits the code to replace a partial
      load of a struct __sk_buff field (*(u8 *)(r1 + 3)) with a full load of
      struct sk_buff field (*(u32 *)(r1 + 104)), an optional shift and a
      bitwise AND, it assumes that the machine is little endian and
      incorrectly decides to use a shift.
      
      Adjust shift count calculation to account for endianness.
      
      Fixes: 31fd8581 ("bpf: permits narrower load from bpf program context fields")
      Signed-off-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      d9b8aada
    • Takashi Iwai's avatar
      sky2: Disable MSI on ASUS P6T · a261e379
      Takashi Iwai authored
      The onboard sky2 NIC on ASUS P6T WS PRO doesn't work after PM resume
      due to the infamous IRQ problem.  Disabling MSI works around it, so
      let's add it to the blacklist.
      
      Unfortunately the BIOS on the machine doesn't fill the standard
      DMI_SYS_* entry, so we pick up DMI_BOARD_* entries instead.
      
      BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1142496Reported-and-tested-by: default avatarMarcus Seyfarth <m.seyfarth@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a261e379