1. 06 Dec, 2018 1 commit
  2. 27 Nov, 2018 2 commits
  3. 29 Oct, 2018 1 commit
  4. 20 Oct, 2018 36 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.162 · 24c2342b
      Greg Kroah-Hartman authored
      24c2342b
    • Long Li's avatar
      HV: properly delay KVP packets when negotiation is in progress · e34c69f2
      Long Li authored
      commit a3ade8cc upstream.
      
      The host may send multiple negotiation packets
      (due to timeout) before the KVP user-mode daemon
      is connected. KVP user-mode daemon is connected.
      We need to defer processing those packets
      until the daemon is negotiated and connected.
      It's okay for guest to respond
      to all negotiation packets.
      
      In addition, the host may send multiple staged
      KVP requests as soon as negotiation is done.
      We need to properly process those packets using one
      tasklet for exclusive access to ring buffer.
      
      This patch is based on the work of
      Nick Meier <Nick.Meier@microsoft.com>.
      
      The above is the original changelog of
      a3ade8cc ("HV: properly delay KVP packets when negotiation is in progress"
      
      Here I re-worked the original patch because the mainline version
      can't work for the linux-4.4.y branch, on which channel->callback_event
      doesn't exist yet. In the mainline, channel->callback_event was added by:
      631e63a9 ("vmbus: change to per channel tasklet"). Here we don't want
      to backport it to v4.4, as it requires extra supporting changes and fixes,
      which are unnecessary as to the KVP bug we're trying to resolve.
      
      NOTE: before this patch is used, we should cherry-pick the other related
      3 patches from the mainline first:
      
      The background of this backport request is that: recently Wang Jian reported
      some KVP issues: https://github.com/LIS/lis-next/issues/593:
      e.g. the /var/lib/hyperv/.kvp_pool_* files can not be updated, and sometimes
      if the hv_kvp_daemon doesn't timely start, the host may not be able to query
      the VM's IP address via KVP.
      Reported-by: 's avatarWang Jian <jianjian.wang1@gmail.com>
      Tested-by: 's avatarWang Jian <jianjian.wang1@gmail.com>
      Signed-off-by: 's avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: 's avatarLong Li <longli@microsoft.com>
      Signed-off-by: 's avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e34c69f2
    • Vitaly Kuznetsov's avatar
      Drivers: hv: kvp: fix IP Failover · 43fea648
      Vitaly Kuznetsov authored
      commit 4dbfc2e6 upstream.
      
      Hyper-V VMs can be replicated to another hosts and there is a feature to
      set different IP for replicas, it is called 'Failover TCP/IP'. When
      such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon
      as we finish negotiation procedure. The problem is that it can happen (and
      it actually happens) before userspace daemon connects and we reply with
      HV_E_FAIL to the message. As there are no repetitions we fail to set the
      requested IP.
      
      Solve the issue by postponing our reply to the negotiation message till
      userspace daemon is connected. We can't wait too long as there is a
      host-side timeout (cca. 75 seconds) and if we fail to reply in this time
      frame the whole KVP service will become inactive. The solution is not
      ideal - if it takes userspace daemon more than 60 seconds to connect
      IP Failover will still fail but I don't see a solution with our current
      separation between kernel and userspace parts.
      
      Other two modules (VSS and FCOPY) don't require such delay, leave them
      untouched.
      Signed-off-by: 's avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: 's avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: 's avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43fea648
    • K. Y. Srinivasan's avatar
      Drivers: hv: util: Pass the channel information during the init call · eaee7976
      K. Y. Srinivasan authored
      commit b9830d12 upstream.
      
      Pass the channel information to the util drivers that need to defer
      reading the channel while they are processing a request. This would address
      the following issue reported by Vitaly:
      
      Commit 3cace4a6 ("Drivers: hv: utils: run polling callback always in
      interrupt context") removed direct *_transaction.state = HVUTIL_READY
      assignments from *_handle_handshake() functions introducing the following
      race: if a userspace daemon connects before we get first non-negotiation
      request from the server hv_poll_channel() won't set transaction state to
      HVUTIL_READY as (!channel) condition will fail, we set it to non-NULL on
      the first real request from the server.
      Signed-off-by: 's avatarK. Y. Srinivasan <kys@microsoft.com>
      Reported-by: 's avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: 's avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eaee7976
    • K. Y. Srinivasan's avatar
      Drivers: hv: utils: Invoke the poll function after handshake · f91b8b1f
      K. Y. Srinivasan authored
      commit 2d0c3b5a upstream.
      
      When the handshake with daemon is complete, we should poll the channel since
      during the handshake, we will not be processing any messages. This is a
      potential bug if the host is waiting for a response from the guest.
      I would like to thank Dexuan for pointing this out.
      Signed-off-by: 's avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: 's avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f91b8b1f
    • Stephen Warren's avatar
      usb: gadget: serial: fix oops when data rx'd after close · 68a31867
      Stephen Warren authored
      commit daa35bd9 upstream.
      
      When the gadget serial device has no associated TTY, do not pass any
      received data into the TTY layer for processing; simply drop it instead.
      This prevents the TTY layer from calling back into the gadget serial
      driver, which will then crash in e.g. gs_write_room() due to lack of
      gadget serial device to TTY association (i.e. a NULL pointer dereference).
      Signed-off-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: 's avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: 's avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      68a31867
    • Alexey Brodkin's avatar
      ARC: build: Get rid of toolchain check · 466dda64
      Alexey Brodkin authored
      commit 615f64458ad890ef94abc879a66d8b27236e733a upstream.
      
      This check is very naive: we simply test if GCC invoked without
      "-mcpu=XXX" has ARC700 define set. In that case we think that GCC
      was built with "--with-cpu=arc700" and has libgcc built for ARC700.
      
      Otherwise if ARC700 is not defined we think that everythng was built
      for ARCv2.
      
      But in reality our life is much more interesting.
      
      1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu"
         it may generate code for any ARC core).
      
      2. libgcc might be built with explicitly specified "--mcpu=YYY"
      
      That's exactly what happens in case of multilibbed toolchains:
       - GCC is configured with default settings
       - All the libs built for many different CPU flavors
      
      I.e. that check gets in the way of usage of multilibbed
      toolchains. And even non-multilibbed toolchains are affected.
      OpenEmbedded also builds GCC without "--with-cpu" because
      each and every target component later is compiled with explicitly
      set "-mcpu=ZZZ".
      Acked-by: 's avatarRob Herring <robh@kernel.org>
      Signed-off-by: 's avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: 's avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      466dda64
    • Michael Neuling's avatar
      powerpc/tm: Avoid possible userspace r1 corruption on reclaim · 5a51c554
      Michael Neuling authored
      [ Upstream commit 96dc89d526ef77604376f06220e3d2931a0bfd58 ]
      
      Current we store the userspace r1 to PACATMSCRATCH before finally
      saving it to the thread struct.
      
      In theory an exception could be taken here (like a machine check or
      SLB miss) that could write PACATMSCRATCH and hence corrupt the
      userspace r1. The SLB fault currently doesn't touch PACATMSCRATCH, but
      others do.
      
      We've never actually seen this happen but it's theoretically
      possible. Either way, the code is fragile as it is.
      
      This patch saves r1 to the kernel stack (which can't fault) before we
      turn MSR[RI] back on. PACATMSCRATCH is still used but only with
      MSR[RI] off. We then copy r1 from the kernel stack to the thread
      struct once we have MSR[RI] back on.
      Suggested-by: 's avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: 's avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: 's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a51c554
    • Michael Neuling's avatar
      powerpc/tm: Fix userspace r13 corruption · 6939b3b0
      Michael Neuling authored
      [ Upstream commit cf13435b730a502e814c63c84d93db131e563f5f ]
      
      When we treclaim we store the userspace checkpointed r13 to a scratch
      SPR and then later save the scratch SPR to the user thread struct.
      
      Unfortunately, this doesn't work as accessing the user thread struct
      can take an SLB fault and the SLB fault handler will write the same
      scratch SPRG that now contains the userspace r13.
      
      To fix this, we store r13 to the kernel stack (which can't fault)
      before we access the user thread struct.
      
      Found by running P8 guest + powervm + disable_1tb_segments + TM. Seen
      as a random userspace segfault with r13 looking like a kernel address.
      Signed-off-by: 's avatarMichael Neuling <mikey@neuling.org>
      Reviewed-by: 's avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: 's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6939b3b0
    • Nathan Chancellor's avatar
      net/mlx4: Use cpumask_available for eq->affinity_mask · 0d02fdd0
      Nathan Chancellor authored
      [ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]
      
      Clang warns that the address of a pointer will always evaluated as true
      in a boolean context:
      
      drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
      array 'eq->affinity_mask' will always evaluate to 'true'
      [-Wpointer-bool-conversion]
              if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
                  ~~~~~^~~~~~~~~~~~~
      1 warning generated.
      
      Use cpumask_available, introduced in commit f7e30f01 ("cpumask: Add
      helper cpumask_available()"), which does the proper checking and avoids
      this warning.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/86Signed-off-by: 's avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d02fdd0
    • Michael Schmitz's avatar
      Input: atakbd - fix Atari CapsLock behaviour · 6df8eb6a
      Michael Schmitz authored
      [ Upstream commit 52d2c7bf7c90217fbe875d2d76f310979c48eb83 ]
      
      The CapsLock key on Atari keyboards is not a toggle, it does send the
      normal make and break scancodes.
      
      Drop the CapsLock toggle handling code, which did cause the CapsLock
      key to merely act as a Shift key.
      Tested-by: 's avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: 's avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: 's avatarAndreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: 's avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6df8eb6a
    • Andreas Schwab's avatar
      Input: atakbd - fix Atari keymap · d200ea29
      Andreas Schwab authored
      [ Upstream commit 9e62df51be993035c577371ffee5477697a56aad ]
      
      Fix errors in Atari keymap (mostly in keypad, help and undo keys).
      
      Patch provided on debian-68k ML by Andreas Schwab <schwab@linux-m68k.org>,
      keymap array size and unhandled scancode limit adjusted to 0x73 by me.
      Tested-by: 's avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: 's avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: 's avatarAndreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: 's avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d200ea29
    • Keerthy's avatar
      clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for non-am43 SoCs · be7e497b
      Keerthy authored
      [ Upstream commit 3b7d96a0dbb6b630878597a1838fc39f808b761b ]
      
      The 32k clocksource is NONSTOP for non-am43 SoCs. Hence
      add the flag for all the other SoCs.
      Reported-by: 's avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: 's avatarKeerthy <j-keerthy@ti.com>
      Acked-by: 's avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: 's avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be7e497b
    • Jozef Balga's avatar
      media: af9035: prevent buffer overflow on write · 2a585d44
      Jozef Balga authored
      [ Upstream commit 312f73b648626a0526a3aceebb0a3192aaba05ce ]
      
      When less than 3 bytes are written to the device, memcpy is called with
      negative array size which leads to buffer overflow and kernel panic. This
      patch adds a condition and returns -EOPNOTSUPP instead.
      Fixes bugzilla issue 64871
      
      [mchehab+samsung@kernel.org: fix a merge conflict and changed the
       condition to match the patch's comment, e. g. len == 3 could
       also be valid]
      Signed-off-by: 's avatarJozef Balga <jozef.balga@gmail.com>
      Signed-off-by: 's avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a585d44
    • Andy Lutomirski's avatar
      x86/fpu: Finish excising 'eagerfpu' · 4e7ef8fc
      Andy Lutomirski authored
      commit e6365084 upstream.
      
      Now that eagerfpu= is gone, remove it from the docs and some
      comments.  Also sync the changes to tools/.
      Signed-off-by: 's avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/cf430dd4481d41280e93ac6cf0def1007a67fc8e.1476740397.git.luto@kernel.orgSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarDaniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e7ef8fc
    • Rik van Riel's avatar
      x86/fpu: Remove struct fpu::counter · 6e7d7bea
      Rik van Riel authored
      commit 3913cc35 upstream.
      
      With the lazy FPU code gone, we no longer use the counter field
      in struct fpu for anything. Get rid it.
      Signed-off-by: 's avatarRik van Riel <riel@redhat.com>
      Reviewed-by: 's avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: pbonzini@redhat.com
      Link: http://lkml.kernel.org/r/1475627678-20788-6-git-send-email-riel@redhat.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarDaniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e7d7bea
    • Andy Lutomirski's avatar
      x86/fpu: Remove use_eager_fpu() · 8c6b69cf
      Andy Lutomirski authored
      commit c592b573 upstream.
      
      This removes all the obvious code paths that depend on lazy FPU mode.
      It shouldn't change the generated code at all.
      Signed-off-by: 's avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: 's avatarRik van Riel <riel@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: pbonzini@redhat.com
      Link: http://lkml.kernel.org/r/1475627678-20788-5-git-send-email-riel@redhat.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarDaniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c6b69cf
    • Paolo Bonzini's avatar
      KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch · 84037eeb
      Paolo Bonzini authored
      commit 5a5fbdc0 upstream.
      
      It is now equal to use_eager_fpu(), which simply tests a cpufeature bit.
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarDaniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84037eeb
    • Eric Dumazet's avatar
      rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096 · dcea9310
      Eric Dumazet authored
      [ Upstream commit 0e1d6eca5113858ed2caea61a5adc03c595f6096 ]
      
      We have an impressive number of syzkaller bugs that are linked
      to the fact that syzbot was able to create a networking device
      with millions of TX (or RX) queues.
      
      Let's limit the number of RX/TX queues to 4096, this really should
      cover all known cases.
      
      A separate patch will add various cond_resched() in the loops
      handling sysfs entries at device creation and dismantle.
      
      Tested:
      
      lpaa6:~# ip link add gre-4097 numtxqueues 4097 numrxqueues 4097 type ip6gretap
      RTNETLINK answers: Invalid argument
      
      lpaa6:~# time ip link add gre-4096 numtxqueues 4096 numrxqueues 4096 type ip6gretap
      
      real	0m0.180s
      user	0m0.000s
      sys	0m0.107s
      
      Fixes: 76ff5cc9 ("rtnl: allow to specify number of rx and tx queues on device creation")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dcea9310
    • Florian Fainelli's avatar
      net: systemport: Fix wake-up interrupt race during resume · 59b6d2e5
      Florian Fainelli authored
      [ Upstream commit 45ec318578c0c22a11f5b9927d064418e1ab1905 ]
      
      The AON_PM_L2 is normally used to trigger and identify the source of a
      wake-up event. Since the RX_SYS clock is no longer turned off, we also
      have an interrupt being sent to the SYSTEMPORT INTRL_2_0 controller, and
      that interrupt remains active up until the magic packet detector is
      disabled which happens much later during the driver resumption.
      
      The race happens if we have a CPU that is entering the SYSTEMPORT
      INTRL2_0 handler during resume, and another CPU has managed to clear the
      wake-up interrupt during bcm_sysport_resume_from_wol(). In that case, we
      have the first CPU stuck in the interrupt handler with an interrupt
      cause that has been cleared under its feet, and so we keep returning
      IRQ_NONE and we never make any progress.
      
      This was not a problem before because we would always turn off the
      RX_SYS clock during WoL, so the SYSTEMPORT INTRL2_0 would also be turned
      off as well, thus not latching the interrupt.
      
      The fix is to make sure we do not enable either the MPD or
      BRCM_TAG_MATCH interrupts since those are redundant with what the
      AON_PM_L2 interrupt controller already processes and they would cause
      such a race to occur.
      
      Fixes: bb9051a2b230 ("net: systemport: Add support for WAKE_FILTER")
      Fixes: 83e82f4c ("net: systemport: add Wake-on-LAN support")
      Signed-off-by: 's avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59b6d2e5
    • Maxime Chevallier's avatar
      net: mvpp2: Extract the correct ethtype from the skb for tx csum offload · 2b2c9306
      Maxime Chevallier authored
      [ Upstream commit 35f3625c21852ad839f20c91c7d81c4c1101e207 ]
      
      When offloading the L3 and L4 csum computation on TX, we need to extract
      the l3_proto from the ethtype, independently of the presence of a vlan
      tag.
      
      The actual driver uses skb->protocol as-is, resulting in packets with
      the wrong L4 checksum being sent when there's a vlan tag in the packet
      header and checksum offloading is enabled.
      
      This commit makes use of vlan_protocol_get() to get the correct ethtype
      regardless the presence of a vlan tag.
      
      Fixes: 3f518509 ("ethernet: Add new driver for Marvell Armada 375 network unit")
      Signed-off-by: 's avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b2c9306
    • Ido Schimmel's avatar
      team: Forbid enslaving team device to itself · e0fff899
      Ido Schimmel authored
      [ Upstream commit 471b83bd8bbe4e89743683ef8ecb78f7029d8288 ]
      
      team's ndo_add_slave() acquires 'team->lock' and later tries to open the
      newly enslaved device via dev_open(). This emits a 'NETDEV_UP' event
      that causes the VLAN driver to add VLAN 0 on the team device. team's
      ndo_vlan_rx_add_vid() will also try to acquire 'team->lock' and
      deadlock.
      
      Fix this by checking early at the enslavement function that a team
      device is not being enslaved to itself.
      
      A similar check was added to the bond driver in commit 09a89c21
      ("bonding: disallow enslaving a bond to itself").
      
      WARNING: possible recursive locking detected
      4.18.0-rc7+ #176 Not tainted
      --------------------------------------------
      syz-executor4/6391 is trying to acquire lock:
      (____ptrval____) (&team->lock){+.+.}, at: team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
      
      but task is already holding lock:
      (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&team->lock);
        lock(&team->lock);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      2 locks held by syz-executor4/6391:
       #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline]
       #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4662
       #1: (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
      
      stack backtrace:
      CPU: 1 PID: 6391 Comm: syz-executor4 Not tainted 4.18.0-rc7+ #176
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
       print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
       check_deadlock kernel/locking/lockdep.c:1809 [inline]
       validate_chain kernel/locking/lockdep.c:2405 [inline]
       __lock_acquire.cold.64+0x1fb/0x486 kernel/locking/lockdep.c:3435
       lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
       __mutex_lock_common kernel/locking/mutex.c:757 [inline]
       __mutex_lock+0x176/0x1820 kernel/locking/mutex.c:894
       mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:909
       team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
       vlan_add_rx_filter_info+0x14a/0x1d0 net/8021q/vlan_core.c:210
       __vlan_vid_add net/8021q/vlan_core.c:278 [inline]
       vlan_vid_add+0x63e/0x9d0 net/8021q/vlan_core.c:308
       vlan_device_event.cold.12+0x2a/0x2f net/8021q/vlan.c:381
       notifier_call_chain+0x180/0x390 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
       call_netdevice_notifiers net/core/dev.c:1753 [inline]
       dev_open+0x173/0x1b0 net/core/dev.c:1433
       team_port_add drivers/net/team/team.c:1219 [inline]
       team_add_slave+0xa8b/0x1c30 drivers/net/team/team.c:1948
       do_set_master+0x1c9/0x220 net/core/rtnetlink.c:2248
       do_setlink+0xba4/0x3e10 net/core/rtnetlink.c:2382
       rtnl_setlink+0x2a9/0x400 net/core/rtnetlink.c:2636
       rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665
       netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2455
       rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683
       netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
       netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
       netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1908
       sock_sendmsg_nosec net/socket.c:642 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:652
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2126
       __sys_sendmsg+0x11d/0x290 net/socket.c:2164
       __do_sys_sendmsg net/socket.c:2173 [inline]
       __se_sys_sendmsg net/socket.c:2171 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x456b29
      Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f9706bf8c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f9706bf96d4 RCX: 0000000000456b29
      RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004
      RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000004d3548 R14: 00000000004c8227 R15: 0000000000000000
      
      Fixes: 87002b03 ("net: introduce vlan_vid_[add/del] and use them instead of direct [add/kill]_vid ndo calls")
      Signed-off-by: 's avatarIdo Schimmel <idosch@mellanox.com>
      Reported-and-tested-by: syzbot+bd051aba086537515cdb@syzkaller.appspotmail.com
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0fff899
    • Shahed Shaikh's avatar
      qlcnic: fix Tx descriptor corruption on 82xx devices · 2f04cacd
      Shahed Shaikh authored
      [ Upstream commit c333fa0c4f220f8f7ea5acd6b0ebf3bf13fd684d ]
      
      In regular NIC transmission flow, driver always configures MAC using
      Tx queue zero descriptor as a part of MAC learning flow.
      But with multi Tx queue supported NIC, regular transmission can occur on
      any non-zero Tx queue and from that context it uses
      Tx queue zero descriptor to configure MAC, at the same time TX queue
      zero could be used by another CPU for regular transmission
      which could lead to Tx queue zero descriptor corruption and cause FW
      abort.
      
      This patch fixes this in such a way that driver always configures
      learned MAC address from the same Tx queue which is used for
      regular transmission.
      
      Fixes: 7e2cf4fe ("qlcnic: change driver hardware interface mechanism")
      Signed-off-by: 's avatarShahed Shaikh <shahed.shaikh@cavium.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f04cacd
    • Yu Zhao's avatar
      net/usb: cancel pending work when unbinding smsc75xx · 0aa059ea
      Yu Zhao authored
      [ Upstream commit f7b2a56e1f3dcbdb4cf09b2b63e859ffe0e09df8 ]
      
      Cancel pending work before freeing smsc75xx private data structure
      during binding. This fixes the following crash in the driver:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      IP: mutex_lock+0x2b/0x3f
      <snipped>
      Workqueue: events smsc75xx_deferred_multicast_write [smsc75xx]
      task: ffff8caa83e85700 task.stack: ffff948b80518000
      RIP: 0010:mutex_lock+0x2b/0x3f
      <snipped>
      Call Trace:
       smsc75xx_deferred_multicast_write+0x40/0x1af [smsc75xx]
       process_one_work+0x18d/0x2fc
       worker_thread+0x1a2/0x269
       ? pr_cont_work+0x58/0x58
       kthread+0xfa/0x10a
       ? pr_cont_work+0x58/0x58
       ? rcu_read_unlock_sched_notrace+0x48/0x48
       ret_from_fork+0x22/0x40
      Signed-off-by: 's avatarYu Zhao <yuzhao@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0aa059ea
    • Sean Tranchetti's avatar
      netlabel: check for IPV4MASK in addrinfo_get · 1f3a2366
      Sean Tranchetti authored
      [ Upstream commit f88b4c01b97e09535505cf3c327fdbce55c27f00 ]
      
      netlbl_unlabel_addrinfo_get() assumes that if it finds the
      NLBL_UNLABEL_A_IPV4ADDR attribute, it must also have the
      NLBL_UNLABEL_A_IPV4MASK attribute as well. However, this is
      not necessarily the case as the current checks in
      netlbl_unlabel_staticadd() and friends are not sufficent to
      enforce this.
      
      If passed a netlink message with NLBL_UNLABEL_A_IPV4ADDR,
      NLBL_UNLABEL_A_IPV6ADDR, and NLBL_UNLABEL_A_IPV6MASK attributes,
      these functions will all call netlbl_unlabel_addrinfo_get() which
      will then attempt dereference NULL when fetching the non-existent
      NLBL_UNLABEL_A_IPV4MASK attribute:
      
      Unable to handle kernel NULL pointer dereference at virtual address 0
      Process unlab (pid: 31762, stack limit = 0xffffff80502d8000)
      Call trace:
      	netlbl_unlabel_addrinfo_get+0x44/0xd8
      	netlbl_unlabel_staticremovedef+0x98/0xe0
      	genl_rcv_msg+0x354/0x388
      	netlink_rcv_skb+0xac/0x118
      	genl_rcv+0x34/0x48
      	netlink_unicast+0x158/0x1f0
      	netlink_sendmsg+0x32c/0x338
      	sock_sendmsg+0x44/0x60
      	___sys_sendmsg+0x1d0/0x2a8
      	__sys_sendmsg+0x64/0xb4
      	SyS_sendmsg+0x34/0x4c
      	el0_svc_naked+0x34/0x38
      Code: 51001149 7100113f 540000a0 f9401508 (79400108)
      ---[ end trace f6438a488e737143 ]---
      Kernel panic - not syncing: Fatal exception
      Signed-off-by: 's avatarSean Tranchetti <stranche@codeaurora.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f3a2366
    • Jeff Barnhill's avatar
      net/ipv6: Display all addresses in output of /proc/net/if_inet6 · 9ee4a60d
      Jeff Barnhill authored
      [ Upstream commit 86f9bd1ff61c413a2a251fa736463295e4e24733 ]
      
      The backend handling for /proc/net/if_inet6 in addrconf.c doesn't properly
      handle starting/stopping the iteration.  The problem is that at some point
      during the iteration, an overflow is detected and the process is
      subsequently stopped.  The item being shown via seq_printf() when the
      overflow occurs is not actually shown, though.  When start() is
      subsequently called to resume iterating, it returns the next item, and
      thus the item that was being processed when the overflow occurred never
      gets printed.
      
      Alter the meaning of the private data member "offset".  Currently, when it
      is not 0 (which only happens at the very beginning), "offset" represents
      the next hlist item to be printed.  After this change, "offset" always
      represents the current item.
      
      This is also consistent with the private data member "bucket", which
      represents the current bucket, and also the use of "pos" as defined in
      seq_file.txt:
          The pos passed to start() will always be either zero, or the most
          recent pos used in the previous session.
      Signed-off-by: 's avatarJeff Barnhill <0xeffeff@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ee4a60d
    • Sabrina Dubroca's avatar
      net: ipv4: update fnhe_pmtu when first hop's MTU changes · 2b7e4c73
      Sabrina Dubroca authored
      [ Upstream commit af7d6cce53694a88d6a1bb60c9a239a6a5144459 ]
      
      Since commit 5aad1de5 ("ipv4: use separate genid for next hop
      exceptions"), exceptions get deprecated separately from cached
      routes. In particular, administrative changes don't clear PMTU anymore.
      
      As Stefano described in commit e9fa1495d738 ("ipv6: Reflect MTU changes
      on PMTU of exceptions for MTU-less routes"), the PMTU discovered before
      the local MTU change can become stale:
       - if the local MTU is now lower than the PMTU, that PMTU is now
         incorrect
       - if the local MTU was the lowest value in the path, and is increased,
         we might discover a higher PMTU
      
      Similarly to what commit e9fa1495d738 did for IPv6, update PMTU in those
      cases.
      
      If the exception was locked, the discovered PMTU was smaller than the
      minimal accepted PMTU. In that case, if the new local MTU is smaller
      than the current PMTU, let PMTU discovery figure out if locking of the
      exception is still needed.
      
      To do this, we need to know the old link MTU in the NETDEV_CHANGEMTU
      notifier. By the time the notifier is called, dev->mtu has been
      changed. This patch adds the old MTU as additional information in the
      notifier structure, and a new call_netdevice_notifiers_u32() function.
      
      Fixes: 5aad1de5 ("ipv4: use separate genid for next hop exceptions")
      Signed-off-by: 's avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: 's avatarStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: 's avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b7e4c73
    • Eric Dumazet's avatar
      ipv4: fix use-after-free in ip_cmsg_recv_dstaddr() · d7148eeb
      Eric Dumazet authored
      [ Upstream commit 64199fc0a46ba211362472f7f942f900af9492fd ]
      
      Caching ip_hdr(skb) before a call to pskb_may_pull() is buggy,
      do not do it.
      
      Fixes: 2efd4fca703a ("ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: 's avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7148eeb
    • Paolo Abeni's avatar
      ip_tunnel: be careful when accessing the inner header · f9d35728
      Paolo Abeni authored
      [ Upstream commit ccfec9e5cb2d48df5a955b7bf47f7782157d3bc2]
      
      Cong noted that we need the same checks introduced by commit 76c0ddd8c3a6
      ("ip6_tunnel: be careful when accessing the inner header")
      even for ipv4 tunnels.
      
      Fixes: c5441932 ("GRE: Refactor GRE tunneling code.")
      Suggested-by: 's avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: 's avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9d35728
    • Paolo Abeni's avatar
      ip6_tunnel: be careful when accessing the inner header · 20f16d1a
      Paolo Abeni authored
      [ Upstream commit 76c0ddd8c3a683f6e2c6e60e11dc1a1558caf4bc ]
      
      the ip6 tunnel xmit ndo assumes that the processed skb always
      contains an ip[v6] header, but syzbot has found a way to send
      frames that fall short of this assumption, leading to the following splat:
      
      BUG: KMSAN: uninit-value in ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307
      [inline]
      BUG: KMSAN: uninit-value in ip6_tnl_start_xmit+0x7d2/0x1ef0
      net/ipv6/ip6_tunnel.c:1390
      CPU: 0 PID: 4504 Comm: syz-executor558 Not tainted 4.16.0+ #87
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:17 [inline]
        dump_stack+0x185/0x1d0 lib/dump_stack.c:53
        kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
        __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
        ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307 [inline]
        ip6_tnl_start_xmit+0x7d2/0x1ef0 net/ipv6/ip6_tunnel.c:1390
        __netdev_start_xmit include/linux/netdevice.h:4066 [inline]
        netdev_start_xmit include/linux/netdevice.h:4075 [inline]
        xmit_one net/core/dev.c:3026 [inline]
        dev_hard_start_xmit+0x5f1/0xc70 net/core/dev.c:3042
        __dev_queue_xmit+0x27ee/0x3520 net/core/dev.c:3557
        dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
        packet_snd net/packet/af_packet.c:2944 [inline]
        packet_sendmsg+0x7c70/0x8a30 net/packet/af_packet.c:2969
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg net/socket.c:640 [inline]
        ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
        __sys_sendmmsg+0x42d/0x800 net/socket.c:2136
        SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167
        SyS_sendmmsg+0x63/0x90 net/socket.c:2162
        do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x441819
      RSP: 002b:00007ffe58ee8268 EFLAGS: 00000213 ORIG_RAX: 0000000000000133
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441819
      RDX: 0000000000000002 RSI: 0000000020000100 RDI: 0000000000000003
      RBP: 00000000006cd018 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000402510
      R13: 00000000004025a0 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was created at:
        kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
        kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
        kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
        kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
        slab_post_alloc_hook mm/slab.h:445 [inline]
        slab_alloc_node mm/slub.c:2737 [inline]
        __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
        __kmalloc_reserve net/core/skbuff.c:138 [inline]
        __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
        alloc_skb include/linux/skbuff.h:984 [inline]
        alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
        sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
        packet_alloc_skb net/packet/af_packet.c:2803 [inline]
        packet_snd net/packet/af_packet.c:2894 [inline]
        packet_sendmsg+0x6454/0x8a30 net/packet/af_packet.c:2969
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg net/socket.c:640 [inline]
        ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
        __sys_sendmmsg+0x42d/0x800 net/socket.c:2136
        SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167
        SyS_sendmmsg+0x63/0x90 net/socket.c:2162
        do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      
      This change addresses the issue adding the needed check before
      accessing the inner header.
      
      The ipv4 side of the issue is apparently there since the ipv4 over ipv6
      initial support, and the ipv6 side predates git history.
      
      Fixes: c4d3efaf ("[IPV6] IP6TUNNEL: Add support to IPv4 over IPv6 tunnel.")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: syzbot+3fde91d4d394747d6db4@syzkaller.appspotmail.com
      Tested-by: 's avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: 's avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20f16d1a
    • Mahesh Bandewar's avatar
      bonding: avoid possible dead-lock · 2691921c
      Mahesh Bandewar authored
      [ Upstream commit d4859d749aa7090ffb743d15648adb962a1baeae ]
      
      Syzkaller reported this on a slightly older kernel but it's still
      applicable to the current kernel -
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.18.0-next-20180823+ #46 Not tainted
      ------------------------------------------------------
      syz-executor4/26841 is trying to acquire lock:
      00000000dd41ef48 ((wq_completion)bond_dev->name){+.+.}, at: flush_workqueue+0x2db/0x1e10 kernel/workqueue.c:2652
      
      but task is already holding lock:
      00000000768ab431 (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline]
      00000000768ab431 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4708
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (rtnl_mutex){+.+.}:
             __mutex_lock_common kernel/locking/mutex.c:925 [inline]
             __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
             mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
             rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
             bond_netdev_notify drivers/net/bonding/bond_main.c:1310 [inline]
             bond_netdev_notify_work+0x44/0xd0 drivers/net/bonding/bond_main.c:1320
             process_one_work+0xc73/0x1aa0 kernel/workqueue.c:2153
             worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
             kthread+0x35a/0x420 kernel/kthread.c:246
             ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
      
      -> #1 ((work_completion)(&(&nnw->work)->work)){+.+.}:
             process_one_work+0xc0b/0x1aa0 kernel/workqueue.c:2129
             worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
             kthread+0x35a/0x420 kernel/kthread.c:246
             ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
      
      -> #0 ((wq_completion)bond_dev->name){+.+.}:
             lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
             flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655
             drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820
             destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155
             __alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138
             bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734
             register_netdevice+0x337/0x1100 net/core/dev.c:8410
             bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453
             rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099
             rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711
             netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
             rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729
             netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
             netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
             netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
             sock_sendmsg_nosec net/socket.c:622 [inline]
             sock_sendmsg+0xd5/0x120 net/socket.c:632
             ___sys_sendmsg+0x7fd/0x930 net/socket.c:2115
             __sys_sendmsg+0x11d/0x290 net/socket.c:2153
             __do_sys_sendmsg net/socket.c:2162 [inline]
             __se_sys_sendmsg net/socket.c:2160 [inline]
             __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160
             do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      other info that might help us debug this:
      
      Chain exists of:
        (wq_completion)bond_dev->name --> (work_completion)(&(&nnw->work)->work) --> rtnl_mutex
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(rtnl_mutex);
                                     lock((work_completion)(&(&nnw->work)->work));
                                     lock(rtnl_mutex);
        lock((wq_completion)bond_dev->name);
      
       *** DEADLOCK ***
      
      1 lock held by syz-executor4/26841:
      
      stack backtrace:
      CPU: 1 PID: 26841 Comm: syz-executor4 Not tainted 4.18.0-next-20180823+ #46
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
       print_circular_bug.isra.34.cold.55+0x1bd/0x27d kernel/locking/lockdep.c:1222
       check_prev_add kernel/locking/lockdep.c:1862 [inline]
       check_prevs_add kernel/locking/lockdep.c:1975 [inline]
       validate_chain kernel/locking/lockdep.c:2416 [inline]
       __lock_acquire+0x3449/0x5020 kernel/locking/lockdep.c:3412
       lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
       flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655
       drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820
       destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155
       __alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138
       bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734
       register_netdevice+0x337/0x1100 net/core/dev.c:8410
       bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453
       rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099
       rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711
       netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
       rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729
       netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
       netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
       netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
       sock_sendmsg_nosec net/socket.c:622 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:632
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2115
       __sys_sendmsg+0x11d/0x290 net/socket.c:2153
       __do_sys_sendmsg net/socket.c:2162 [inline]
       __se_sys_sendmsg net/socket.c:2160 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457089
      Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f2df20a5c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f2df20a66d4 RCX: 0000000000457089
      RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003
      RBP: 0000000000930140 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000004d40b8 R14: 00000000004c8ad8 R15: 0000000000000001
      Signed-off-by: 's avatarMahesh Bandewar <maheshb@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2691921c
    • Michael Chan's avatar
      bnxt_en: Fix TX timeout during netpoll. · 4348b966
      Michael Chan authored
      [ Upstream commit 73f21c653f930f438d53eed29b5e4c65c8a0f906 ]
      
      The current netpoll implementation in the bnxt_en driver has problems
      that may miss TX completion events.  bnxt_poll_work() in effect is
      only handling at most 1 TX packet before exiting.  In addition,
      there may be in flight TX completions that ->poll() may miss even
      after we fix bnxt_poll_work() to handle all visible TX completions.
      netpoll may not call ->poll() again and HW may not generate IRQ
      because the driver does not ARM the IRQ when the budget (0 for netpoll)
      is reached.
      
      We fix it by handling all TX completions and to always ARM the IRQ
      when we exit ->poll() with 0 budget.
      
      Also, the logic to ACK the completion ring in case it is almost filled
      with TX completions need to be adjusted to take care of the 0 budget
      case, as discussed with Eric Dumazet <edumazet@google.com>
      Reported-by: 's avatarSong Liu <songliubraving@fb.com>
      Reviewed-by: 's avatarSong Liu <songliubraving@fb.com>
      Tested-by: 's avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: 's avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4348b966
    • Hou Tao's avatar
      jffs2: return -ERANGE when xattr buffer is too small · 5ac147eb
      Hou Tao authored
      When a file have multiple xattrs and the passed buffer is
      smaller than the required size, jffs2_listxattr() should
      return -ERANGE instead of continue, else Oops may occur
      due to memory corruption.
      
      Also remove the unnecessary check ("rc < 0"), because
      xhandle->list(...) will not return an error number.
      
      Spotted by generic/377 in xfstests-dev.
      
      NB: The problem had been fixed by commit 764a5c6b ("xattr
      handlers: Simplify list operation") in v4.5-rc1, but the
      modification in that commit may be too much because it modifies
      all file-systems which implement xattr, so I create a single
      patch for jffs2 to fix the problem.
      Signed-off-by: 's avatarHou Tao <houtao1@huawei.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ac147eb
    • Mathias Nyman's avatar
      xhci: Don't print a warning when setting link state for disabled ports · f37a3ff6
      Mathias Nyman authored
      commit 1208d8a8 upstream.
      
      When disabling a USB3 port the hub driver will set the port link state to
      U3 to prevent "ejected" or "safely removed" devices that are still
      physically connected from immediately re-enumerating.
      
      If the device was really unplugged, then error messages were printed
      as the hub tries to set the U3 link state for a port that is no longer
      enabled.
      
      xhci-hcd ee000000.usb: Cannot set link state.
      usb usb8-port1: cannot disable (err = -32)
      
      Don't print error message in xhci-hub if hub tries to set port link state
      for a disabled port. Return -ENODEV instead which also silences hub driver.
      Signed-off-by: 's avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Tested-by: 's avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: 's avatarRoss Zwisler <zwisler@google.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f37a3ff6
    • Edgar Cherkasov's avatar
      i2c: i2c-scmi: fix for i2c_smbus_write_block_data · 86333409
      Edgar Cherkasov authored
      commit 08d9db00fe0e300d6df976e6c294f974988226dd upstream.
      
      The i2c-scmi driver crashes when the SMBus Write Block transaction is
      executed:
      
      WARNING: CPU: 9 PID: 2194 at mm/page_alloc.c:3931 __alloc_pages_slowpath+0x9db/0xec0
       Call Trace:
        ? get_page_from_freelist+0x49d/0x11f0
        ? alloc_pages_current+0x6a/0xe0
        ? new_slab+0x499/0x690
        __alloc_pages_nodemask+0x265/0x280
        alloc_pages_current+0x6a/0xe0
        kmalloc_order+0x18/0x40
        kmalloc_order_trace+0x24/0xb0
        ? acpi_ut_allocate_object_desc_dbg+0x62/0x10c
        __kmalloc+0x203/0x220
        acpi_os_allocate_zeroed+0x34/0x36
        acpi_ut_copy_eobject_to_iobject+0x266/0x31e
        acpi_evaluate_object+0x166/0x3b2
        acpi_smbus_cmi_access+0x144/0x530 [i2c_scmi]
        i2c_smbus_xfer+0xda/0x370
        i2cdev_ioctl_smbus+0x1bd/0x270
        i2cdev_ioctl+0xaa/0x250
        do_vfs_ioctl+0xa4/0x600
        SyS_ioctl+0x79/0x90
        do_syscall_64+0x73/0x130
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      ACPI Error: Evaluating _SBW: 4 (20170831/smbus_cmi-185)
      
      This problem occurs because the length of ACPI Buffer object is not
      defined/initialized in the code before a corresponding ACPI method is
      called. The obvious patch below fixes this issue.
      Signed-off-by: 's avatarEdgar Cherkasov <echerkasov@dev.rtsoft.ru>
      Acked-by: 's avatarViktor Krasnov <vkrasnov@dev.rtsoft.ru>
      Acked-by: 's avatarMichael Brunner <Michael.Brunner@kontron.com>
      Signed-off-by: 's avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86333409
    • Adrian Hunter's avatar
      perf script python: Fix export-to-postgresql.py occasional failure · 49f80e6e
      Adrian Hunter authored
      commit 25e11700b54c7b6b5ebfc4361981dae12299557b upstream.
      
      Occasional export failures were found to be caused by truncating 64-bit
      pointers to 32-bits. Fix by explicitly setting types for all ctype
      arguments and results.
      Signed-off-by: 's avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180911114504.28516-2-adrian.hunter@intel.comSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49f80e6e