1. 04 Mar, 2021 27 commits
  2. 03 Mar, 2021 7 commits
    • Jakub Kicinski's avatar
      docs: networking: drop special stable handling · dbbe7c96
      Jakub Kicinski authored
      Leave it to Greg.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dbbe7c96
    • Ong Boon Leong's avatar
      net: stmmac: fix incorrect DMA channel intr enable setting of EQoS v4.10 · 879c348c
      Ong Boon Leong authored
      We introduce dwmac410_dma_init_channel() here for both EQoS v4.10 and
      above which use different DMA_CH(n)_Interrupt_Enable bit definitions for
      NIE and AIE.
      
      Fixes: 48863ce5 ("stmmac: add DMA support for GMAC 4.xx")
      Signed-off-by: default avatarOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: default avatarRamesh Babu B <ramesh.babu.b@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      879c348c
    • Michal Suchanek's avatar
      ibmvnic: Fix possibly uninitialized old_num_tx_queues variable warning. · 6881b07f
      Michal Suchanek authored
      GCC 7.5 reports:
      ../drivers/net/ethernet/ibm/ibmvnic.c: In function 'ibmvnic_reset_init':
      ../drivers/net/ethernet/ibm/ibmvnic.c:5373:51: warning: 'old_num_tx_queues' may be used uninitialized in this function [-Wmaybe-uninitialized]
      ../drivers/net/ethernet/ibm/ibmvnic.c:5373:6: warning: 'old_num_rx_queues' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      The variable is initialized only if(reset) and used only if(reset &&
      something) so this is a false positive. However, there is no reason to
      not initialize the variables unconditionally avoiding the warning.
      
      Fixes: 635e442f ("ibmvnic: merge ibmvnic_reset_init and ibmvnic_init")
      Signed-off-by: default avatarMichal Suchanek <msuchanek@suse.de>
      Reviewed-by: default avatarSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6881b07f
    • Dan Carpenter's avatar
      octeontx2-af: cn10k: fix an array overflow in is_lmac_valid() · 2378b2c9
      Dan Carpenter authored
      The value of "lmac_id" can be controlled by the user and if it is larger
      then the number of bits in long then it reads outside the bitmap.
      The highest valid value is less than MAX_LMAC_PER_CGX (4).
      
      Fixes: 91c6945e ("octeontx2-af: cn10k: Add RPM MAC support")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2378b2c9
    • Jiri Kosina's avatar
      iwlwifi: don't call netif_napi_add() with rxq->lock held (was Re: Lockdep... · 295d4cd8
      Jiri Kosina authored
      iwlwifi: don't call netif_napi_add() with rxq->lock held (was Re: Lockdep warning in iwl_pcie_rx_handle())
      
      We can't call netif_napi_add() with rxq-lock held, as there is a potential
      for deadlock as spotted by lockdep (see below). rxq->lock is not
      protecting anything over the netif_napi_add() codepath anyway, so let's
      drop it just before calling into NAPI.
      
       ========================================================
       WARNING: possible irq lock inversion dependency detected
       5.12.0-rc1-00002-gbada49429032 #5 Not tainted
       --------------------------------------------------------
       irq/136-iwlwifi/565 just changed the state of lock:
       ffff89f28433b0b0 (&rxq->lock){+.-.}-{2:2}, at: iwl_pcie_rx_handle+0x7f/0x960 [iwlwifi]
       but this lock took another, SOFTIRQ-unsafe lock in the past:
        (napi_hash_lock){+.+.}-{2:2}
      
       and interrupts could create inverse lock ordering between them.
      
       other info that might help us debug this:
        Possible interrupt unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(napi_hash_lock);
                                      local_irq_disable();
                                      lock(&rxq->lock);
                                      lock(napi_hash_lock);
         <Interrupt>
           lock(&rxq->lock);
      
        *** DEADLOCK ***
      
       1 lock held by irq/136-iwlwifi/565:
        #0: ffff89f2b1440170 (sync_cmd_lockdep_map){+.+.}-{0:0}, at: iwl_pcie_irq_handler+0x5/0xb30
      
       the shortest dependencies between 2nd lock and 1st lock:
        -> (napi_hash_lock){+.+.}-{2:2} {
           HARDIRQ-ON-W at:
                             lock_acquire+0x277/0x3d0
                             _raw_spin_lock+0x2c/0x40
                             netif_napi_add+0x14b/0x270
                             e1000_probe+0x2fe/0xee0 [e1000e]
                             local_pci_probe+0x42/0x90
                             pci_device_probe+0x10b/0x1c0
                             really_probe+0xef/0x4b0
                             driver_probe_device+0xde/0x150
                             device_driver_attach+0x4f/0x60
                             __driver_attach+0x9c/0x140
                             bus_for_each_dev+0x79/0xc0
                             bus_add_driver+0x18d/0x220
                             driver_register+0x5b/0xf0
                             do_one_initcall+0x5b/0x300
                             do_init_module+0x5b/0x21c
                             load_module+0x1dae/0x22c0
                             __do_sys_finit_module+0xad/0x110
                             do_syscall_64+0x33/0x80
                             entry_SYSCALL_64_after_hwframe+0x44/0xae
           SOFTIRQ-ON-W at:
                             lock_acquire+0x277/0x3d0
                             _raw_spin_lock+0x2c/0x40
                             netif_napi_add+0x14b/0x270
                             e1000_probe+0x2fe/0xee0 [e1000e]
                             local_pci_probe+0x42/0x90
                             pci_device_probe+0x10b/0x1c0
                             really_probe+0xef/0x4b0
                             driver_probe_device+0xde/0x150
                             device_driver_attach+0x4f/0x60
                             __driver_attach+0x9c/0x140
                             bus_for_each_dev+0x79/0xc0
                             bus_add_driver+0x18d/0x220
                             driver_register+0x5b/0xf0
                             do_one_initcall+0x5b/0x300
                             do_init_module+0x5b/0x21c
                             load_module+0x1dae/0x22c0
                             __do_sys_finit_module+0xad/0x110
                             do_syscall_64+0x33/0x80
                             entry_SYSCALL_64_after_hwframe+0x44/0xae
           INITIAL USE at:
                            lock_acquire+0x277/0x3d0
                            _raw_spin_lock+0x2c/0x40
                            netif_napi_add+0x14b/0x270
                            e1000_probe+0x2fe/0xee0 [e1000e]
                            local_pci_probe+0x42/0x90
                            pci_device_probe+0x10b/0x1c0
                            really_probe+0xef/0x4b0
                            driver_probe_device+0xde/0x150
                            device_driver_attach+0x4f/0x60
                            __driver_attach+0x9c/0x140
                            bus_for_each_dev+0x79/0xc0
                            bus_add_driver+0x18d/0x220
                            driver_register+0x5b/0xf0
                            do_one_initcall+0x5b/0x300
                            do_init_module+0x5b/0x21c
                            load_module+0x1dae/0x22c0
                            __do_sys_finit_module+0xad/0x110
                            do_syscall_64+0x33/0x80
                            entry_SYSCALL_64_after_hwframe+0x44/0xae
         }
         ... key      at: [<ffffffffae84ef38>] napi_hash_lock+0x18/0x40
         ... acquired at:
          _raw_spin_lock+0x2c/0x40
          netif_napi_add+0x14b/0x270
          _iwl_pcie_rx_init+0x1f4/0x710 [iwlwifi]
          iwl_pcie_rx_init+0x1b/0x3b0 [iwlwifi]
          iwl_trans_pcie_start_fw+0x2ac/0x6a0 [iwlwifi]
          iwl_mvm_load_ucode_wait_alive+0x116/0x460 [iwlmvm]
          iwl_run_init_mvm_ucode+0xa4/0x3a0 [iwlmvm]
          iwl_op_mode_mvm_start+0x9ed/0xbf0 [iwlmvm]
          _iwl_op_mode_start.isra.4+0x42/0x80 [iwlwifi]
          iwl_opmode_register+0x71/0xe0 [iwlwifi]
          iwl_mvm_init+0x34/0x1000 [iwlmvm]
          do_one_initcall+0x5b/0x300
          do_init_module+0x5b/0x21c
          load_module+0x1dae/0x22c0
          __do_sys_finit_module+0xad/0x110
          do_syscall_64+0x33/0x80
          entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      [ ... lockdep output trimmed .... ]
      
      Fixes: 25edc8f2 ("iwlwifi: pcie: properly implement NAPI")
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2103021134060.12405@cbobk.fhfr.pm
      295d4cd8
    • Pierre-Louis Bossart's avatar
      iwlwifi: fix ARCH=i386 compilation warnings · 436b2656
      Pierre-Louis Bossart authored
      An unsigned long variable should rely on '%lu' format strings, not '%zd'
      
      Fixes: a1a6a4cf ("iwlwifi: pnvm: implement reading PNVM from UEFI")
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Acked-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20210302011640.1276636-1-pierre-louis.bossart@linux.intel.com
      436b2656
    • Wei Yongjun's avatar
      iwlwifi: mvm: add terminate entry for dmi_system_id tables · a22549f1
      Wei Yongjun authored
      Make sure dmi_system_id tables are NULL terminated. This crashed when LTO was enabled:
      
      BUG: KASAN: global-out-of-bounds in dmi_check_system+0x5a/0x70
      Read of size 1 at addr ffffffffc16af750 by task NetworkManager/1913
      
      CPU: 4 PID: 1913 Comm: NetworkManager Not tainted 5.12.0-rc1+ #10057
      Hardware name: LENOVO 20THCTO1WW/20THCTO1WW, BIOS N2VET27W (1.12 ) 12/21/2020
      Call Trace:
       dump_stack+0x90/0xbe
       print_address_description.constprop.0+0x1d/0x140
       ? dmi_check_system+0x5a/0x70
       ? dmi_check_system+0x5a/0x70
       kasan_report.cold+0x7b/0xd4
       ? dmi_check_system+0x5a/0x70
       __asan_load1+0x4d/0x50
       dmi_check_system+0x5a/0x70
       iwl_mvm_up+0x1360/0x1690 [iwlmvm]
       ? iwl_mvm_send_recovery_cmd+0x270/0x270 [iwlmvm]
       ? setup_object.isra.0+0x27/0xd0
       ? kasan_poison+0x20/0x50
       ? ___slab_alloc.constprop.0+0x483/0x5b0
       ? mempool_kmalloc+0x17/0x20
       ? ftrace_graph_ret_addr+0x2a/0xb0
       ? kasan_poison+0x3c/0x50
       ? cfg80211_iftype_allowed+0x2e/0x90 [cfg80211]
       ? __kasan_check_write+0x14/0x20
       ? mutex_lock+0x86/0xe0
       ? __mutex_lock_slowpath+0x20/0x20
       __iwl_mvm_mac_start+0x49/0x290 [iwlmvm]
       iwl_mvm_mac_start+0x37/0x50 [iwlmvm]
       drv_start+0x73/0x1b0 [mac80211]
       ieee80211_do_open+0x53e/0xf10 [mac80211]
       ? ieee80211_check_concurrent_iface+0x266/0x2e0 [mac80211]
       ieee80211_open+0xb9/0x100 [mac80211]
       __dev_open+0x1b8/0x280
      
      Fixes: a2ac0f48 ("iwlwifi: mvm: implement approved list for the PPAG feature")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarNathan Chancellor <nathan@kernel.org>
      Tested-by: default avatarVictor Michel <vic.michel.web@gmail.com>
      Acked-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      [kvalo@codeaurora.org: improve commit log]
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20210223140039.1708534-1-weiyongjun1@huawei.com
      a22549f1
  3. 02 Mar, 2021 2 commits
    • Biao Huang's avatar
      net: ethernet: mtk-star-emac: fix wrong unmap in RX handling · 95b39f07
      Biao Huang authored
      mtk_star_dma_unmap_rx() should unmap the dma_addr of old skb rather than
      that of new skb.
      Assign new_dma_addr to desc_data.dma_addr after all handling of old skb
      ends to avoid unexpected receive side error.
      
      Fixes: f96e9641 ("net: ethernet: mtk-star-emac: fix error path in RX handling")
      Signed-off-by: default avatarBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95b39f07
    • Wong Vee Khee's avatar
      stmmac: intel: Fix mdio bus registration issue for TGL-H/ADL-S · fa706dce
      Wong Vee Khee authored
      On Intel platforms which consist of two Ethernet Controllers such as
      TGL-H and ADL-S, a unique MDIO bus id is required for MDIO bus to be
      successful registered:
      
      [   13.076133] sysfs: cannot create duplicate filename '/class/mdio_bus/stmmac-1'
      [   13.083404] CPU: 8 PID: 1898 Comm: systemd-udevd Tainted: G     U            5.11.0-net-next #106
      [   13.092410] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DRR4 CRB, BIOS ADLIFSI1.R00.1494.B00.2012031421 12/03/2020
      [   13.105709] Call Trace:
      [   13.108176]  dump_stack+0x64/0x7c
      [   13.111553]  sysfs_warn_dup+0x56/0x70
      [   13.115273]  sysfs_do_create_link_sd.isra.2+0xbd/0xd0
      [   13.120371]  device_add+0x4df/0x840
      [   13.123917]  ? complete_all+0x2a/0x40
      [   13.127636]  __mdiobus_register+0x98/0x310 [libphy]
      [   13.132572]  stmmac_mdio_register+0x1c5/0x3f0 [stmmac]
      [   13.137771]  ? stmmac_napi_add+0xa5/0xf0 [stmmac]
      [   13.142493]  stmmac_dvr_probe+0x806/0xee0 [stmmac]
      [   13.147341]  intel_eth_pci_probe+0x1cb/0x250 [dwmac_intel]
      [   13.152884]  pci_device_probe+0xd2/0x150
      [   13.156897]  really_probe+0xf7/0x4d0
      [   13.160527]  driver_probe_device+0x5d/0x140
      [   13.164761]  device_driver_attach+0x4f/0x60
      [   13.168996]  __driver_attach+0xa2/0x140
      [   13.172891]  ? device_driver_attach+0x60/0x60
      [   13.177300]  bus_for_each_dev+0x76/0xc0
      [   13.181188]  bus_add_driver+0x189/0x230
      [   13.185083]  ? 0xffffffffc0795000
      [   13.188446]  driver_register+0x5b/0xf0
      [   13.192249]  ? 0xffffffffc0795000
      [   13.195577]  do_one_initcall+0x4d/0x210
      [   13.199467]  ? kmem_cache_alloc_trace+0x2ff/0x490
      [   13.204228]  do_init_module+0x5b/0x21c
      [   13.208031]  load_module+0x2a0c/0x2de0
      [   13.211838]  ? __do_sys_finit_module+0xb1/0x110
      [   13.216420]  __do_sys_finit_module+0xb1/0x110
      [   13.220825]  do_syscall_64+0x33/0x40
      [   13.224451]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [   13.229515] RIP: 0033:0x7fc2b1919ccd
      [   13.233113] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 93 31 0c 00 f7 d8 64 89 01 48
      [   13.251912] RSP: 002b:00007ffcea2e5b98 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      [   13.259527] RAX: ffffffffffffffda RBX: 0000560558920f10 RCX: 00007fc2b1919ccd
      [   13.266706] RDX: 0000000000000000 RSI: 00007fc2b1a881e3 RDI: 0000000000000012
      [   13.273887] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000000
      [   13.281036] R10: 0000000000000012 R11: 0000000000000246 R12: 00007fc2b1a881e3
      [   13.288183] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffcea2e5d58
      [   13.295389] libphy: mii_bus stmmac-1 failed to register
      
      Fixes: 88af9bd4 ("stmmac: intel: Add ADL-S 1Gbps PCI IDs")
      Fixes: 8450e23f ("stmmac: intel: Add PCI IDs for TGL-H platform")
      Signed-off-by: default avatarWong Vee Khee <vee.khee.wong@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa706dce
  4. 01 Mar, 2021 4 commits
    • Eric Dumazet's avatar
      tcp: add sanity tests to TCP_QUEUE_SEQ · 8811f4a9
      Eric Dumazet authored
      Qingyu Li reported a syzkaller bug where the repro
      changes RCV SEQ _after_ restoring data in the receive queue.
      
      mprotect(0x4aa000, 12288, PROT_READ)    = 0
      mmap(0x1ffff000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1ffff000
      mmap(0x20000000, 16777216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000
      mmap(0x21000000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x21000000
      socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
      setsockopt(3, SOL_TCP, TCP_REPAIR, [1], 4) = 0
      connect(3, {sa_family=AF_INET6, sin6_port=htons(0), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0
      setsockopt(3, SOL_TCP, TCP_REPAIR_QUEUE, [1], 4) = 0
      sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="0x0000000000000003\0\0", iov_len=20}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
      setsockopt(3, SOL_TCP, TCP_REPAIR, [0], 4) = 0
      setsockopt(3, SOL_TCP, TCP_QUEUE_SEQ, [128], 4) = 0
      recvfrom(3, NULL, 20, 0, NULL, NULL)    = -1 ECONNRESET (Connection reset by peer)
      
      syslog shows:
      [  111.205099] TCP recvmsg seq # bug 2: copied 80, seq 0, rcvnxt 80, fl 0
      [  111.207894] WARNING: CPU: 1 PID: 356 at net/ipv4/tcp.c:2343 tcp_recvmsg_locked+0x90e/0x29a0
      
      This should not be allowed. TCP_QUEUE_SEQ should only be used
      when queues are empty.
      
      This patch fixes this case, and the tx path as well.
      
      Fixes: ee995283 ("tcp: Initial repair mode")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=212005Reported-by: default avatarQingyu Li <ieatmuttonchuan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8811f4a9
    • Andrea Parri (Microsoft)'s avatar
      hv_netvsc: Fix validation in netvsc_linkstatus_callback() · 3946688e
      Andrea Parri (Microsoft) authored
      Contrary to the RNDIS protocol specification, certain (pre-Fe)
      implementations of Hyper-V's vSwitch did not account for the status
      buffer field in the length of an RNDIS packet; the bug was fixed in
      newer implementations.  Validate the status buffer fields using the
      length of the 'vmtransfer_page' packet (all implementations), that
      is known/validated to be less than or equal to the receive section
      size and not smaller than the length of the RNDIS message.
      Reported-by: default avatarDexuan Cui <decui@microsoft.com>
      Suggested-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarAndrea Parri (Microsoft) <parri.andrea@gmail.com>
      Fixes: 505e3f00 ("hv_netvsc: Add (more) validation for untrusted Hyper-V values")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3946688e
    • DENG Qingfang's avatar
      net: dsa: tag_mtk: fix 802.1ad VLAN egress · 9200f515
      DENG Qingfang authored
      A different TPID bit is used for 802.1ad VLAN frames.
      Reported-by: default avatarIlario Gelmetti <iochesonome@gmail.com>
      Fixes: f0af3431 ("net: dsa: mediatek: combine MediaTek tag with VLAN tag")
      Signed-off-by: default avatarDENG Qingfang <dqfext@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9200f515
    • Willem de Bruijn's avatar
      net: expand textsearch ts_state to fit skb_seq_state · b228c9b0
      Willem de Bruijn authored
      The referenced commit expands the skb_seq_state used by
      skb_find_text with a 4B frag_off field, growing it to 48B.
      
      This exceeds container ts_state->cb, causing a stack corruption:
      
      [   73.238353] Kernel panic - not syncing: stack-protector: Kernel stack
      is corrupted in: skb_find_text+0xc5/0xd0
      [   73.247384] CPU: 1 PID: 376 Comm: nping Not tainted 5.11.0+ #4
      [   73.252613] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
      BIOS 1.14.0-2 04/01/2014
      [   73.260078] Call Trace:
      [   73.264677]  dump_stack+0x57/0x6a
      [   73.267866]  panic+0xf6/0x2b7
      [   73.270578]  ? skb_find_text+0xc5/0xd0
      [   73.273964]  __stack_chk_fail+0x10/0x10
      [   73.277491]  skb_find_text+0xc5/0xd0
      [   73.280727]  string_mt+0x1f/0x30
      [   73.283639]  ipt_do_table+0x214/0x410
      
      The struct is passed between skb_find_text and its callbacks
      skb_prepare_seq_read, skb_seq_read and skb_abort_seq read through
      the textsearch interface using TS_SKB_CB.
      
      I assumed that this mapped to skb->cb like other .._SKB_CB wrappers.
      skb->cb is 48B. But it maps to ts_state->cb, which is only 40B.
      
      skb->cb was increased from 40B to 48B after ts_state was introduced,
      in commit 3e3850e9 ("[NETFILTER]: Fix xfrm lookup in
      ip_route_me_harder/ip6_route_me_harder").
      
      Increase ts_state.cb[] to 48 to fit the struct.
      
      Also add a BUILD_BUG_ON to avoid a repeat.
      
      The alternative is to directly add a dependency from textsearch onto
      linux/skbuff.h, but I think the intent is textsearch to have no such
      dependencies on its callers.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=211911
      Fixes: 97550f6f ("net: compound page support in skb_seq_read")
      Reported-by: default avatarKris Karas <bugs-a17@moonlit-rail.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b228c9b0