1. 25 May, 2021 3 commits
  2. 24 May, 2021 19 commits
    • George McCollister's avatar
      net: dsa: microchip: enable phy errata workaround on 9567 · 8c42a497
      George McCollister authored
      Also enable phy errata workaround on 9567 since has the same errata as
      the 9477 according to the manufacture's documentation.
      Signed-off-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c42a497
    • Pavel Skripkin's avatar
      net: usb: fix memory leak in smsc75xx_bind · 46a8b29c
      Pavel Skripkin authored
      Syzbot reported memory leak in smsc75xx_bind().
      The problem was is non-freed memory in case of
      errors after memory allocation.
      
      backtrace:
        [<ffffffff84245b62>] kmalloc include/linux/slab.h:556 [inline]
        [<ffffffff84245b62>] kzalloc include/linux/slab.h:686 [inline]
        [<ffffffff84245b62>] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460
        [<ffffffff82b5b2e6>] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728
      
      Fixes: d0cad871 ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
      Cc: stable@kernel.vger.org
      Reported-and-tested-by: syzbot+b558506ba8165425fee2@syzkaller.appspotmail.com
      Signed-off-by: default avatarPavel Skripkin <paskripkin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      46a8b29c
    • George McCollister's avatar
      net: hsr: fix mac_len checks · 48b491a5
      George McCollister authored
      Commit 2e9f6093 ("net: hsr: check skb can contain struct hsr_ethhdr
      in fill_frame_info") added the following which resulted in -EINVAL
      always being returned:
      	if (skb->mac_len < sizeof(struct hsr_ethhdr))
      		return -EINVAL;
      
      mac_len was not being set correctly so this check completely broke
      HSR/PRP since it was always 14, not 20.
      
      Set mac_len correctly and modify the mac_len checks to test in the
      correct places since sometimes it is legitimately 14.
      
      Fixes: 2e9f6093 ("net: hsr: check skb can contain struct hsr_ethhdr in fill_frame_info")
      Signed-off-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48b491a5
    • Saubhik Mukherjee's avatar
      net: appletalk: cops: Fix data race in cops_probe1 · a4dd4fc6
      Saubhik Mukherjee authored
      In cops_probe1(), there is a write to dev->base_addr after requesting an
      interrupt line and registering the interrupt handler cops_interrupt().
      The handler might be called in parallel to handle an interrupt.
      cops_interrupt() tries to read dev->base_addr leading to a potential
      data race. So write to dev->base_addr before calling request_irq().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarSaubhik Mukherjee <saubhik.mukherjee@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4dd4fc6
    • David S. Miller's avatar
      Merge branch 'sja1105-fixes' · 93c5d741
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Fixes for SJA1105 DSA driver
      
      This series contains some minor fixes in the sja1105 driver:
      - improved error handling in the probe path
      - rejecting an invalid phy-mode specified in the device tree
      - register access fix for SJA1105P/Q/R/S for the virtual links through
        the dynamic reconfiguration interface
      - handling 2 bridge VLANs where the second is supposed to overwrite the
        first
      - making sure that the lack of a pvid results in the actual dropping of
        untagged traffic
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93c5d741
    • Vladimir Oltean's avatar
      net: dsa: sja1105: update existing VLANs from the bridge VLAN list · b38e659d
      Vladimir Oltean authored
      When running this sequence of operations:
      
      ip link add br0 type bridge vlan_filtering 1
      ip link set swp4 master br0
      bridge vlan add dev swp4 vid 1
      
      We observe the traffic sent on swp4 is still untagged, even though the
      bridge has overwritten the existing VLAN entry:
      
      port    vlan ids
      swp4     1 PVID
      
      br0      1 PVID Egress Untagged
      
      This happens because we didn't consider that the 'bridge vlan add'
      command just overwrites VLANs like it's nothing. We treat the 'vid 1
      pvid untagged' and the 'vid 1' as two separate VLANs, and the first
      still has precedence when calling sja1105_build_vlan_table. Obviously
      there is a disagreement regarding semantics, and we end up doing
      something unexpected from the PoV of the bridge.
      
      Let's actually consider an "existing VLAN" to be one which is on the
      same port, and has the same VLAN ID, as one we already have, and update
      it if it has different flags than we do.
      
      The first blamed commit is the one introducing the bug, the second one
      is the latest on top of which the bugfix still applies.
      
      Fixes: ec5ae610 ("net: dsa: sja1105: save/restore VLANs using a delta commit method")
      Fixes: 5899ee36 ("net: dsa: tag_8021q: add a context structure")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b38e659d
    • Vladimir Oltean's avatar
      net: dsa: sja1105: use 4095 as the private VLAN for untagged traffic · ed040abc
      Vladimir Oltean authored
      One thing became visible when writing the blamed commit, and that was
      that STP and PTP frames injected by net/dsa/tag_sja1105.c using the
      deferred xmit mechanism are always classified to the pvid of the CPU
      port, regardless of whatever VLAN there might be in these packets.
      
      So a decision needed to be taken regarding the mechanism through which
      we should ensure that delivery of STP and PTP traffic is possible when
      we are in a VLAN awareness mode that involves tag_8021q. This is because
      tag_8021q is not concerned with managing the pvid of the CPU port, since
      as far as tag_8021q is concerned, no traffic should be sent as untagged
      from the CPU port. So we end up not actually having a pvid on the CPU
      port if we only listen to tag_8021q, and unless we do something about it.
      
      The decision taken at the time was to keep VLAN 1 in the list of
      priv->dsa_8021q_vlans, and make it a pvid of the CPU port. This ensures
      that STP and PTP frames can always be sent to the outside world.
      
      However there is a problem. If we do the following while we are in
      the best_effort_vlan_filtering=true mode:
      
      ip link add br0 type bridge vlan_filtering 1
      ip link set swp2 master br0
      bridge vlan del dev swp2 vid 1
      
      Then untagged and pvid-tagged frames should be dropped. But we observe
      that they aren't, and this is because of the precaution we took that VID
      1 is always installed on all ports.
      
      So clearly VLAN 1 is not good for this purpose. What about VLAN 0?
      Well, VLAN 0 is managed by the 8021q module, and that module wants to
      ensure that 802.1p tagged frames are always received by a port, and are
      always transmitted as VLAN-tagged (with VLAN ID 0). Whereas we want our
      STP and PTP frames to be untagged if the stack sent them as untagged -
      we don't want the driver to just decide out of the blue that it adds
      VID 0 to some packets.
      
      So what to do?
      
      Well, there is one other VLAN that is reserved, and that is 4095:
      $ ip link add link swp2 name swp2.4095 type vlan id 4095
      Error: 8021q: Invalid VLAN id.
      $ bridge vlan add dev swp2 vid 4095
      Error: bridge: Vlan id is invalid.
      
      After we made this change, VLAN 1 is indeed forwarded and/or dropped
      according to the bridge VLAN table, there are no further alterations
      done by the sja1105 driver.
      
      Fixes: ec5ae610 ("net: dsa: sja1105: save/restore VLANs using a delta commit method")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed040abc
    • Vladimir Oltean's avatar
      net: dsa: sja1105: error out on unsupported PHY mode · 6729188d
      Vladimir Oltean authored
      The driver continues probing when a port is configured for an
      unsupported PHY interface type, instead it should stop.
      
      Fixes: 8aa9ebcc ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6729188d
    • Vladimir Oltean's avatar
      net: dsa: sja1105: add error handling in sja1105_setup() · cec279a8
      Vladimir Oltean authored
      If any of sja1105_static_config_load(), sja1105_clocking_setup() or
      sja1105_devlink_setup() fails, we can't just return in the middle of
      sja1105_setup() or memory will leak. Add a cleanup path.
      
      Fixes: 0a7bdbc2 ("net: dsa: sja1105: move devlink param code to sja1105_devlink.c")
      Fixes: 8aa9ebcc ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cec279a8
    • Vladimir Oltean's avatar
      net: dsa: sja1105: call dsa_unregister_switch when allocating memory fails · dc596e3f
      Vladimir Oltean authored
      Unlike other drivers which pretty much end their .probe() execution with
      dsa_register_switch(), the sja1105 does some extra stuff. When that
      fails with -ENOMEM, the driver is quick to return that, forgetting to
      call dsa_unregister_switch(). Not critical, but a bug nonetheless.
      
      Fixes: 4d752508 ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc")
      Fixes: a68578c2 ("net: dsa: Make deferred_xmit private to sja1105")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc596e3f
    • Vladimir Oltean's avatar
      net: dsa: sja1105: fix VL lookup command packing for P/Q/R/S · ba61cf16
      Vladimir Oltean authored
      At the beginning of the sja1105_dynamic_config.c file there is a diagram
      of the dynamic config interface layout:
      
       packed_buf
      
       |
       V
       +-----------------------------------------+------------------+
       |              ENTRY BUFFER               |  COMMAND BUFFER  |
       +-----------------------------------------+------------------+
      
       <----------------------- packed_size ------------------------>
      
      So in order to pack/unpack the command bits into the buffer,
      sja1105_vl_lookup_cmd_packing must first advance the buffer pointer by
      the length of the entry. This is similar to what the other *cmd_packing
      functions do.
      
      This bug exists because the command packing function for P/Q/R/S was
      copied from the E/T generation, and on E/T, the command was actually
      embedded within the entry buffer itself.
      
      Fixes: 94f94d4a ("net: dsa: sja1105: add static tables for virtual links")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba61cf16
    • Johan Hovold's avatar
      net: hso: fix control-request directions · 1a6e9a9c
      Johan Hovold authored
      The direction of the pipe argument must match the request-type direction
      bit or control requests may fail depending on the host-controller-driver
      implementation.
      
      Fix the tiocmset and rfkill requests which erroneously used
      usb_rcvctrlpipe().
      
      Fixes: 72dc1c09 ("HSO: add option hso driver")
      Cc: stable@vger.kernel.org      # 2.6.27
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a6e9a9c
    • Hayes Wang's avatar
      r8152: check the informaton of the device · 1a44fb38
      Hayes Wang authored
      Verify some fields of the USB descriptor to make sure the driver
      could be used by the device.
      
      Besides, remove the check of endpoint number in rtl8152_probe().
      usb_find_common_endpoints() includes it.
      
      BugLink: https://syzkaller.appspot.com/bug?id=912c9c373656996801b4de61f1e3cb326fe940aa
      Reported-by: syzbot+95afd23673f5dd295c57@syzkaller.appspotmail.com
      Fixes: c2198943 ("r8152: search the configuration of vendor mode")
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Reviewed-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a44fb38
    • Taehee Yoo's avatar
      sch_dsmark: fix a NULL deref in qdisc_reset() · 9b76eade
      Taehee Yoo authored
      If Qdisc_ops->init() is failed, Qdisc_ops->reset() would be called.
      When dsmark_init(Qdisc_ops->init()) is failed, it possibly doesn't
      initialize dsmark_qdisc_data->q. But dsmark_reset(Qdisc_ops->reset())
      uses dsmark_qdisc_data->q pointer wihtout any null checking.
      So, panic would occur.
      
      Test commands:
          sysctl net.core.default_qdisc=dsmark -w
          ip link add dummy0 type dummy
          ip link add vw0 link dummy0 type virt_wifi
          ip link set vw0 up
      
      Splat looks like:
      KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
      CPU: 3 PID: 684 Comm: ip Not tainted 5.12.0+ #910
      RIP: 0010:qdisc_reset+0x2b/0x680
      Code: 1f 44 00 00 48 b8 00 00 00 00 00 fc ff df 41 57 41 56 41 55 41 54
      55 48 89 fd 48 83 c7 18 53 48 89 fa 48 c1 ea 03 48 83 ec 20 <80> 3c 02
      00 0f 85 09 06 00 00 4c 8b 65 18 0f 1f 44 00 00 65 8b 1d
      RSP: 0018:ffff88800fda6bf8 EFLAGS: 00010282
      RAX: dffffc0000000000 RBX: ffff8880050ed800 RCX: 0000000000000000
      RDX: 0000000000000003 RSI: ffffffff99e34100 RDI: 0000000000000018
      RBP: 0000000000000000 R08: fffffbfff346b553 R09: fffffbfff346b553
      R10: 0000000000000001 R11: fffffbfff346b552 R12: ffffffffc0824940
      R13: ffff888109e83800 R14: 00000000ffffffff R15: ffffffffc08249e0
      FS:  00007f5042287680(0000) GS:ffff888119800000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000055ae1f4dbd90 CR3: 0000000006760002 CR4: 00000000003706e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ? rcu_read_lock_bh_held+0xa0/0xa0
       dsmark_reset+0x3d/0xf0 [sch_dsmark]
       qdisc_reset+0xa9/0x680
       qdisc_destroy+0x84/0x370
       qdisc_create_dflt+0x1fe/0x380
       attach_one_default_qdisc.constprop.41+0xa4/0x180
       dev_activate+0x4d5/0x8c0
       ? __dev_open+0x268/0x390
       __dev_open+0x270/0x390
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b76eade
    • Aditya Srivastava's avatar
      NFC: nfcmrvl: fix kernel-doc syntax in file headers · 4dd649d1
      Aditya Srivastava authored
      The opening comment mark '/**' is used for highlighting the beginning of
      kernel-doc comments.
      The header for drivers/nfc/nfcmrvl follows this syntax, but the content
      inside does not comply with kernel-doc.
      
      This line was probably not meant for kernel-doc parsing, but is parsed
      due to the presence of kernel-doc like comment syntax(i.e, '/**'), which
      causes unexpected warnings from kernel-doc.
      For e.g., running scripts/kernel-doc -none on drivers/nfc/nfcmrvl/spi.c
      causes warning:
      warning: expecting prototype for Marvell NFC(). Prototype was for SPI_WAIT_HANDSHAKE() instead
      
      Provide a simple fix by replacing such occurrences with general comment
      format, i.e. '/*', to prevent kernel-doc from parsing it.
      Signed-off-by: default avatarAditya Srivastava <yashsri421@gmail.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4dd649d1
    • DENG Qingfang's avatar
      net: dsa: mt7530: fix VLAN traffic leaks · 474a2dda
      DENG Qingfang authored
      PCR_MATRIX field was set to all 1's when VLAN filtering is enabled, but
      was not reset when it is disabled, which may cause traffic leaks:
      
      	ip link add br0 type bridge vlan_filtering 1
      	ip link add br1 type bridge vlan_filtering 1
      	ip link set swp0 master br0
      	ip link set swp1 master br1
      	ip link set br0 type bridge vlan_filtering 0
      	ip link set br1 type bridge vlan_filtering 0
      	# traffic in br0 and br1 will start leaking to each other
      
      As port_bridge_{add,del} have set up PCR_MATRIX properly, remove the
      PCR_MATRIX write from mt7530_port_set_vlan_aware.
      
      Fixes: 83163f7d ("net: dsa: mediatek: add VLAN support for MT7530")
      Signed-off-by: default avatarDENG Qingfang <dqfext@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      474a2dda
    • David S. Miller's avatar
      Merge branch 'fq_pie-fixes' · 835744e8
      David S. Miller authored
      Davide Caratti says:
      
      ====================
      two fixes for the fq_pie scheduler
      
      - patch 1/2 restores the possibility to use 65536 flows with fq_pie,
        preserving the fix for an endless loop in the control plane
      - patch 2/2 fixes an OOB access that can be observed in the traffic
        path of fq_pie scheduler, when the classification selects a flow
        beyond the allocated space.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      835744e8
    • Davide Caratti's avatar
      net/sched: fq_pie: fix OOB access in the traffic path · e70f7a11
      Davide Caratti authored
      the following script:
      
        # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2
        # tc qdisc add dev eth0 clsact
        # tc filter add dev eth0 egress matchall action skbedit priority 0x10002
        # ping 192.0.2.2 -I eth0 -c2 -w1 -q
      
      produces the following splat:
      
       BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
       Read of size 4 at addr ffff888171306924 by task ping/942
      
       CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ #441
       Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
       Call Trace:
        dump_stack+0x92/0xc1
        print_address_description.constprop.7+0x1a/0x150
        kasan_report.cold.13+0x7f/0x111
        fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
        __dev_queue_xmit+0x1034/0x2b10
        ip_finish_output2+0xc62/0x2120
        __ip_finish_output+0x553/0xea0
        ip_output+0x1ca/0x4d0
        ip_send_skb+0x37/0xa0
        raw_sendmsg+0x1c4b/0x2d00
        sock_sendmsg+0xdb/0x110
        __sys_sendto+0x1d7/0x2b0
        __x64_sys_sendto+0xdd/0x1b0
        do_syscall_64+0x3c/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xae
       RIP: 0033:0x7fe69735c3eb
       Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89
       RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
       RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb
       RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003
       RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010
       R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260
       R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0
      
       Allocated by task 917:
        kasan_save_stack+0x19/0x40
        __kasan_kmalloc+0x7f/0xa0
        __kmalloc_node+0x139/0x280
        fq_pie_init+0x555/0x8e8 [sch_fq_pie]
        qdisc_create+0x407/0x11b0
        tc_modify_qdisc+0x3c2/0x17e0
        rtnetlink_rcv_msg+0x346/0x8e0
        netlink_rcv_skb+0x120/0x380
        netlink_unicast+0x439/0x630
        netlink_sendmsg+0x719/0xbf0
        sock_sendmsg+0xe2/0x110
        ____sys_sendmsg+0x5ba/0x890
        ___sys_sendmsg+0xe9/0x160
        __sys_sendmsg+0xd3/0x170
        do_syscall_64+0x3c/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xae
      
       The buggy address belongs to the object at ffff888171306800
        which belongs to the cache kmalloc-256 of size 256
       The buggy address is located 36 bytes to the right of
        256-byte region [ffff888171306800, ffff888171306900)
       The buggy address belongs to the page:
       page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306
       head:00000000bcfb624e order:1 compound_mapcount:0
       flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
       raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40
       raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
       page dumped because: kasan: bad access detected
      
       Memory state around the buggy address:
        ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
       >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                      ^
        ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a
      valid flow: it's an address beyond the allocated memory.
      
      Fixes: ec97ecf1 ("net: sched: add Flow Queue PIE packet scheduler")
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e70f7a11
    • Davide Caratti's avatar
      net/sched: fq_pie: re-factor fix for fq_pie endless loop · 3a62fed2
      Davide Caratti authored
      the patch that fixed an endless loop in_fq_pie_init() was not considering
      that 65535 is a valid class id. The correct bugfix for this infinite loop
      is to change 'idx' to become an u32, like Colin proposed in the past [1].
      
      Fix this as follows:
       - restore 65536 as maximum possible values of 'flows_cnt'
       - use u32 'idx' when iterating on 'q->flows'
       - fix the TDC selftest
      
      This reverts commit bb2f930d.
      
      [1] https://lore.kernel.org/netdev/20210407163808.499027-1-colin.king@canonical.com/
      
      CC: Colin Ian King <colin.king@canonical.com>
      CC: stable@vger.kernel.org
      Fixes: bb2f930d ("net/sched: fix infinite loop in sch_fq_pie")
      Fixes: ec97ecf1 ("net: sched: add Flow Queue PIE packet scheduler")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a62fed2
  3. 23 May, 2021 3 commits
  4. 21 May, 2021 8 commits
  5. 20 May, 2021 7 commits
    • David S. Miller's avatar
      Merge branch 'stmmac-fixes' · 5cb4a593
      David S. Miller authored
      Joakim Zhang says:
      
      ====================
      net: fixes for stmmac
      
      Two clock fixes for stmmac driver.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5cb4a593
    • Joakim Zhang's avatar
      net: stmmac: fix system hang if change mac address after interface ifdown · 4691ffb1
      Joakim Zhang authored
      Fix system hang with below sequences:
      ~# ifconfig ethx down
      ~# ifconfig ethx hw ether xx:xx:xx:xx:xx:xx
      
      After ethx down, stmmac all clocks gated off and then register access causes
      system hang.
      
      Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver")
      Signed-off-by: default avatarJoakim Zhang <qiangqing.zhang@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4691ffb1
    • Joakim Zhang's avatar
      net: stmmac: correct clocks enabled in stmmac_vlan_rx_kill_vid() · b3dcb312
      Joakim Zhang authored
      This should be a mistake to fix conflicts when removing RFC tag to
      repost the patch.
      
      Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver")
      Signed-off-by: default avatarJoakim Zhang <qiangqing.zhang@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3dcb312
    • Zheyu Ma's avatar
      net/qla3xxx: fix schedule while atomic in ql_sem_spinlock · 13a6f315
      Zheyu Ma authored
      When calling the 'ql_sem_spinlock', the driver has already acquired the
      spin lock, so the driver should not call 'ssleep' in atomic context.
      
      This bug can be fixed by using 'mdelay' instead of 'ssleep'.
      
      The KASAN's log reveals it:
      
      [    3.238124 ] BUG: scheduling while atomic: swapper/0/1/0x00000002
      [    3.238748 ] 2 locks held by swapper/0/1:
      [    3.239151 ]  #0: ffff88810177b240 (&dev->mutex){....}-{3:3}, at:
      __device_driver_lock+0x41/0x60
      [    3.240026 ]  #1: ffff888107c60e28 (&qdev->hw_lock){....}-{2:2}, at:
      ql3xxx_probe+0x2aa/0xea0
      [    3.240873 ] Modules linked in:
      [    3.241187 ] irq event stamp: 460854
      [    3.241541 ] hardirqs last  enabled at (460853): [<ffffffff843051bf>]
      _raw_spin_unlock_irqrestore+0x4f/0x70
      [    3.242245 ] hardirqs last disabled at (460854): [<ffffffff843058ca>]
      _raw_spin_lock_irqsave+0x2a/0x70
      [    3.242245 ] softirqs last  enabled at (446076): [<ffffffff846002e4>]
      __do_softirq+0x2e4/0x4b1
      [    3.242245 ] softirqs last disabled at (446069): [<ffffffff811ba5e0>]
      irq_exit_rcu+0x100/0x110
      [    3.242245 ] Preemption disabled at:
      [    3.242245 ] [<ffffffff828ca5ba>] ql3xxx_probe+0x2aa/0xea0
      [    3.242245 ] Kernel panic - not syncing: scheduling while atomic
      [    3.242245 ] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
      5.13.0-rc1-00145
      -gee7dc339169-dirty #16
      [    3.242245 ] Call Trace:
      [    3.242245 ]  dump_stack+0xba/0xf5
      [    3.242245 ]  ? ql3xxx_probe+0x1f0/0xea0
      [    3.242245 ]  panic+0x15a/0x3f2
      [    3.242245 ]  ? vprintk+0x76/0x150
      [    3.242245 ]  ? ql3xxx_probe+0x2aa/0xea0
      [    3.242245 ]  __schedule_bug+0xae/0xe0
      [    3.242245 ]  __schedule+0x72e/0xa00
      [    3.242245 ]  schedule+0x43/0xf0
      [    3.242245 ]  schedule_timeout+0x28b/0x500
      [    3.242245 ]  ? del_timer_sync+0xf0/0xf0
      [    3.242245 ]  ? msleep+0x2f/0x70
      [    3.242245 ]  msleep+0x59/0x70
      [    3.242245 ]  ql3xxx_probe+0x307/0xea0
      [    3.242245 ]  ? _raw_spin_unlock_irqrestore+0x3a/0x70
      [    3.242245 ]  ? pci_device_remove+0x110/0x110
      [    3.242245 ]  local_pci_probe+0x45/0xa0
      [    3.242245 ]  pci_device_probe+0x12b/0x1d0
      [    3.242245 ]  really_probe+0x2a9/0x610
      [    3.242245 ]  driver_probe_device+0x90/0x1d0
      [    3.242245 ]  ? mutex_lock_nested+0x1b/0x20
      [    3.242245 ]  device_driver_attach+0x68/0x70
      [    3.242245 ]  __driver_attach+0x124/0x1b0
      [    3.242245 ]  ? device_driver_attach+0x70/0x70
      [    3.242245 ]  bus_for_each_dev+0xbb/0x110
      [    3.242245 ]  ? rdinit_setup+0x45/0x45
      [    3.242245 ]  driver_attach+0x27/0x30
      [    3.242245 ]  bus_add_driver+0x1eb/0x2a0
      [    3.242245 ]  driver_register+0xa9/0x180
      [    3.242245 ]  __pci_register_driver+0x82/0x90
      [    3.242245 ]  ? yellowfin_init+0x25/0x25
      [    3.242245 ]  ql3xxx_driver_init+0x23/0x25
      [    3.242245 ]  do_one_initcall+0x7f/0x3d0
      [    3.242245 ]  ? rdinit_setup+0x45/0x45
      [    3.242245 ]  ? rcu_read_lock_sched_held+0x4f/0x80
      [    3.242245 ]  kernel_init_freeable+0x2aa/0x301
      [    3.242245 ]  ? rest_init+0x2c0/0x2c0
      [    3.242245 ]  kernel_init+0x18/0x190
      [    3.242245 ]  ? rest_init+0x2c0/0x2c0
      [    3.242245 ]  ? rest_init+0x2c0/0x2c0
      [    3.242245 ]  ret_from_fork+0x1f/0x30
      [    3.242245 ] Dumping ftrace buffer:
      [    3.242245 ]    (ftrace buffer empty)
      [    3.242245 ] Kernel Offset: disabled
      [    3.242245 ] Rebooting in 1 seconds.
      Reported-by: default avatarZheyu Ma <zheyuma97@gmail.com>
      Signed-off-by: default avatarZheyu Ma <zheyuma97@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13a6f315
    • Aditya Srivastava's avatar
      net: encx24j600: fix kernel-doc syntax in file headers · 503c599a
      Aditya Srivastava authored
      The opening comment mark '/**' is used for highlighting the beginning of
      kernel-doc comments.
      The header for drivers/net/ethernet/microchip/encx24j600 files follows
      this syntax, but the content inside does not comply with kernel-doc.
      
      This line was probably not meant for kernel-doc parsing, but is parsed
      due to the presence of kernel-doc like comment syntax(i.e, '/**'), which
      causes unexpected warning from kernel-doc.
      For e.g., running scripts/kernel-doc -none
      drivers/net/ethernet/microchip/encx24j600_hw.h emits:
      warning: expecting prototype for h(). Prototype was for _ENCX24J600_HW_H() instead
      
      Provide a simple fix by replacing such occurrences with general comment
      format, i.e. '/*', to prevent kernel-doc from parsing it.
      Signed-off-by: default avatarAditya Srivastava <yashsri421@gmail.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      503c599a
    • Jesse Brandeburg's avatar
      ixgbe: fix large MTU request from VF · 63e39d29
      Jesse Brandeburg authored
      Check that the MTU value requested by the VF is in the supported
      range of MTUs before attempting to set the VF large packet enable,
      otherwise reject the request. This also avoids unnecessary
      register updates in the case of the 82599 controller.
      
      Fixes: 872844dd ("ixgbe: Enable jumbo frames support w/ SR-IOV")
      Co-developed-by: default avatarPiotr Skajewski <piotrx.skajewski@intel.com>
      Signed-off-by: default avatarPiotr Skajewski <piotrx.skajewski@intel.com>
      Signed-off-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Co-developed-by: default avatarMateusz Palczewski <mateusz.palczewski@intel.com>
      Signed-off-by: default avatarMateusz Palczewski <mateusz.palczewski@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63e39d29
    • David Matlack's avatar
      selftests: Add .gitignore for nci test suite · 8570e75a
      David Matlack authored
      Building the nci test suite produces a binary, nci_dev, that git then
      tries to track. Add a .gitignore file to tell git to ignore this binary.
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8570e75a