1. 03 Feb, 2022 1 commit
    • Hou Tao's avatar
      bpf: Use VM_MAP instead of VM_ALLOC for ringbuf · b293dcc4
      Hou Tao authored
      After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
      after mapping"), non-VM_ALLOC mappings will be marked as accessible
      in __get_vm_area_node() when KASAN is enabled. But now the flag for
      ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
      after vmap() returns. Because the ringbuf area is created by mapping
      allocated pages, so use VM_MAP instead.
      
      After the change, info in /proc/vmallocinfo also changes from
        [start]-[end]   24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
      to
        [start]-[end]   24576 ringbuf_map_alloc+0x171/0x290 vmap user
      
      Fixes: 457f4436 ("bpf: Implement BPF ring buffer and verifier support for it")
      Reported-by: syzbot+5ad567a418794b9b5983@syzkaller.appspotmail.com
      Signed-off-by: default avatarHou Tao <houtao1@huawei.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220202060158.6260-1-houtao1@huawei.com
      b293dcc4
  2. 01 Feb, 2022 1 commit
  3. 26 Jan, 2022 2 commits
  4. 25 Jan, 2022 1 commit
  5. 24 Jan, 2022 18 commits
    • Jakub Kicinski's avatar
      Merge tag 'linux-can-fixes-for-5.17-20220124' of... · e52984be
      Jakub Kicinski authored
      Merge tag 'linux-can-fixes-for-5.17-20220124' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2022-01-24
      
      The first patch updates the email address of Brian Silverman from his
      former employer to his private address.
      
      The next patch fixes DT bindings information for the tcan4x5x SPI CAN
      driver.
      
      The following patch targets the m_can driver and fixes the
      introduction of FIFO bulk read support.
      
      Another patch for the tcan4x5x driver, which fixes the max register
      value for the regmap config.
      
      The last patch for the flexcan driver marks the RX mailbox support for
      the MCF5441X as support.
      
      * tag 'linux-can-fixes-for-5.17-20220124' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
        can: flexcan: mark RX via mailboxes as supported on MCF5441X
        can: tcan4x5x: regmap: fix max register value
        can: m_can: m_can_fifo_{read,write}: don't read or write from/to FIFO if length is 0
        dt-bindings: can: tcan4x5x: fix mram-cfg RX FIFO config
        mailmap: update email address of Brian Silverman
      ====================
      
      Link: https://lore.kernel.org/r/20220124175955.3464134-1-mkl@pengutronix.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e52984be
    • Marc Kleine-Budde's avatar
      can: flexcan: mark RX via mailboxes as supported on MCF5441X · f04aefd4
      Marc Kleine-Budde authored
      Most flexcan IP cores support 2 RX modes:
      - FIFO
      - mailbox
      
      The flexcan IP core on the MCF5441X cannot receive CAN RTR messages
      via mailboxes. However the mailbox mode is more performant. The commit
      
      | 1c45f577 ("can: flexcan: add ethtool support to change rx-rtr setting during runtime")
      
      added support to switch from FIFO to mailbox mode on these cores.
      
      After testing the mailbox mode on the MCF5441X by Angelo Dureghello,
      this patch marks it (without RTR capability) as supported. Further the
      IP core overview table is updated, that RTR reception via mailboxes is
      not supported.
      
      Link: https://lore.kernel.org/all/20220121084425.3141218-1-mkl@pengutronix.deTested-by: default avatarAngelo Dureghello <angelo@kernel-space.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      f04aefd4
    • Marc Kleine-Budde's avatar
      can: tcan4x5x: regmap: fix max register value · e59986de
      Marc Kleine-Budde authored
      The MRAM of the tcan4x5x has a size of 2K and starts at 0x8000. There
      are no further registers in the tcan4x5x making 0x87fc the biggest
      addressable register.
      
      This patch fixes the max register value of the regmap config from
      0x8ffc to 0x87fc.
      
      Fixes: 6e1caaf8 ("can: tcan4x5x: fix max register value")
      Link: https://lore.kernel.org/all/20220119064011.2943292-1-mkl@pengutronix.deSigned-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      e59986de
    • Marc Kleine-Budde's avatar
      can: m_can: m_can_fifo_{read,write}: don't read or write from/to FIFO if length is 0 · db72589c
      Marc Kleine-Budde authored
      In order to optimize FIFO access, especially on m_can cores attached
      to slow busses like SPI, in patch
      
      | e3938177 ("can: m_can: Disable IRQs on FIFO bus errors")
      
      bulk read/write support has been added to the m_can_fifo_{read,write}
      functions.
      
      That change leads to the tcan driver to call
      regmap_bulk_{read,write}() with a length of 0 (for CAN frames with 0
      data length). regmap treats this as an error:
      
      | tcan4x5x spi1.0 tcan4x5x0: FIFO write returned -22
      
      This patch fixes the problem by not calling the
      cdev->ops->{read,write)_fifo() in case of a 0 length read/write.
      
      Fixes: e3938177 ("can: m_can: Disable IRQs on FIFO bus errors")
      Link: https://lore.kernel.org/all/20220114155751.2651888-1-mkl@pengutronix.de
      Cc: stable@vger.kernel.org
      Cc: Matt Kline <matt@bitbashing.io>
      Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com>
      Reported-by: default avatarMichael Anochin <anochin@photo-meter.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      db72589c
    • Marc Kleine-Budde's avatar
      dt-bindings: can: tcan4x5x: fix mram-cfg RX FIFO config · 17a30422
      Marc Kleine-Budde authored
      This tcan4x5x only comes with 2K of MRAM, a RX FIFO with a dept of 32
      doesn't fit into the MRAM. Use a depth of 16 instead.
      
      Fixes: 4edd396a ("dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver")
      Link: https://lore.kernel.org/all/20220119062951.2939851-1-mkl@pengutronix.deSigned-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      17a30422
    • Marc Kleine-Budde's avatar
      mailmap: update email address of Brian Silverman · 984d1eff
      Marc Kleine-Budde authored
      Brian Silverman's address at bluerivertech.com is not valid anymore,
      use Brian's private email address instead.
      
      Link: https://lore.kernel.org/all/20220110082359.2019735-1-mkl@pengutronix.de
      Cc: Brian Silverman <bsilver16384@gmail.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      984d1eff
    • Jisheng Zhang's avatar
      net: stmmac: remove unused members in struct stmmac_priv · de8a820d
      Jisheng Zhang authored
      The tx_coalesce and mii_irq are not used at all now, so remove them.
      Signed-off-by: default avatarJisheng Zhang <jszhang@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de8a820d
    • Christophe JAILLET's avatar
      net: atlantic: Use the bitmap API instead of hand-writing it · ebe0582b
      Christophe JAILLET authored
      Simplify code by using bitmap_weight() and bitmap_zero() instead of
      hand-writing these functions.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Reviewed-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebe0582b
    • Xin Long's avatar
      ping: fix the sk_bound_dev_if match in ping_lookup · 2afc3b5a
      Xin Long authored
      When 'ping' changes to use PING socket instead of RAW socket by:
      
         # sysctl -w net.ipv4.ping_group_range="0 100"
      
      the selftests 'router_broadcast.sh' will fail, as such command
      
        # ip vrf exec vrf-h1 ping -I veth0 198.51.100.255 -b
      
      can't receive the response skb by the PING socket. It's caused by mismatch
      of sk_bound_dev_if and dif in ping_rcv() when looking up the PING socket,
      as dif is vrf-h1 if dif's master was set to vrf-h1.
      
      This patch is to fix this regression by also checking the sk_bound_dev_if
      against sdif so that the packets can stil be received even if the socket
      is not bound to the vrf device but to the real iif.
      
      Fixes: c319b4d7 ("net: ipv4: add IPPROTO_ICMP socket kind")
      Reported-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2afc3b5a
    • Wen Gu's avatar
      net/smc: Transitional solution for clcsock race issue · c0bf3d8a
      Wen Gu authored
      We encountered a crash in smc_setsockopt() and it is caused by
      accessing smc->clcsock after clcsock was released.
      
       BUG: kernel NULL pointer dereference, address: 0000000000000020
       #PF: supervisor read access in kernel mode
       #PF: error_code(0x0000) - not-present page
       PGD 0 P4D 0
       Oops: 0000 [#1] PREEMPT SMP PTI
       CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E     5.16.0-rc4+ #53
       RIP: 0010:smc_setsockopt+0x59/0x280 [smc]
       Call Trace:
        <TASK>
        __sys_setsockopt+0xfc/0x190
        __x64_sys_setsockopt+0x20/0x30
        do_syscall_64+0x34/0x90
        entry_SYSCALL_64_after_hwframe+0x44/0xae
       RIP: 0033:0x7f16ba83918e
        </TASK>
      
      This patch tries to fix it by holding clcsock_release_lock and
      checking whether clcsock has already been released before access.
      
      In case that a crash of the same reason happens in smc_getsockopt()
      or smc_switch_to_fallback(), this patch also checkes smc->clcsock
      in them too. And the caller of smc_switch_to_fallback() will identify
      whether fallback succeeds according to the return value.
      
      Fixes: fd57770d ("net/smc: wait for pending work before clcsock release_sock")
      Link: https://lore.kernel.org/lkml/5dd7ffd1-28e2-24cc-9442-1defec27375e@linux.ibm.com/T/Signed-off-by: default avatarWen Gu <guwen@linux.alibaba.com>
      Acked-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0bf3d8a
    • Sukadev Bhattiprolu's avatar
      ibmvnic: remove unused ->wait_capability · 3a5d9db7
      Sukadev Bhattiprolu authored
      With previous bug fix, ->wait_capability flag is no longer needed and can
      be removed.
      
      Fixes: 249168ad ("ibmvnic: Make CRQ interrupt tasklet wait for all capabilities crqs")
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Reviewed-by: default avatarDany Madden <drt@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a5d9db7
    • Sukadev Bhattiprolu's avatar
      ibmvnic: don't spin in tasklet · 48079e7f
      Sukadev Bhattiprolu authored
      ibmvnic_tasklet() continuously spins waiting for responses to all
      capability requests. It does this to avoid encountering an error
      during initialization of the vnic. However if there is a bug in the
      VIOS and we do not receive a response to one or more queries the
      tasklet ends up spinning continuously leading to hard lock ups.
      
      If we fail to receive a message from the VIOS it is reasonable to
      timeout the login attempt rather than spin indefinitely in the tasklet.
      
      Fixes: 249168ad ("ibmvnic: Make CRQ interrupt tasklet wait for all capabilities crqs")
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Reviewed-by: default avatarDany Madden <drt@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48079e7f
    • Sukadev Bhattiprolu's avatar
      ibmvnic: init ->running_cap_crqs early · 151b6a5c
      Sukadev Bhattiprolu authored
      We use ->running_cap_crqs to determine when the ibmvnic_tasklet() should
      send out the next protocol message type. i.e when we get back responses
      to all our QUERY_CAPABILITY CRQs we send out REQUEST_CAPABILITY crqs.
      Similiary, when we get responses to all the REQUEST_CAPABILITY crqs, we
      send out the QUERY_IP_OFFLOAD CRQ.
      
      We currently increment ->running_cap_crqs as we send out each CRQ and
      have the ibmvnic_tasklet() send out the next message type, when this
      running_cap_crqs count drops to 0.
      
      This assumes that all the CRQs of the current type were sent out before
      the count drops to 0. However it is possible that we send out say 6 CRQs,
      get preempted and receive all the 6 responses before we send out the
      remaining CRQs. This can result in ->running_cap_crqs count dropping to
      zero before all messages of the current type were sent and we end up
      sending the next protocol message too early.
      
      Instead initialize the ->running_cap_crqs upfront so the tasklet will
      only send the next protocol message after all responses are received.
      
      Use the cap_reqs local variable to also detect any discrepancy (either
      now or in future) in the number of capability requests we actually send.
      
      Currently only send_query_cap() is affected by this behavior (of sending
      next message early) since it is called from the worker thread (during
      reset) and from application thread (during ->ndo_open()) and they can be
      preempted. send_request_cap() is only called from the tasklet  which
      processes CRQ responses sequentially, is not be affected.  But to
      maintain the existing symmtery with send_query_capability() we update
      send_request_capability() also.
      
      Fixes: 249168ad ("ibmvnic: Make CRQ interrupt tasklet wait for all capabilities crqs")
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Reviewed-by: default avatarDany Madden <drt@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      151b6a5c
    • Sukadev Bhattiprolu's avatar
      ibmvnic: Allow extra failures before disabling · db9f0e8b
      Sukadev Bhattiprolu authored
      If auto-priority-failover (APF) is enabled and there are at least two
      backing devices of different priorities, some resets like fail-over,
      change-param etc can cause at least two back to back failovers. (Failover
      from high priority backing device to lower priority one and then back
      to the higher priority one if that is still functional).
      
      Depending on the timimg of the two failovers it is possible to trigger
      a "hard" reset and for the hard reset to fail due to failovers. When this
      occurs, the driver assumes that the network is unstable and disables the
      VNIC for a 60-second "settling time". This in turn can cause the ethtool
      command to fail with "No such device" while the vnic automatically recovers
      a little while later.
      
      Given that it's possible to have two back to back failures, allow for extra
      failures before disabling the vnic for the settling time.
      
      Fixes: f15fde9d ("ibmvnic: delay next reset if hard reset fails")
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Reviewed-by: default avatarDany Madden <drt@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db9f0e8b
    • Jakub Kicinski's avatar
      ipv4: fix ip option filtering for locally generated fragments · 27a8caa5
      Jakub Kicinski authored
      During IP fragmentation we sanitize IP options. This means overwriting
      options which should not be copied with NOPs. Only the first fragment
      has the original, full options.
      
      ip_fraglist_prepare() copies the IP header and options from previous
      fragment to the next one. Commit 19c3401a ("net: ipv4: place control
      buffer handling away from fragmentation iterators") moved sanitizing
      options before ip_fraglist_prepare() which means options are sanitized
      and then overwritten again with the old values.
      
      Fixing this is not enough, however, nor did the sanitization work
      prior to aforementioned commit.
      
      ip_options_fragment() (which does the sanitization) uses ipcb->opt.optlen
      for the length of the options. ipcb->opt of fragments is not populated
      (it's 0), only the head skb has the state properly built. So even when
      called at the right time ip_options_fragment() does nothing. This seems
      to date back all the way to v2.5.44 when the fast path for pre-fragmented
      skbs had been introduced. Prior to that ip_options_build() would have been
      called for every fragment (in fact ever since v2.5.44 the fragmentation
      handing in ip_options_build() has been dead code, I'll clean it up in
      -next).
      
      In the original patch (see Link) caixf mentions fixing the handling
      for fragments other than the second one, but I'm not sure how _any_
      fragment could have had their options sanitized with the code
      as it stood.
      
      Tested with python (MTU on lo lowered to 1000 to force fragmentation):
      
        import socket
        s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        s.setsockopt(socket.IPPROTO_IP, socket.IP_OPTIONS,
                     bytearray([7,4,5,192, 20|0x80,4,1,0]))
        s.sendto(b'1'*2000, ('127.0.0.1', 1234))
      
      Before:
      
      IP (tos 0x0, ttl 64, id 1053, offset 0, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
          localhost.36500 > localhost.search-agent: UDP, length 2000
      IP (tos 0x0, ttl 64, id 1053, offset 968, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
          localhost > localhost: udp
      IP (tos 0x0, ttl 64, id 1053, offset 1936, flags [none], proto UDP (17), length 100, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
          localhost > localhost: udp
      
      After:
      
      IP (tos 0x0, ttl 96, id 42549, offset 0, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
          localhost.51607 > localhost.search-agent: UDP, bad length 2000 > 960
      IP (tos 0x0, ttl 96, id 42549, offset 968, flags [+], proto UDP (17), length 996, options (NOP,NOP,NOP,NOP,RA value 256))
          localhost > localhost: udp
      IP (tos 0x0, ttl 96, id 42549, offset 1936, flags [none], proto UDP (17), length 100, options (NOP,NOP,NOP,NOP,RA value 256))
          localhost > localhost: udp
      
      RA (20 | 0x80) is now copied as expected, RR (7) is "NOPed out".
      
      Link: https://lore.kernel.org/netdev/20220107080559.122713-1-ooppublic@163.com/
      Fixes: 19c3401a ("net: ipv4: place control buffer handling away from fragmentation iterators")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarcaixf <ooppublic@163.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27a8caa5
    • Jianguo Wu's avatar
      net-procfs: show net devices bound packet types · 1d10f8a1
      Jianguo Wu authored
      After commit:7866a621 ("dev: add per net_device packet type chains"),
      we can not get packet types that are bound to a specified net device by
      /proc/net/ptype, this patch fix the regression.
      
      Run "tcpdump -i ens192 udp -nns0" Before and after apply this patch:
      
      Before:
        [root@localhost ~]# cat /proc/net/ptype
        Type Device      Function
        0800          ip_rcv
        0806          arp_rcv
        86dd          ipv6_rcv
      
      After:
        [root@localhost ~]# cat /proc/net/ptype
        Type Device      Function
        ALL  ens192   tpacket_rcv
        0800          ip_rcv
        0806          arp_rcv
        86dd          ipv6_rcv
      
      v1 -> v2:
        - fix the regression rather than adding new /proc API as
          suggested by Stephen Hemminger.
      
      Fixes: 7866a621 ("dev: add per net_device packet type chains")
      Signed-off-by: default avatarJianguo Wu <wujianguo@chinatelecom.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d10f8a1
    • Hangbin Liu's avatar
      bonding: use rcu_dereference_rtnl when get bonding active slave · aa603467
      Hangbin Liu authored
      bond_option_active_slave_get_rcu() should not be used in rtnl_mutex as it
      use rcu_dereference(). Replace to rcu_dereference_rtnl() so we also can use
      this function in rtnl protected context.
      
      With this update, we can rmeove the rcu_read_lock/unlock in
      bonding .ndo_eth_ioctl and .get_ts_info.
      Reported-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Fixes: 94dd016a ("bond: pass get_ts_info and SIOC[SG]HWTSTAMP ioctl to active device")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aa603467
    • Marek Behún's avatar
      net: sfp: ignore disabled SFP node · 2148927e
      Marek Behún authored
      Commit ce0aa27f ("sfp: add sfp-bus to bridge between network devices
      and sfp cages") added code which finds SFP bus DT node even if the node
      is disabled with status = "disabled". Because of this, when phylink is
      created, it ends with non-null .sfp_bus member, even though the SFP
      module is not probed (because the node is disabled).
      
      We need to ignore disabled SFP bus node.
      
      Fixes: ce0aa27f ("sfp: add sfp-bus to bridge between network devices and sfp cages")
      Signed-off-by: default avatarMarek Behún <kabel@kernel.org>
      Cc: stable@vger.kernel.org # 2203cbf2 ("net: sfp: move fwnode parsing into sfp-bus layer")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2148927e
  6. 22 Jan, 2022 3 commits
  7. 21 Jan, 2022 14 commits