1. 01 Jun, 2019 4 commits
  2. 30 May, 2019 2 commits
  3. 28 May, 2019 5 commits
    • YueHaibing's avatar
      rtw88: Make some symbols static · 6aca0977
      YueHaibing authored
      Fix sparse warnings:
      
      drivers/net/wireless/realtek/rtw88/phy.c:851:4: warning: symbol 'rtw_cck_size' was not declared. Should it be static?
      drivers/net/wireless/realtek/rtw88/phy.c:852:4: warning: symbol 'rtw_ofdm_size' was not declared. Should it be static?
      drivers/net/wireless/realtek/rtw88/phy.c:853:4: warning: symbol 'rtw_ht_1s_size' was not declared. Should it be static?
      drivers/net/wireless/realtek/rtw88/phy.c:854:4: warning: symbol 'rtw_ht_2s_size' was not declared. Should it be static?
      drivers/net/wireless/realtek/rtw88/phy.c:855:4: warning: symbol 'rtw_vht_1s_size' was not declared. Should it be static?
      drivers/net/wireless/realtek/rtw88/phy.c:856:4: warning: symbol 'rtw_vht_2s_size' was not declared. Should it be static?
      drivers/net/wireless/realtek/rtw88/fw.c:11:6: warning: symbol 'rtw_fw_c2h_cmd_handle_ext' was not declared. Should it be static?
      drivers/net/wireless/realtek/rtw88/fw.c:50:6: warning: symbol 'rtw_fw_send_h2c_command' was not declared. Should it be static?
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      6aca0977
    • Stanislaw Gruszka's avatar
      rtw88: avoid circular locking between local->iflist_mtx and rtwdev->mutex · 5b0efb4d
      Stanislaw Gruszka authored
      Remove circular lock dependency by using atomic version of interfaces
      iterate in watch_dog_work(), hence avoid taking local->iflist_mtx
      (rtw_vif_watch_dog_iter() only update some data, it can be called from
      atomic context). Fixes below LOCKDEP warning:
      
      [ 1157.219415] ======================================================
      [ 1157.225772] [ INFO: possible circular locking dependency detected ]
      [ 1157.232150] 3.10.0-1043.el7.sgruszka1.x86_64.debug #1 Not tainted
      [ 1157.238346] -------------------------------------------------------
      [ 1157.244635] kworker/u4:2/14490 is trying to acquire lock:
      [ 1157.250194]  (&rtwdev->mutex){+.+.+.}, at: [<ffffffffc098322b>] rtw_ops_config+0x2b/0x90 [rtw88]
      [ 1157.259151]
      but task is already holding lock:
      [ 1157.265085]  (&local->iflist_mtx){+.+...}, at: [<ffffffffc0b8ab7a>] ieee80211_mgd_probe_ap.part.28+0xca/0x160 [mac80211]
      [ 1157.276169]
      which lock already depends on the new lock.
      
      [ 1157.284488]
      the existing dependency chain (in reverse order) is:
      [ 1157.292101]
      -> #2 (&local->iflist_mtx){+.+...}:
      [ 1157.296919]        [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0
      [ 1157.302955]        [<ffffffffbce72793>] mutex_lock_nested+0x93/0x410
      [ 1157.309416]        [<ffffffffc0b6038f>] ieee80211_iterate_interfaces+0x2f/0x60 [mac80211]
      [ 1157.317730]        [<ffffffffc09811ab>] rtw_watch_dog_work+0xcb/0x130 [rtw88]
      [ 1157.325003]        [<ffffffffbc6d77bc>] process_one_work+0x22c/0x720
      [ 1157.331481]        [<ffffffffbc6d7dd6>] worker_thread+0x126/0x3b0
      [ 1157.337589]        [<ffffffffbc6e107f>] kthread+0xef/0x100
      [ 1157.343260]        [<ffffffffbce848b7>] ret_from_fork_nospec_end+0x0/0x39
      [ 1157.350091]
      -> #1 ((&(&rtwdev->watch_dog_work)->work)){+.+...}:
      [ 1157.356314]        [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0
      [ 1157.362427]        [<ffffffffbc6d570b>] flush_work+0x5b/0x310
      [ 1157.368287]        [<ffffffffbc6d740e>] __cancel_work_timer+0xae/0x170
      [ 1157.374940]        [<ffffffffbc6d7583>] cancel_delayed_work_sync+0x13/0x20
      [ 1157.381930]        [<ffffffffc0982b49>] rtw_core_stop+0x29/0x50 [rtw88]
      [ 1157.388679]        [<ffffffffc098bee6>] rtw_enter_ips+0x16/0x20 [rtw88]
      [ 1157.395428]        [<ffffffffc0983242>] rtw_ops_config+0x42/0x90 [rtw88]
      [ 1157.402173]        [<ffffffffc0b13343>] ieee80211_hw_config+0xc3/0x680 [mac80211]
      [ 1157.409854]        [<ffffffffc0b3925b>] ieee80211_do_open+0x69b/0x9c0 [mac80211]
      [ 1157.417418]        [<ffffffffc0b395e9>] ieee80211_open+0x69/0x70 [mac80211]
      [ 1157.424496]        [<ffffffffbcd03442>] __dev_open+0xe2/0x160
      [ 1157.430356]        [<ffffffffbcd03773>] __dev_change_flags+0xa3/0x180
      [ 1157.436922]        [<ffffffffbcd03879>] dev_change_flags+0x29/0x60
      [ 1157.443224]        [<ffffffffbcda14c4>] devinet_ioctl+0x794/0x890
      [ 1157.449331]        [<ffffffffbcda27b5>] inet_ioctl+0x75/0xa0
      [ 1157.455087]        [<ffffffffbccd54eb>] sock_do_ioctl+0x2b/0x60
      [ 1157.461178]        [<ffffffffbccd5753>] sock_ioctl+0x233/0x310
      [ 1157.467109]        [<ffffffffbc8bd820>] do_vfs_ioctl+0x410/0x6c0
      [ 1157.473233]        [<ffffffffbc8bdb71>] SyS_ioctl+0xa1/0xc0
      [ 1157.478914]        [<ffffffffbce84a5e>] system_call_fastpath+0x25/0x2a
      [ 1157.485569]
      -> #0 (&rtwdev->mutex){+.+.+.}:
      [ 1157.490022]        [<ffffffffbc7409d1>] __lock_acquire+0xec1/0x1630
      [ 1157.496305]        [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0
      [ 1157.502413]        [<ffffffffbce72793>] mutex_lock_nested+0x93/0x410
      [ 1157.508890]        [<ffffffffc098322b>] rtw_ops_config+0x2b/0x90 [rtw88]
      [ 1157.515724]        [<ffffffffc0b13343>] ieee80211_hw_config+0xc3/0x680 [mac80211]
      [ 1157.523370]        [<ffffffffc0b8a4ca>] ieee80211_recalc_ps.part.27+0x9a/0x180 [mac80211]
      [ 1157.531685]        [<ffffffffc0b8abc5>] ieee80211_mgd_probe_ap.part.28+0x115/0x160 [mac80211]
      [ 1157.540353]        [<ffffffffc0b8b40d>] ieee80211_beacon_connection_loss_work+0x4d/0x80 [mac80211]
      [ 1157.549513]        [<ffffffffbc6d77bc>] process_one_work+0x22c/0x720
      [ 1157.555886]        [<ffffffffbc6d7dd6>] worker_thread+0x126/0x3b0
      [ 1157.562170]        [<ffffffffbc6e107f>] kthread+0xef/0x100
      [ 1157.567765]        [<ffffffffbce848b7>] ret_from_fork_nospec_end+0x0/0x39
      [ 1157.574579]
      other info that might help us debug this:
      
      [ 1157.582788] Chain exists of:
        &rtwdev->mutex --> (&(&rtwdev->watch_dog_work)->work) --> &local->iflist_mtx
      
      [ 1157.593024]  Possible unsafe locking scenario:
      
      [ 1157.599046]        CPU0                    CPU1
      [ 1157.603653]        ----                    ----
      [ 1157.608258]   lock(&local->iflist_mtx);
      [ 1157.612180]                                lock((&(&rtwdev->watch_dog_work)->work));
      [ 1157.620074]                                lock(&local->iflist_mtx);
      [ 1157.626555]   lock(&rtwdev->mutex);
      [ 1157.630124]
       *** DEADLOCK ***
      
      [ 1157.636148] 4 locks held by kworker/u4:2/14490:
      [ 1157.640755]  #0:  (%s#6){.+.+.+}, at: [<ffffffffbc6d774a>] process_one_work+0x1ba/0x720
      [ 1157.648965]  #1:  ((&ifmgd->beacon_connection_loss_work)){+.+.+.}, at: [<ffffffffbc6d774a>] process_one_work+0x1ba/0x720
      [ 1157.659950]  #2:  (&wdev->mtx){+.+.+.}, at: [<ffffffffc0b8aad5>] ieee80211_mgd_probe_ap.part.28+0x25/0x160 [mac80211]
      [ 1157.670901]  #3:  (&local->iflist_mtx){+.+...}, at: [<ffffffffc0b8ab7a>] ieee80211_mgd_probe_ap.part.28+0xca/0x160 [mac80211]
      [ 1157.682466]
      
      Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver")
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: default avatarYan-Hsuan Chuang <yhchuang@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      5b0efb4d
    • Nathan Chancellor's avatar
      rsi: Properly initialize data in rsi_sdio_ta_reset · f57b5d85
      Nathan Chancellor authored
      When building with -Wuninitialized, Clang warns:
      
      drivers/net/wireless/rsi/rsi_91x_sdio.c:940:43: warning: variable 'data'
      is uninitialized when used here [-Wuninitialized]
              put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
                                                       ^~~~
      drivers/net/wireless/rsi/rsi_91x_sdio.c:930:10: note: initialize the
      variable 'data' to silence this warning
              u8 *data;
                      ^
                       = NULL
      1 warning generated.
      
      Using Clang's suggestion of initializing data to NULL wouldn't work out
      because data will be dereferenced by put_unaligned_le32. Use kzalloc to
      properly initialize data, which matches a couple of other places in this
      driver.
      
      Fixes: e5a1ecc9 ("rsi: add firmware loading for 9116 device")
      Link: https://github.com/ClangBuiltLinux/linux/issues/464Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      f57b5d85
    • Yan-Hsuan Chuang's avatar
      rtw88: fix unassigned rssi_level in rtw_sta_info · a24bad74
      Yan-Hsuan Chuang authored
      The new rssi_level should be stored in si, otherwise the rssi_level will
      never be updated and get a wrong RA mask, which is calculated by the
      rssi level
      
      If a wrong RA mask is chosen, the firmware will pick some *bad rates*.
      The most hurtful scene will be in *noisy environment*, such as office or
      public area with many APs and users.
      The latency would be high and the overall throughput would be only half
      or less.
      
      Tested in 2.4G in office area, with this patch the throughput increased
      from such as "1x Mbps -> 4x Mbps".
      Signed-off-by: default avatarYan-Hsuan Chuang <yhchuang@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      a24bad74
    • Stanislaw Gruszka's avatar
      rtw88: fix subscript above array bounds compiler warning · 8a03447d
      Stanislaw Gruszka authored
      My compiler complains about:
      
      drivers/net/wireless/realtek/rtw88/phy.c: In function ‘rtw_phy_rf_power_2_rssi’:
      drivers/net/wireless/realtek/rtw88/phy.c:430:26: warning: array subscript is above array bounds [-Warray-bounds]
        linear = db_invert_table[i][j];
      
      According to comment power_db should be in range 1 ~ 96 .
      To fix add check for boundaries before access the array.
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: default avatarYan-Hsuan Chuang <yhchuang@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      8a03447d
  4. 27 May, 2019 6 commits
  5. 26 May, 2019 5 commits
  6. 25 May, 2019 7 commits
  7. 24 May, 2019 3 commits
  8. 23 May, 2019 8 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 71e15f76
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter/IPVS fixes for net
      
      The following patchset contains Netfilter/IPVS fixes for your net tree:
      
      1) Fix crash when dumping rules after conversion to RCU,
         from Florian Westphal.
      
      2) Fix incorrect hook reinjection from nf_queue in case NF_REPEAT,
         from Jagdish Motwani.
      
      3) Fix check for route existence in fib extension, from Phil Sutter.
      
      4) Fix use after free in ip_vs_in() hook, from YueHaibing.
      
      5) Check for veth existence from netfilter selftests,
         from Jeffrin Jose T.
      
      6) Checksum corruption in UDP NAT helpers due to typo,
         from Florian Westphal.
      
      7) Pass up packets to classic forwarding path regardless of
         IPv4 DF bit, patch for the flowtable infrastructure from Florian.
      
      8) Set liberal TCP tracking for flows that are placed in the
         flowtable, in case they need to go back to classic forwarding path,
         also from Florian.
      
      9) Don't add flow with sequence adjustment to flowtable, from Florian.
      
      10) Skip IPv4 options from IPv6 datapath in flowtable, from Florian.
      
      11) Add selftest for the flowtable infrastructure, from Florian.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71e15f76
    • Raju Rangoju's avatar
      cxgb4: offload VLAN flows regardless of VLAN ethtype · b5730061
      Raju Rangoju authored
      VLAN flows never get offloaded unless ivlan_vld is set in filter spec.
      It's not compulsory for vlan_ethtype to be set.
      
      So, always enable ivlan_vld bit for offloading VLAN flows regardless of
      vlan_ethtype is set or not.
      
      Fixes: ad9af3e0 (cxgb4: add tc flower match support for vlan)
      Signed-off-by: default avatarRaju Rangoju <rajur@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5730061
    • Andreas Oetken's avatar
      hsr: fix don't prune the master node from the node_db · d2daa127
      Andreas Oetken authored
      Don't prune the master node in the hsr_prune_nodes function.
      Neither time_in[HSR_PT_SLAVE_A] nor time_in[HSR_PT_SLAVE_B]
      will ever be updated by hsr_register_frame_in for the master port.
      Thus, the master node will be repeatedly pruned leading to
      repeated packet loss.
      This bug never appeared because the hsr_prune_nodes function
      was only called once. Since commit 5150b45f
      ("net: hsr: Fix node prune function for forget time expiry") this issue
      is fixed unveiling the issue described above.
      
      Fixes: 5150b45f ("net: hsr: Fix node prune function for forget time expiry")
      Signed-off-by: default avatarAndreas Oetken <andreas.oetken@siemens.com>
      Tested-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d2daa127
    • Maxime Chevallier's avatar
      net: mvpp2: cls: Fix leaked ethtool_rx_flow_rule · 3f6f7a17
      Maxime Chevallier authored
      The flow_rule is only used when configuring the classification tables,
      and should be free'd once we're done using it. The current code only
      frees it in the error path.
      
      Fixes: 90b509b3 ("net: mvpp2: cls: Add Classification offload support")
      Signed-off-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f6f7a17
    • Eric Dumazet's avatar
      ipv4/igmp: fix build error if !CONFIG_IP_MULTICAST · 903869bd
      Eric Dumazet authored
      ip_sf_list_clear_all() needs to be defined even if !CONFIG_IP_MULTICAST
      
      Fixes: 3580d04a ("ipv4/igmp: fix another memory leak in igmpv3_del_delrec()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      903869bd
    • Eric Dumazet's avatar
      ipv4/igmp: fix another memory leak in igmpv3_del_delrec() · 3580d04a
      Eric Dumazet authored
      syzbot reported memory leaks [1] that I have back tracked to
      a missing cleanup from igmpv3_del_delrec() when
      (im->sfmode != MCAST_INCLUDE)
      
      Add ip_sf_list_clear_all() and kfree_pmc() helpers to explicitely
      handle the cleanups before freeing.
      
      [1]
      
      BUG: memory leak
      unreferenced object 0xffff888123e32b00 (size 64):
        comm "softirq", pid 0, jiffies 4294942968 (age 8.010s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 e0 00 00 01 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<000000006105011b>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<000000006105011b>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<000000006105011b>] slab_alloc mm/slab.c:3326 [inline]
          [<000000006105011b>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
          [<000000004bba8073>] kmalloc include/linux/slab.h:547 [inline]
          [<000000004bba8073>] kzalloc include/linux/slab.h:742 [inline]
          [<000000004bba8073>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
          [<000000004bba8073>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
          [<00000000a46a65a0>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
          [<000000005956ca89>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:957
          [<00000000848e2d2f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
          [<00000000b9db185c>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
          [<000000003028e438>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130
          [<0000000015b65589>] __sys_setsockopt+0x98/0x120 net/socket.c:2078
          [<00000000ac198ef0>] __do_sys_setsockopt net/socket.c:2089 [inline]
          [<00000000ac198ef0>] __se_sys_setsockopt net/socket.c:2086 [inline]
          [<00000000ac198ef0>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
          [<000000000a770437>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<00000000d3adb93b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 9c8bb163 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Hangbin Liu <liuhangbin@gmail.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3580d04a
    • David S. Miller's avatar
      Merge branch 'bnxt_en-Bug-fixes' · db51a732
      David S. Miller authored
      Michael Chan says:
      
      ===================
      bnxt_en: Bug fixes.
      
      There are 4 driver fixes in this series:
      
      1. Fix RX buffer leak during OOM condition.
      2. Call pci_disable_msix() under correct conditions to prevent hitting BUG.
      3. Reduce unneeded mmeory allocation in kdump kernel to prevent OOM.
      4. Don't read device serial number on VFs because it is not supported.
      
      Please queue #1, #2, #3 for -stable as well.  Thanks.
      ===================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db51a732
    • Vasundhara Volam's avatar
      bnxt_en: Device serial number is supported only for PFs. · 2e9217d1
      Vasundhara Volam authored
      Don't read DSN on VFs that do not have the PCI capability.
      
      Fixes: 03213a99 ("bnxt: move bp->switch_id initialization to PF probe")
      Signed-off-by: default avatarVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e9217d1