1. 04 Nov, 2018 40 commits
    • Rickard x Andersson's avatar
      net: fec: fix rare tx timeout · 1837dbb2
      Rickard x Andersson authored
      [ Upstream commit 657ade07 ]
      
      During certain heavy network loads TX could time out
      with TX ring dump.
      TX is sometimes never restarted after reaching
      "tx_stop_threshold" because function "fec_enet_tx_queue"
      only tests the first queue.
      
      In addition the TX timeout callback function failed to
      recover because it also operated only on the first queue.
      Signed-off-by: default avatarRickard x Andersson <rickaran@axis.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1837dbb2
    • Natarajan, Janakarajan's avatar
      perf/x86/amd/uncore: Set ThreadMask and SliceMask for L3 Cache perf events · 784f8395
      Natarajan, Janakarajan authored
      [ Upstream commit d7cbbe49 ]
      
      In Family 17h, some L3 Cache Performance events require the ThreadMask
      and SliceMask to be set. For other events, these fields do not affect
      the count either way.
      
      Set ThreadMask and SliceMask to 0xFF and 0xF respectively.
      Signed-off-by: default avatarJanakarajan Natarajan <Janakarajan.Natarajan@amd.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H . Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Suravee <Suravee.Suthikulpanit@amd.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/Message-ID:
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      784f8395
    • Kan Liang's avatar
      perf/x86/intel/uncore: Fix PCI BDF address of M3UPI on SKX · 40568f21
      Kan Liang authored
      [ Upstream commit 9d92cfea ]
      
      The counters on M3UPI Link 0 and Link 3 don't count properly, and writing
      0 to these counters may causes system crash on some machines.
      
      The PCI BDF addresses of the M3UPI in the current code are incorrect.
      
      The correct addresses should be:
      
        D18:F1	0x204D
        D18:F2	0x204E
        D18:F5	0x204D
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: cd34cd97 ("perf/x86/intel/uncore: Add Skylake server uncore support")
      Link: http://lkml.kernel.org/r/1537538826-55489-1-git-send-email-kan.liang@linux.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      40568f21
    • Jiri Olsa's avatar
      perf/ring_buffer: Prevent concurent ring buffer access · a18e2159
      Jiri Olsa authored
      [ Upstream commit cd6fb677 ]
      
      Some of the scheduling tracepoints allow the perf_tp_event
      code to write to ring buffer under different cpu than the
      code is running on.
      
      This results in corrupted ring buffer data demonstrated in
      following perf commands:
      
        # perf record -e 'sched:sched_switch,sched:sched_wakeup' perf bench sched messaging
        # Running 'sched/messaging' benchmark:
        # 20 sender and receiver processes per group
        # 10 groups == 400 processes run
      
             Total time: 0.383 [sec]
        [ perf record: Woken up 8 times to write data ]
        0x42b890 [0]: failed to process type: -1765585640
        [ perf record: Captured and wrote 4.825 MB perf.data (29669 samples) ]
      
        # perf report --stdio
        0x42b890 [0]: failed to process type: -1765585640
      
      The reason for the corruption are some of the scheduling tracepoints,
      that have __perf_task dfined and thus allow to store data to another
      cpu ring buffer:
      
        sched_waking
        sched_wakeup
        sched_wakeup_new
        sched_stat_wait
        sched_stat_sleep
        sched_stat_iowait
        sched_stat_blocked
      
      The perf_tp_event function first store samples for current cpu
      related events defined for tracepoint:
      
          hlist_for_each_entry_rcu(event, head, hlist_entry)
            perf_swevent_event(event, count, &data, regs);
      
      And then iterates events of the 'task' and store the sample
      for any task's event that passes tracepoint checks:
      
        ctx = rcu_dereference(task->perf_event_ctxp[perf_sw_context]);
      
        list_for_each_entry_rcu(event, &ctx->event_list, event_entry) {
          if (event->attr.type != PERF_TYPE_TRACEPOINT)
            continue;
          if (event->attr.config != entry->type)
            continue;
      
          perf_swevent_event(event, count, &data, regs);
        }
      
      Above code can race with same code running on another cpu,
      ending up with 2 cpus trying to store under the same ring
      buffer, which is specifically not allowed.
      
      This patch prevents the problem, by allowing only events with the same
      current cpu to receive the event.
      
      NOTE: this requires the use of (per-task-)per-cpu buffers for this
      feature to work; perf-record does this.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      [peterz: small edits to Changelog]
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrew Vagin <avagin@openvz.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: e6dab5ff ("perf/trace: Add ability to set a target task for events")
      Link: http://lkml.kernel.org/r/20180923161343.GB15054@kravaSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a18e2159
    • Peter Zijlstra's avatar
      perf/core: Fix perf_pmu_unregister() locking · ffc3cb56
      Peter Zijlstra authored
      [ Upstream commit a9f97721 ]
      
      When we unregister a PMU, we fail to serialize the @pmu_idr properly.
      Fix that by doing the entire thing under pmu_lock.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: 2e80a82a ("perf: Dynamic pmu types")
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ffc3cb56
    • Yu Zhao's avatar
      cfg80211: fix use-after-free in reg_process_hint() · 492a8131
      Yu Zhao authored
      [ Upstream commit 1db58529 ]
      
      reg_process_hint_country_ie() can free regulatory_request and return
      REG_REQ_ALREADY_SET. We shouldn't use regulatory_request after it's
      called. KASAN error was observed when this happens.
      
      BUG: KASAN: use-after-free in reg_process_hint+0x839/0x8aa [cfg80211]
      Read of size 4 at addr ffff8800c430d434 by task kworker/1:3/89
      <snipped>
      Workqueue: events reg_todo [cfg80211]
      Call Trace:
       dump_stack+0xc1/0x10c
       ? _atomic_dec_and_lock+0x1ad/0x1ad
       ? _raw_spin_lock_irqsave+0xa0/0xd2
       print_address_description+0x86/0x26f
       ? reg_process_hint+0x839/0x8aa [cfg80211]
       kasan_report+0x241/0x29b
       reg_process_hint+0x839/0x8aa [cfg80211]
       reg_todo+0x204/0x5b9 [cfg80211]
       process_one_work+0x55f/0x8d0
       ? worker_detach_from_pool+0x1b5/0x1b5
       ? _raw_spin_unlock_irq+0x65/0xdd
       ? _raw_spin_unlock_irqrestore+0xf3/0xf3
       worker_thread+0x5dd/0x841
       ? kthread_parkme+0x1d/0x1d
       kthread+0x270/0x285
       ? pr_cont_work+0xe3/0xe3
       ? rcu_read_unlock_sched_notrace+0xca/0xca
       ret_from_fork+0x22/0x40
      
      Allocated by task 2718:
       set_track+0x63/0xfa
       __kmalloc+0x119/0x1ac
       regulatory_hint_country_ie+0x38/0x329 [cfg80211]
       __cfg80211_connect_result+0x854/0xadd [cfg80211]
       cfg80211_rx_assoc_resp+0x3bc/0x4f0 [cfg80211]
      smsc95xx v1.0.6
       ieee80211_sta_rx_queued_mgmt+0x1803/0x7ed5 [mac80211]
       ieee80211_iface_work+0x411/0x696 [mac80211]
       process_one_work+0x55f/0x8d0
       worker_thread+0x5dd/0x841
       kthread+0x270/0x285
       ret_from_fork+0x22/0x40
      
      Freed by task 89:
       set_track+0x63/0xfa
       kasan_slab_free+0x6a/0x87
       kfree+0xdc/0x470
       reg_process_hint+0x31e/0x8aa [cfg80211]
       reg_todo+0x204/0x5b9 [cfg80211]
       process_one_work+0x55f/0x8d0
       worker_thread+0x5dd/0x841
       kthread+0x270/0x285
       ret_from_fork+0x22/0x40
      <snipped>
      Signed-off-by: default avatarYu Zhao <yuzhao@google.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      492a8131
    • Florian Fainelli's avatar
      smsc95xx: Check for Wake-on-LAN modes · 35ffbd52
      Florian Fainelli authored
      [ Upstream commit c530c471 ]
      
      The driver does not check for Wake-on-LAN modes specified by an user,
      but will conditionally set the device as wake-up enabled or not based on
      that, which could be a very confusing user experience.
      
      Fixes: e0e474a8 ("smsc95xx: add wol magic packet support")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      35ffbd52
    • Florian Fainelli's avatar
      smsc75xx: Check for Wake-on-LAN modes · 9e3a0366
      Florian Fainelli authored
      [ Upstream commit 9c734b27 ]
      
      The driver does not check for Wake-on-LAN modes specified by an user,
      but will conditionally set the device as wake-up enabled or not based on
      that, which could be a very confusing user experience.
      
      Fixes: 6c636503 ("smsc75xx: add wol magic packet support")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9e3a0366
    • Florian Fainelli's avatar
      r8152: Check for supported Wake-on-LAN Modes · 9eaabc0a
      Florian Fainelli authored
      [ Upstream commit f2750df1 ]
      
      The driver does not check for Wake-on-LAN modes specified by an user,
      but will conditionally set the device as wake-up enabled or not based on
      that, which could be a very confusing user experience.
      
      Fixes: 21ff2e89 ("r8152: support WOL")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9eaabc0a
    • Florian Fainelli's avatar
      sr9800: Check for supported Wake-on-LAN modes · 4301fb33
      Florian Fainelli authored
      [ Upstream commit c5cb93e9 ]
      
      The driver currently silently accepts unsupported Wake-on-LAN modes
      (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
      which is confusing.
      
      Fixes: 19a38d8e ("USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4301fb33
    • Florian Fainelli's avatar
      lan78xx: Check for supported Wake-on-LAN modes · 9f0962c0
      Florian Fainelli authored
      [ Upstream commit eb9ad088 ]
      
      The driver supports a fair amount of Wake-on-LAN modes, but is not
      checking that the user specified one that is supported.
      
      Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarWoojung Huh <Woojung.Huh@Microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9f0962c0
    • Florian Fainelli's avatar
      ax88179_178a: Check for supported Wake-on-LAN modes · a0fc0633
      Florian Fainelli authored
      [ Upstream commit 5ba6b4aa ]
      
      The driver currently silently accepts unsupported Wake-on-LAN modes
      (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
      which is confusing.
      
      Fixes: e2ca90c2 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a0fc0633
    • Florian Fainelli's avatar
      asix: Check for supported Wake-on-LAN modes · eef5935c
      Florian Fainelli authored
      [ Upstream commit c4ce446e ]
      
      The driver currently silently accepts unsupported Wake-on-LAN modes
      (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
      which is confusing.
      
      Fixes: 2e55cc72 ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      eef5935c
    • Masashi Honma's avatar
      nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds · 915670c4
      Masashi Honma authored
      [ Upstream commit 1222a160 ]
      
      Use array_index_nospec() to sanitize i with respect to speculation.
      
      Note that the user doesn't control i directly, but can make it out
      of bounds by not finding a threshold in the array.
      Signed-off-by: default avatarMasashi Honma <masashi.honma@gmail.com>
      [add note about user control, as explained by Masashi]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      915670c4
    • Nathan Chancellor's avatar
      qed: Avoid implicit enum conversion in qed_iwarp_parse_rx_pkt · b93393d6
      Nathan Chancellor authored
      [ Upstream commit 77f2d753 ]
      
      Clang warns when one enumerated type is implicitly converted to another.
      
      drivers/net/ethernet/qlogic/qed/qed_iwarp.c:1713:25: warning: implicit
      conversion from enumeration type 'enum tcp_ip_version' to different
      enumeration type 'enum qed_tcp_ip_version' [-Wenum-conversion]
                      cm_info->ip_version = TCP_IPV4;
                                          ~ ^~~~~~~~
      drivers/net/ethernet/qlogic/qed/qed_iwarp.c:1733:25: warning: implicit
      conversion from enumeration type 'enum tcp_ip_version' to different
      enumeration type 'enum qed_tcp_ip_version' [-Wenum-conversion]
                      cm_info->ip_version = TCP_IPV6;
                                          ~ ^~~~~~~~
      2 warnings generated.
      
      Use the appropriate values from the expected type, qed_tcp_ip_version:
      
      TCP_IPV4 = QED_TCP_IPV4 = 0
      TCP_IPV6 = QED_TCP_IPV6 = 1
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/125Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b93393d6
    • Nathan Chancellor's avatar
      qed: Avoid constant logical operation warning in qed_vf_pf_acquire · ee86b4d6
      Nathan Chancellor authored
      [ Upstream commit 1c492a9d ]
      
      Clang warns when a constant is used in a boolean context as it thinks a
      bitwise operation may have been intended.
      
      drivers/net/ethernet/qlogic/qed/qed_vf.c:415:27: warning: use of logical
      '&&' with constant operand [-Wconstant-logical-operand]
              if (!p_iov->b_pre_fp_hsi &&
                                       ^
      drivers/net/ethernet/qlogic/qed/qed_vf.c:415:27: note: use '&' for a
      bitwise operation
              if (!p_iov->b_pre_fp_hsi &&
                                       ^~
                                       &
      drivers/net/ethernet/qlogic/qed/qed_vf.c:415:27: note: remove constant
      to silence this warning
              if (!p_iov->b_pre_fp_hsi &&
                                      ~^~
      1 warning generated.
      
      This has been here since commit 1fe614d1 ("qed: Relax VF firmware
      requirements") and I am not entirely sure why since 0 isn't a special
      case. Just remove the statement causing Clang to warn since it isn't
      required.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/126Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ee86b4d6
    • Nathan Chancellor's avatar
      qed: Avoid implicit enum conversion in qed_roce_mode_to_flavor · 935d4419
      Nathan Chancellor authored
      [ Upstream commit d3a31579 ]
      
      Clang warns when one enumerated type is implicitly converted to another.
      
      drivers/net/ethernet/qlogic/qed/qed_roce.c:153:12: warning: implicit
      conversion from enumeration type 'enum roce_mode' to different
      enumeration type 'enum roce_flavor' [-Wenum-conversion]
                      flavor = ROCE_V2_IPV6;
                             ~ ^~~~~~~~~~~~
      drivers/net/ethernet/qlogic/qed/qed_roce.c:156:12: warning: implicit
      conversion from enumeration type 'enum roce_mode' to different
      enumeration type 'enum roce_flavor' [-Wenum-conversion]
                      flavor = MAX_ROCE_MODE;
                             ~ ^~~~~~~~~~~~~
      2 warnings generated.
      
      Use the appropriate values from the expected type, roce_flavor:
      
      ROCE_V2_IPV6 = RROCE_IPV6 = 2
      MAX_ROCE_MODE = MAX_ROCE_FLAVOR = 3
      
      While we're add it, ditch the local variable flavor, we can just return
      the value directly from the switch statement.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/125Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      935d4419
    • Nathan Chancellor's avatar
      qed: Fix mask parameter in qed_vf_prep_tunn_req_tlv · ab7998ab
      Nathan Chancellor authored
      [ Upstream commit db803f36 ]
      
      Clang complains when one enumerated type is implicitly converted to
      another.
      
      drivers/net/ethernet/qlogic/qed/qed_vf.c:686:6: warning: implicit
      conversion from enumeration type 'enum qed_tunn_mode' to different
      enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
                                       QED_MODE_L2GENEVE_TUNN,
                                       ^~~~~~~~~~~~~~~~~~~~~~
      
      Update mask's parameter to expect qed_tunn_mode, which is what was
      intended.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/125Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ab7998ab
    • Nathan Chancellor's avatar
      qed: Avoid implicit enum conversion in qed_set_tunn_cls_info · 76f86190
      Nathan Chancellor authored
      [ Upstream commit a898fba3 ]
      
      Clang warns when one enumerated type is implicitly converted to another.
      
      drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:163:25: warning:
      implicit conversion from enumeration type 'enum tunnel_clss' to
      different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
              p_tun->vxlan.tun_cls = type;
                                   ~ ^~~~
      drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:165:26: warning:
      implicit conversion from enumeration type 'enum tunnel_clss' to
      different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
              p_tun->l2_gre.tun_cls = type;
                                    ~ ^~~~
      drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:167:26: warning:
      implicit conversion from enumeration type 'enum tunnel_clss' to
      different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
              p_tun->ip_gre.tun_cls = type;
                                    ~ ^~~~
      drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:169:29: warning:
      implicit conversion from enumeration type 'enum tunnel_clss' to
      different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
              p_tun->l2_geneve.tun_cls = type;
                                       ~ ^~~~
      drivers/net/ethernet/qlogic/qed/qed_sp_commands.c:171:29: warning:
      implicit conversion from enumeration type 'enum tunnel_clss' to
      different enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
              p_tun->ip_geneve.tun_cls = type;
                                       ~ ^~~~
      5 warnings generated.
      
      Avoid this by changing type to an int.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/125Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      76f86190
    • Lubomir Rintel's avatar
      pxa168fb: prepare the clock · 86574155
      Lubomir Rintel authored
      [ Upstream commit d85536cd ]
      
      Add missing prepare/unprepare operations for fbi->clk,
      this fixes following kernel warning:
      
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:874 clk_core_enable+0x2c/0x1b0
        Enabling unprepared disp0_clk
        Modules linked in:
        CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0-rc8-00032-g02b43ddd4f21-dirty #25
        Hardware name: Marvell MMP2 (Device Tree Support)
        [<c010f7cc>] (unwind_backtrace) from [<c010cc6c>] (show_stack+0x10/0x14)
        [<c010cc6c>] (show_stack) from [<c011dab4>] (__warn+0xd8/0xf0)
        [<c011dab4>] (__warn) from [<c011db10>] (warn_slowpath_fmt+0x44/0x6c)
        [<c011db10>] (warn_slowpath_fmt) from [<c043898c>] (clk_core_enable+0x2c/0x1b0)
        [<c043898c>] (clk_core_enable) from [<c0439ec8>] (clk_core_enable_lock+0x18/0x2c)
        [<c0439ec8>] (clk_core_enable_lock) from [<c0436698>] (pxa168fb_probe+0x464/0x6ac)
        [<c0436698>] (pxa168fb_probe) from [<c04779a0>] (platform_drv_probe+0x48/0x94)
        [<c04779a0>] (platform_drv_probe) from [<c0475bec>] (driver_probe_device+0x328/0x470)
        [<c0475bec>] (driver_probe_device) from [<c0475de4>] (__driver_attach+0xb0/0x124)
        [<c0475de4>] (__driver_attach) from [<c0473c38>] (bus_for_each_dev+0x64/0xa0)
        [<c0473c38>] (bus_for_each_dev) from [<c0474ee0>] (bus_add_driver+0x1b8/0x230)
        [<c0474ee0>] (bus_add_driver) from [<c0476a20>] (driver_register+0xac/0xf0)
        [<c0476a20>] (driver_register) from [<c0102dd4>] (do_one_initcall+0xb8/0x1f0)
        [<c0102dd4>] (do_one_initcall) from [<c0b010a0>] (kernel_init_freeable+0x294/0x2e0)
        [<c0b010a0>] (kernel_init_freeable) from [<c07e9eb8>] (kernel_init+0x8/0x10c)
        [<c07e9eb8>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
        Exception stack(0xd008bfb0 to 0xd008bff8)
        bfa0:                                     00000000 00000000 00000000 00000000
        bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
        ---[ end trace c0af40f9e2ed7cb4 ]---
      Signed-off-by: default avatarLubomir Rintel <lkundrak@v3.sk>
      [b.zolnierkie: enhance patch description a bit]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      86574155
    • Matias Karhumaa's avatar
      Bluetooth: SMP: fix crash in unpairing · 0f8a689c
      Matias Karhumaa authored
      [ Upstream commit cb28c306 ]
      
      In case unpair_device() was called through mgmt interface at the same time
      when pairing was in progress, Bluetooth kernel module crash was seen.
      
      [  600.351225] general protection fault: 0000 [#1] SMP PTI
      [  600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G           OE     4.19.0-rc1+ #1
      [  600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 05/14/2017
      [  600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
      [  600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
      [  600.351279] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246
      [  600.351282] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60
      [  600.351285] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500
      [  600.351287] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00
      [  600.351290] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800
      [  600.351292] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00
      [  600.351295] FS:  00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000
      [  600.351298] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  600.351300] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0
      [  600.351302] Call Trace:
      [  600.351325]  smp_failure+0x4f/0x70 [bluetooth]
      [  600.351345]  smp_cancel_pairing+0x74/0x80 [bluetooth]
      [  600.351370]  unpair_device+0x1c1/0x330 [bluetooth]
      [  600.351399]  hci_sock_sendmsg+0x960/0x9f0 [bluetooth]
      [  600.351409]  ? apparmor_socket_sendmsg+0x1e/0x20
      [  600.351417]  sock_sendmsg+0x3e/0x50
      [  600.351422]  sock_write_iter+0x85/0xf0
      [  600.351429]  do_iter_readv_writev+0x12b/0x1b0
      [  600.351434]  do_iter_write+0x87/0x1a0
      [  600.351439]  vfs_writev+0x98/0x110
      [  600.351443]  ? ep_poll+0x16d/0x3d0
      [  600.351447]  ? ep_modify+0x73/0x170
      [  600.351451]  do_writev+0x61/0xf0
      [  600.351455]  ? do_writev+0x61/0xf0
      [  600.351460]  __x64_sys_writev+0x1c/0x20
      [  600.351465]  do_syscall_64+0x5a/0x110
      [  600.351471]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  600.351474] RIP: 0033:0x7fb2bdb62fe0
      [  600.351477] Code: 73 01 c3 48 8b 0d b8 6e 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 69 c7 2c 00 00 75 10 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 80 01 00 48 89 04 24
      [  600.351479] RSP: 002b:00007ffe062cb8f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
      [  600.351484] RAX: ffffffffffffffda RBX: 000000000255b3d0 RCX: 00007fb2bdb62fe0
      [  600.351487] RDX: 0000000000000001 RSI: 00007ffe062cb920 RDI: 0000000000000004
      [  600.351490] RBP: 00007ffe062cb920 R08: 000000000255bd80 R09: 0000000000000000
      [  600.351494] R10: 0000000000000353 R11: 0000000000000246 R12: 0000000000000001
      [  600.351497] R13: 00007ffe062cbbe0 R14: 0000000000000000 R15: 0000000000000000
      [  600.351501] Modules linked in: algif_hash algif_skcipher af_alg cmac ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter bridge stp llc overlay arc4 nls_iso8859_1 dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp dell_laptop kvm_intel crct10dif_pclmul dell_smm_hwmon crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media hid_multitouch input_leds joydev serio_raw dell_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic dell_smbios dcdbas sparse_keymap
      [  600.351569]  snd_hda_intel btusb snd_hda_codec btrtl btbcm btintel snd_hda_core bluetooth(OE) snd_hwdep snd_pcm iwlmvm ecdh_generic wmi_bmof dell_wmi_descriptor snd_seq_midi mac80211 snd_seq_midi_event lpc_ich iwlwifi snd_rawmidi snd_seq snd_seq_device snd_timer cfg80211 snd soundcore mei_me mei dell_rbtn dell_smo8800 mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid hid i915 nouveau kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi psmouse ahci sdhci_pci cqhci libahci fb_sys_fops sdhci drm e1000e video wmi
      [  600.351637] ---[ end trace e49e9f1df09c94fb ]---
      [  600.351664] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
      [  600.351666] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
      [  600.351669] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246
      [  600.351672] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60
      [  600.351674] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500
      [  600.351676] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00
      [  600.351679] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800
      [  600.351681] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00
      [  600.351684] FS:  00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000
      [  600.351686] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  600.351689] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0
      
      Crash happened because list_del_rcu() was called twice for smp->ltk. This
      was possible if unpair_device was called right after ltk was generated
      but before keys were distributed.
      
      In this commit smp_cancel_pairing was refactored to cancel pairing if it
      is in progress and otherwise just removes keys. Once keys are removed from
      rcu list, pointers to smp context's keys are set to NULL to make sure
      removed list items are not accessed later.
      
      This commit also adjusts the functionality of mgmt unpair_device() little
      bit. Previously pairing was canceled only if pairing was in state that
      keys were already generated. With this commit unpair_device() cancels
      pairing already in earlier states.
      
      Bug was found by fuzzing kernel SMP implementation using Synopsys
      Defensics.
      Reported-by: default avatarPekka Oikarainen <pekka.oikarainen@synopsys.com>
      Signed-off-by: default avatarMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0f8a689c
    • Martin Willi's avatar
      mac80211_hwsim: do not omit multicast announce of first added radio · db2a11e7
      Martin Willi authored
      [ Upstream commit 28ef8b49 ]
      
      The allocation of hwsim radio identifiers uses a post-increment from 0,
      so the first radio has idx 0. This idx is explicitly excluded from
      multicast announcements ever since, but it is unclear why.
      
      Drop that idx check and announce the first radio as well. This makes
      userspace happy if it relies on these events.
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      db2a11e7
    • Masashi Honma's avatar
      nl80211: Fix possible Spectre-v1 for NL80211_TXRATE_HT · c7b66583
      Masashi Honma authored
      [ Upstream commit 30fe6d50 ]
      
      Use array_index_nospec() to sanitize ridx with respect to speculation.
      Signed-off-by: default avatarMasashi Honma <masashi.honma@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c7b66583
    • Zhao Qiang's avatar
      soc: fsl: qe: Fix copy/paste bug in ucc_get_tdm_sync_shift() · fa1578ec
      Zhao Qiang authored
      [ Upstream commit 96fc7433 ]
      
      There is a copy and paste bug so we accidentally use the RX_ shift when
      we're in TX_ mode.
      
      Fixes: bb8b2062 ("fsl/qe: setup clock source for TDM mode")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarZhao Qiang <qiang.zhao@nxp.com>
      Signed-off-by: default avatarLi Yang <leoyang.li@nxp.com>
      (cherry picked from commit 3cb31b634052ed458922e0c8e2b4b093d7fb60b9)
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fa1578ec
    • Alexandre Belloni's avatar
      soc: fsl: qbman: qman: avoid allocating from non existing gen_pool · 795b1303
      Alexandre Belloni authored
      [ Upstream commit 64e9e22e ]
      
      If the qman driver didn't probe, calling qman_alloc_fqid_range,
      qman_alloc_pool_range or qman_alloc_cgrid_range (as done in dpaa_eth) will
      pass a NULL pointer to gen_pool_alloc, leading to a NULL pointer
      dereference.
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Reviewed-by: default avatarRoy Pledge <roy.pledge@nxp.com>
      Signed-off-by: default avatarLi Yang <leoyang.li@nxp.com>
      (cherry picked from commit f72487a2788aa70c3aee1d0ebd5470de9bac953a)
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      795b1303
    • Michal Simek's avatar
      net: macb: Clean 64b dma addresses if they are not detected · d9e74276
      Michal Simek authored
      [ Upstream commit e1e5d8a9 ]
      
      Clear ADDR64 dma bit in DMACFG register in case that HW_DMA_CAP_64B is
      not detected on 64bit system.
      The issue was observed when bootloader(u-boot) does not check macb
      feature at DCFG6 register (DAW64_OFFSET) and enabling 64bit dma support
      by default. Then macb driver is reading DMACFG register back and only
      adding 64bit dma configuration but not cleaning it out.
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d9e74276
    • Florian Fainelli's avatar
      ARM: dts: BCM63xx: Fix incorrect interrupt specifiers · a5bdfc68
      Florian Fainelli authored
      [ Upstream commit 3ab97942 ]
      
      A number of our interrupts were incorrectly specified, fix both the PPI
      and SPI interrupts to be correct.
      
      Fixes: b5762cac ("ARM: bcm63138: add NAND DT support")
      Fixes: 46d4bca0 ("ARM: BCM63XX: add BCM63138 minimal Device Tree")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a5bdfc68
    • Steve Capper's avatar
      arm64: hugetlb: Fix handling of young ptes · 1241679c
      Steve Capper authored
      [ Upstream commit 469ed9d8 ]
      
      In the contiguous bit hugetlb break-before-make code we assume that all
      hugetlb pages are young.
      
      In fact, remove_migration_pte is able to place an old hugetlb pte so
      this assumption is not valid.
      
      This patch fixes the contiguous hugetlb scanning code to preserve young
      ptes.
      
      Fixes: d8bdcff2 ("arm64: hugetlb: Add break-before-make logic for contiguous entries")
      Signed-off-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1241679c
    • David Ahern's avatar
      netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev · 11577134
      David Ahern authored
      [ Upstream commit a173f066 ]
      
      For starters, the bridge netfilter code registers operations that
      are invoked any time nh_hook is called. Specifically, ip_sabotage_in
      watches for nested calls for NF_INET_PRE_ROUTING when a bridge is in
      the stack.
      
      Packet wise, the bridge netfilter hook runs first. br_nf_pre_routing
      allocates nf_bridge, sets in_prerouting to 1 and calls NF_HOOK for
      NF_INET_PRE_ROUTING. It's finish function, br_nf_pre_routing_finish,
      then resets in_prerouting flag to 0 and the packet continues up the
      stack. The packet eventually makes it to the VRF driver and it invokes
      nf_hook for NF_INET_PRE_ROUTING in case any rules have been added against
      the vrf device.
      
      Because of the registered operations the call to nf_hook causes
      ip_sabotage_in to be invoked. That function sees the nf_bridge on the
      skb and that in_prerouting is not set. Thinking it is an invalid nested
      call it steals (drops) the packet.
      
      Update ip_sabotage_in to recognize that the bridge or one of its upper
      devices (e.g., vlan) can be enslaved to a VRF (L3 master device) and
      allow the packet to go through the nf_hook a second time.
      
      Fixes: 73e20b76 ("net: vrf: Add support for PREROUTING rules on vrf device")
      Reported-by: default avatarD'Souza, Nelson <ndsouza@ciena.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      11577134
    • Sean Tranchetti's avatar
      xfrm: validate template mode · 26c6b9da
      Sean Tranchetti authored
      [ Upstream commit 32bf94fb ]
      
      XFRM mode parameters passed as part of the user templates
      in the IP_XFRM_POLICY are never properly validated. Passing
      values other than valid XFRM modes can cause stack-out-of-bounds
      reads to occur later in the XFRM processing:
      
      [  140.535608] ================================================================
      [  140.543058] BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x17e4/0x1cc4
      [  140.550306] Read of size 4 at addr ffffffc0238a7a58 by task repro/5148
      [  140.557369]
      [  140.558927] Call trace:
      [  140.558936] dump_backtrace+0x0/0x388
      [  140.558940] show_stack+0x24/0x30
      [  140.558946] __dump_stack+0x24/0x2c
      [  140.558949] dump_stack+0x8c/0xd0
      [  140.558956] print_address_description+0x74/0x234
      [  140.558960] kasan_report+0x240/0x264
      [  140.558963] __asan_report_load4_noabort+0x2c/0x38
      [  140.558967] xfrm_state_find+0x17e4/0x1cc4
      [  140.558971] xfrm_resolve_and_create_bundle+0x40c/0x1fb8
      [  140.558975] xfrm_lookup+0x238/0x1444
      [  140.558977] xfrm_lookup_route+0x48/0x11c
      [  140.558984] ip_route_output_flow+0x88/0xc4
      [  140.558991] raw_sendmsg+0xa74/0x266c
      [  140.558996] inet_sendmsg+0x258/0x3b0
      [  140.559002] sock_sendmsg+0xbc/0xec
      [  140.559005] SyS_sendto+0x3a8/0x5a8
      [  140.559008] el0_svc_naked+0x34/0x38
      [  140.559009]
      [  140.592245] page dumped because: kasan: bad access detected
      [  140.597981] page_owner info is not active (free page?)
      [  140.603267]
      [  140.653503] ================================================================
      Signed-off-by: default avatarSean Tranchetti <stranche@codeaurora.org>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      26c6b9da
    • Thomas Petazzoni's avatar
      ARM: 8799/1: mm: fix pci_ioremap_io() offset check · 5d7bf7b4
      Thomas Petazzoni authored
      [ Upstream commit 3a58ac65 ]
      
      IO_SPACE_LIMIT is the ending address of the PCI IO space, i.e
      something like 0xfffff (and not 0x100000).
      
      Therefore, when offset = 0xf0000 is passed as argument, this function
      fails even though the offset + SZ_64K fits below the
      IO_SPACE_LIMIT. This makes the last chunk of 64 KB of the I/O space
      not usable as it cannot be mapped.
      
      This patch fixes that by substracing 1 to offset + SZ_64K, so that we
      compare the addrss of the last byte of the I/O space against
      IO_SPACE_LIMIT instead of the address of the first byte of what is
      after the I/O space.
      
      Fixes: c2794437 ("ARM: Add fixed PCI i/o mapping")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5d7bf7b4
    • Steffen Klassert's avatar
      xfrm: Fix NULL pointer dereference when skb_dst_force clears the dst_entry. · 73c6f860
      Steffen Klassert authored
      [ Upstream commit 9e143793 ]
      
      Since commit 222d7dbd ("net: prevent dst uses after free")
      skb_dst_force() might clear the dst_entry attached to the skb.
      The xfrm code don't expect this to happen, so we crash with
      a NULL pointer dereference in this case. Fix it by checking
      skb_dst(skb) for NULL after skb_dst_force() and drop the packet
      in cast the dst_entry was cleared.
      
      Fixes: 222d7dbd ("net: prevent dst uses after free")
      Reported-by: default avatarTobias Hommel <netdev-list@genoetigt.de>
      Reported-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Reported-by: default avatarWolfgang Walter <linux@stwm.de>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      73c6f860
    • Yuan-Chi Pang's avatar
      mac80211: fix TX status reporting for ieee80211s · 35507aab
      Yuan-Chi Pang authored
      [ Upstream commit c4205510 ]
      
      TX status reporting to ieee80211s is through ieee80211s_update_metric.
      There are two problems about ieee80211s_update_metric:
      
      1. The purpose is to estimate the fail probability
      to a specific link. No need to restrict to data frame.
      
      2. Current implementation does not work if wireless driver does not
      pass tx_status with skb.
      
      Fix this by removing ieee80211_is_data condition, passing
      ieee80211_tx_status directly to ieee80211s_update_metric, and
      putting it in both __ieee80211_tx_status and ieee80211_tx_status_ext.
      Signed-off-by: default avatarYuan-Chi Pang <fu3mo6goo@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      35507aab
    • Johannes Berg's avatar
      mac80211: TDLS: fix skb queue/priority assignment · ebec37ed
      Johannes Berg authored
      [ Upstream commit cb59bc14 ]
      
      If the TDLS setup happens over a connection to an AP that
      doesn't have QoS, we nevertheless assign a non-zero TID
      (skb->priority) and queue mapping, which may confuse us or
      drivers later.
      
      Fix it by just assigning the special skb->priority and then
      using ieee80211_select_queue() just like other data frames
      would go through.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ebec37ed
    • Jouni Malinen's avatar
      cfg80211: Address some corner cases in scan result channel updating · 9da59d2e
      Jouni Malinen authored
      [ Upstream commit 119f94a6 ]
      
      cfg80211_get_bss_channel() is used to update the RX channel based on the
      available frame payload information (channel number from DSSS Parameter
      Set element or HT Operation element). This is needed on 2.4 GHz channels
      where frames may be received on neighboring channels due to overlapping
      frequency range.
      
      This might of some use on the 5 GHz band in some corner cases, but
      things are more complex there since there is no n:1 or 1:n mapping
      between channel numbers and frequencies due to multiple different
      starting frequencies in different operating classes. This could result
      in ieee80211_channel_to_frequency() returning incorrect frequency and
      ieee80211_get_channel() returning incorrect channel information (or
      indication of no match). In the previous implementation, this could
      result in some scan results being dropped completely, e.g., for the 4.9
      GHz channels. That prevented connection to such BSSs.
      
      Fix this by using the driver-provided channel pointer if
      ieee80211_get_channel() does not find matching channel data for the
      channel number in the frame payload and if the scan is done with 5 MHz
      or 10 MHz channel bandwidth. While doing this, also add comments
      describing what the function is trying to achieve to make it easier to
      understand what happens here and why.
      Signed-off-by: default avatarJouni Malinen <jouni@codeaurora.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9da59d2e
    • Bob Copeland's avatar
      mac80211: fix pending queue hang due to TX_DROP · 574be53a
      Bob Copeland authored
      [ Upstream commit 6eae4a6c ]
      
      In our environment running lots of mesh nodes, we are seeing the
      pending queue hang periodically, with the debugfs queues file showing
      lines such as:
      
          00: 0x00000000/348
      
      i.e. there are a large number of frames but no stop reason set.
      
      One way this could happen is if queue processing from the pending
      tasklet exited early without processing all frames, and without having
      some future event (incoming frame, stop reason flag, ...) to reschedule
      it.
      
      Exactly this can occur today if ieee80211_tx() returns false due to
      packet drops or power-save buffering in the tx handlers.  In the
      past, this function would return true in such cases, and the change
      to false doesn't seem to be intentional.  Fix this case by reverting
      to the previous behavior.
      
      Fixes: bb42f2d1 ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue")
      Signed-off-by: default avatarBob Copeland <bobcopeland@fb.com>
      Acked-by: default avatarToke Høiland-Jørgensen <toke@toke.dk>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      574be53a
    • Andrei Otcheretianski's avatar
      cfg80211: reg: Init wiphy_idx in regulatory_hint_core() · d46c334f
      Andrei Otcheretianski authored
      [ Upstream commit 24f33e64 ]
      
      Core regulatory hints didn't set wiphy_idx to WIPHY_IDX_INVALID. Since
      the regulatory request is zeroed, wiphy_idx was always implicitly set to
      0. This resulted in updating only phy #0.
      Fix that.
      
      Fixes: 806a9e39 ("cfg80211: make regulatory_request use wiphy_idx instead of wiphy")
      Signed-off-by: default avatarAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      [add fixes tag]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d46c334f
    • Andrei Otcheretianski's avatar
      mac80211: Always report TX status · b0be0d83
      Andrei Otcheretianski authored
      [ Upstream commit 8682250b ]
      
      If a frame is dropped for any reason, mac80211 wouldn't report the TX
      status back to user space.
      
      As the user space may rely on the TX_STATUS to kick its state
      machines, resends etc, it's better to just report this frame as not
      acked instead.
      Signed-off-by: default avatarAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b0be0d83
    • Sowmini Varadhan's avatar
      xfrm: reset crypto_done when iterating over multiple input xfrms · 64f38286
      Sowmini Varadhan authored
      [ Upstream commit 782710e3 ]
      
      We only support one offloaded xfrm (we do not have devices that
      can handle more than one offload), so reset crypto_done in
      xfrm_input() when iterating over multiple transforms in xfrm_input,
      so that we can invoke the appropriate x->type->input for the
      non-offloaded transforms
      
      Fixes: d77e38e6 ("xfrm: Add an IPsec hardware offloading API")
      Signed-off-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      64f38286
    • Sowmini Varadhan's avatar
      xfrm: reset transport header back to network header after all input transforms ahave been applied · a95d9004
      Sowmini Varadhan authored
      [ Upstream commit bfc0698b ]
      
      A policy may have been set up with multiple transforms (e.g., ESP
      and ipcomp). In this situation, the ingress IPsec processing
      iterates in xfrm_input() and applies each transform in turn,
      processing the nexthdr to find any additional xfrm that may apply.
      
      This patch resets the transport header back to network header
      only after the last transformation so that subsequent xfrms
      can find the correct transport header.
      
      Fixes: 7785bba2 ("esp: Add a software GRO codepath")
      Suggested-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a95d9004