1. 05 Apr, 2019 40 commits
    • Russell King's avatar
      net: marvell: mvpp2: fix stuck in-band SGMII negotiation · a78aae93
      Russell King authored
      [ Upstream commit 316734fd ]
      
      It appears that the mvpp22 can get stuck with SGMII negotiation.  The
      symptoms are that in-band negotiation never completes and the partner
      (eg, PHY) never reports SGMII link up, or if it supports negotiation
      bypass, goes into negotiation bypass mode (which will happen when the
      PHY sees that the MAC is alive but gets no response.)
      
      Triggering the PHY end of the link to re-negotiate results in the
      bypass bit clearing on the PHY, and then re-setting - indicating that
      the problem is at the mvpp22 GMAC end.
      
      Asserting the GMAC reset and de-asserting it resolves the issue.
      Arrange to assert the GMAC reset at probe time, and deassert it only
      after we have configured the GMAC for the appropriate mode.  This
      resolves the issue.
      Tested-by: default avatarSven Auhagen <sven.auhagen@voleatech.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a78aae93
    • Thomas Gleixner's avatar
      genirq: Avoid summation loops for /proc/stat · 1f369486
      Thomas Gleixner authored
      [ Upstream commit 1136b072 ]
      
      Waiman reported that on large systems with a large amount of interrupts the
      readout of /proc/stat takes a long time to sum up the interrupt
      statistics. In principle this is not a problem. but for unknown reasons
      some enterprise quality software reads /proc/stat with a high frequency.
      
      The reason for this is that interrupt statistics are accounted per cpu. So
      the /proc/stat logic has to sum up the interrupt stats for each interrupt.
      
      This can be largely avoided for interrupts which are not marked as
      'PER_CPU' interrupts by simply adding a per interrupt summation counter
      which is incremented along with the per interrupt per cpu counter.
      
      The PER_CPU interrupts need to avoid that and use only per cpu accounting
      because they share the interrupt number and the interrupt descriptor and
      concurrent updates would conflict or require unwanted synchronization.
      Reported-by: default avatarWaiman Long <longman@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarWaiman Long <longman@redhat.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Daniel Colascione <dancol@google.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Link: https://lkml.kernel.org/r/20190208135020.925487496@linutronix.de
      
      8<-------------
      
      v2: Undo the unintentional layout change of struct irq_desc.
      
       include/linux/irqdesc.h |    1 +
       kernel/irq/chip.c       |   12 ++++++++++--
       kernel/irq/internals.h  |    8 +++++++-
       kernel/irq/irqdesc.c    |    7 ++++++-
       4 files changed, 24 insertions(+), 4 deletions(-)
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1f369486
    • Coly Li's avatar
      bcache: improve sysfs_strtoul_clamp() · 98eddc19
      Coly Li authored
      [ Upstream commit 596b5a5d ]
      
      Currently sysfs_strtoul_clamp() is defined as,
       82 #define sysfs_strtoul_clamp(file, var, min, max)                   \
       83 do {                                                               \
       84         if (attr == &sysfs_ ## file)                               \
       85                 return strtoul_safe_clamp(buf, var, min, max)      \
       86                         ?: (ssize_t) size;                         \
       87 } while (0)
      
      The problem is, if bit width of var is less then unsigned long, min and
      max may not protect var from integer overflow, because overflow happens
      in strtoul_safe_clamp() before checking min and max.
      
      To fix such overflow in sysfs_strtoul_clamp(), to make min and max take
      effect, this patch adds an unsigned long variable, and uses it to macro
      strtoul_safe_clamp() to convert an unsigned long value in range defined
      by [min, max]. Then assign this value to var. By this method, if bit
      width of var is less than unsigned long, integer overflow won't happen
      before min and max are checking.
      
      Now sysfs_strtoul_clamp() can properly handle smaller data type like
      unsigned int, of cause min and max should be defined in range of
      unsigned int too.
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      98eddc19
    • Coly Li's avatar
      bcache: fix potential div-zero error of writeback_rate_i_term_inverse · b468e000
      Coly Li authored
      [ Upstream commit c3b75a21 ]
      
      dc->writeback_rate_i_term_inverse can be set via sysfs interface. It is
      in type unsigned int, and convert from input string by d_strtoul(). The
      problem is d_strtoul() does not check valid range of the input, if
      4294967296 is written into sysfs file writeback_rate_i_term_inverse,
      an overflow of unsigned integer will happen and value 0 is set to
      dc->writeback_rate_i_term_inverse.
      
      In writeback.c:__update_writeback_rate(), there are following lines of
      code,
            integral_scaled = div_s64(dc->writeback_rate_integral,
                            dc->writeback_rate_i_term_inverse);
      If dc->writeback_rate_i_term_inverse is set to 0 via sysfs interface,
      a div-zero error might be triggered in the above code.
      
      Therefore we need to add a range limitation in the sysfs interface,
      this is what this patch does, use sysfs_stroul_clamp() to replace
      d_strtoul() and restrict the input range in [1, UINT_MAX].
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b468e000
    • Coly Li's avatar
      bcache: fix input overflow to sequential_cutoff · c7b687eb
      Coly Li authored
      [ Upstream commit 8c27a395 ]
      
      People may set sequential_cutoff of a cached device via sysfs file,
      but current code does not check input value overflow. E.g. if value
      4294967295 (UINT_MAX) is written to file sequential_cutoff, its value
      is 4GB, but if 4294967296 (UINT_MAX + 1) is written into, its value
      will be 0. This is an unexpected behavior.
      
      This patch replaces d_strtoi_h() by sysfs_strtoul_clamp() to convert
      input string to unsigned integer value, and limit its range in
      [0, UINT_MAX]. Then the input overflow can be fixed.
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c7b687eb
    • Coly Li's avatar
      bcache: fix input overflow to cache set sysfs file io_error_halflife · 16975f04
      Coly Li authored
      [ Upstream commit a91fbda4 ]
      
      Cache set sysfs entry io_error_halflife is used to set c->error_decay.
      c->error_decay is in type unsigned int, and it is converted by
      strtoul_or_return(), therefore overflow to c->error_decay is possible
      for a large input value.
      
      This patch fixes the overflow by using strtoul_safe_clamp() to convert
      input string to an unsigned long value in range [0, UINT_MAX], then
      divides by 88 and set it to c->error_decay.
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      16975f04
    • Luc Van Oostenryck's avatar
      sched/topology: Fix percpu data types in struct sd_data & struct s_data · 845d4849
      Luc Van Oostenryck authored
      [ Upstream commit 99687cdb ]
      
      The percpu members of struct sd_data and s_data are declared as:
      
      	struct ... ** __percpu member;
      
      So their type is:
      
      	__percpu pointer to pointer to struct ...
      
      But looking at how they're used, their type should be:
      
      	pointer to __percpu pointer to struct ...
      
      and they should thus be declared as:
      
      	struct ... * __percpu *member;
      
      So fix the placement of '__percpu' in the definition of these
      structures.
      
      This addresses a bunch of Sparse's warnings like:
      
      	warning: incorrect type in initializer (different address spaces)
      	  expected void const [noderef] <asn:3> *__vpp_verify
      	  got struct sched_domain **
      Signed-off-by: default avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20190118144936.79158-1-luc.vanoostenryck@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      845d4849
    • John Stultz's avatar
      usb: f_fs: Avoid crash due to out-of-scope stack ptr access · ad02fb6a
      John Stultz authored
      [ Upstream commit 54f64d5c ]
      
      Since the 5.0 merge window opened, I've been seeing frequent
      crashes on suspend and reboot with the trace:
      
      [   36.911170] Unable to handle kernel paging request at virtual address ffffff801153d660
      [   36.912769] Unable to handle kernel paging request at virtual address ffffff800004b564
      ...
      [   36.950666] Call trace:
      [   36.950670]  queued_spin_lock_slowpath+0x1cc/0x2c8
      [   36.950681]  _raw_spin_lock_irqsave+0x64/0x78
      [   36.950692]  complete+0x28/0x70
      [   36.950703]  ffs_epfile_io_complete+0x3c/0x50
      [   36.950713]  usb_gadget_giveback_request+0x34/0x108
      [   36.950721]  dwc3_gadget_giveback+0x50/0x68
      [   36.950723]  dwc3_thread_interrupt+0x358/0x1488
      [   36.950731]  irq_thread_fn+0x30/0x88
      [   36.950734]  irq_thread+0x114/0x1b0
      [   36.950739]  kthread+0x104/0x130
      [   36.950747]  ret_from_fork+0x10/0x1c
      
      I isolated this down to in ffs_epfile_io():
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/function/f_fs.c#n1065
      
      Where the completion done is setup on the stack:
        DECLARE_COMPLETION_ONSTACK(done);
      
      Then later we setup a request and queue it, and wait for it:
        if (unlikely(wait_for_completion_interruptible(&done))) {
          /*
          * To avoid race condition with ffs_epfile_io_complete,
          * dequeue the request first then check
          * status. usb_ep_dequeue API should guarantee no race
          * condition with req->complete callback.
          */
          usb_ep_dequeue(ep->ep, req);
          interrupted = ep->status < 0;
        }
      
      The problem is, that we end up being interrupted, dequeue the
      request, and exit.
      
      But then the irq triggers and we try calling complete() on the
      context pointer which points to now random stack space, which
      results in the panic.
      
      Alan Stern pointed out there is a bug here, in that the snippet
      above "assumes that usb_ep_dequeue() waits until the request has
      been completed." And that:
      
          wait_for_completion(&done);
      
      Is needed right after the usb_ep_dequeue().
      
      Thus this patch implements that change. With it I no longer see
      the crashes on suspend or reboot.
      
      This issue seems to have been uncovered by behavioral changes in
      the dwc3 driver in commit fec9095b ("usb: dwc3: gadget:
      remove wait_end_transfer").
      
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Zeng Tao <prime.zeng@hisilicon.com>
      Cc: Jack Pham <jackp@codeaurora.org>
      Cc: Thinh Nguyen <thinh.nguyen@synopsys.com>
      Cc: Chen Yu <chenyu56@huawei.com>
      Cc: Jerry Zhang <zhangjerry@google.com>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Vincent Pelletier <plr.vincent@gmail.com>
      Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linux USB List <linux-usb@vger.kernel.org>
      Suggested-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ad02fb6a
    • Rakesh Pillai's avatar
      ath10k: fix shadow register implementation for WCN3990 · 126f2f6a
      Rakesh Pillai authored
      [ Upstream commit 18630083 ]
      
      WCN3990 supports shadow registers write operation support
      for copy engine for regular operation in powersave mode.
      
      Since WCN3990 is a 64-bit target, the shadow register
      implementation needs to be done in the copy engine handlers
      for 64-bit target. Currently the shadow register implementation
      is present in the 32-bit target handlers of copy engine.
      
      Fix the shadow register copy engine write operation
      implementation for 64-bit target(WCN3990).
      
      Tested HW: WCN3990
      Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
      
      Fixes: b7ba83f7 ("ath10k: add support for shadow register for WNC3990")
      Signed-off-by: default avatarRakesh Pillai <pillair@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      126f2f6a
    • Ranjani Sridharan's avatar
      ALSA: PCM: check if ops are defined before suspending PCM · ccce7643
      Ranjani Sridharan authored
      [ Upstream commit d9c0b2af ]
      
      BE dai links only have internal PCM's and their substream ops may
      not be set. Suspending these PCM's will result in their
       ops->trigger() being invoked and cause a kernel oops.
      So skip suspending PCM's if their ops are NULL.
      
      [ NOTE: this change is required now for following the recent PCM core
        change to get rid of snd_pcm_suspend() call.  Since DPCM BE takes
        the runtime carried from FE while keeping NULL ops, it can hit this
        bug.  See details at:
           https://github.com/thesofproject/linux/pull/582
        -- tiwai ]
      Signed-off-by: default avatarRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ccce7643
    • Martin Blumenstingl's avatar
      ARM: dts: meson8b: fix the Ethernet data line signals in eth_rgmii_pins · d21a63fc
      Martin Blumenstingl authored
      [ Upstream commit 29f0023d ]
      
      According to the Odroid-C1+ schematics the Ethernet TXD1 signal is
      routed to GPIOH_5 and the TXD0 signal is routed to GPIOH_6.
      The public S805 datasheet shows that TXD0 can be routed to DIF_2_P and
      TXD1 can be routed to DIF_2_N instead.
      
      The pin groups eth_txd0_0 (GPIOH_6) and eth_txd0_1 (DIF_2_P) are both
      configured as Ethernet TXD0 and TXD1 data lines in meson8b.dtsi. At the
      same time eth_txd1_0 (GPIOH_5) and eth_txd1_1 (DIF_2_N) are configured
      as TXD0 and TXD1 data lines as well.
      This results in a bad Ethernet receive performance. Presumably this is
      due to the eth_txd0 and eth_txd1 signal being routed to the wrong pins.
      As a result of that data can only be transmitted on eth_txd2 and
      eth_txd3. However, I have no scope to fully confirm this assumption.
      
      The vendor u-boot sources for Odroid-C1 use the following Ethernet
      pinmux configuration:
        SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_6, 0x3f4f);
        SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_7, 0xf00000);
      This translates to the following pin groups in the mainline kernel:
      - register 6 bit  0: eth_rxd1 (DIF_0_P)
      - register 6 bit  1: eth_rxd0 (DIF_0_N)
      - register 6 bit  2: eth_rx_dv (DIF_1_P)
      - register 6 bit  3: eth_rx_clk (DIF_1_N)
      - register 6 bit  6: eth_tx_en (DIF_3_P)
      - register 6 bit  8: eth_ref_clk (DIF_3_N)
      - register 6 bit  9: eth_mdc (DIF_4_P)
      - register 6 bit 10: eth_mdio_en (DIF_4_N)
      - register 6 bit 11: eth_tx_clk (GPIOH_9)
      - register 6 bit 12: eth_txd2 (GPIOH_8)
      - register 6 bit 13: eth_txd3 (GPIOH_7)
      - register 7 bit 20: eth_txd0_0 (GPIOH_6)
      - register 7 bit 21: eth_txd1_0 (GPIOH_5)
      - register 7 bit 22: eth_rxd3 (DIF_2_P)
      - register 7 bit 23: eth_rxd2 (DIF_2_N)
      
      Drop the eth_txd0_1 and eth_txd1_1 groups from eth_rgmii_pins to fix the
      Ethernet transmit performance on Odroid-C1. Also add the eth_rxd2 and
      eth_rxd3 groups so we don't rely on the bootloader to set them up.
      
      iperf3 statistics before this change:
      - transmitting from Odroid-C1: 741 Mbits/sec (0 retries)
      - receiving on Odroid-C1: 199 Mbits/sec (1713 retries)
      
      iperf3 statistics after this change:
      - transmitting from Odroid-C1: 667 Mbits/sec (0 retries)
      - receiving on Odroid-C1: 750 Mbits/sec (0 retries)
      
      Fixes: b9644654 ("ARM: dts: meson8b: extend ethernet controller description")
      Signed-off-by: default avatarMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Cc: Emiliano Ingrassia <ingrassia@epigenesys.com>
      Cc: Linus Lüssing <linus.luessing@c0d3.blue>
      Tested-by: default avatarEmiliano Ingrassia <ingrassia@epigenesys.com>
      Reviewed-by: default avatarEmiliano Ingrassia <ingrassia@epigenesys.com>
      Signed-off-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d21a63fc
    • Nathan Chancellor's avatar
      ARM: 8833/1: Ensure that NEON code always compiles with Clang · d93fe5e6
      Nathan Chancellor authored
      [ Upstream commit de9c0d49 ]
      
      While building arm32 allyesconfig, I ran into the following errors:
      
        arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
        '-mfloat-abi=softfp -mfpu=neon'
      
        In file included from lib/raid6/neon1.c:27:
        /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
        error: "NEON support not enabled"
      
      Building V=1 showed NEON_FLAGS getting passed along to Clang but
      __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
      only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
      which is the '-march' value for allyesconfig.
      
      >From lib/Basic/Targets/ARM.cpp in the Clang source:
      
        // This only gets set when Neon instructions are actually available, unlike
        // the VFP define, hence the soft float and arch check. This is subtly
        // different from gcc, we follow the intent which was that it should be set
        // when Neon instructions are actually available.
        if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
          Builder.defineMacro("__ARM_NEON", "1");
          Builder.defineMacro("__ARM_NEON__");
          // current AArch32 NEON implementations do not support double-precision
          // floating-point even when it is present in VFP.
          Builder.defineMacro("__ARM_NEON_FP",
                              "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
        }
      
      Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
      beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
      definined by Clang. This doesn't functionally change anything because
      that code will only run where NEON is supported, which is implicitly
      armv7.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/287Suggested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d93fe5e6
    • Chieh-Min Wang's avatar
      netfilter: conntrack: fix cloned unconfirmed skb->_nfct race in __nf_conntrack_confirm · 3a1ce979
      Chieh-Min Wang authored
      [ Upstream commit 13f5251f ]
      
      For bridge(br_flood) or broadcast/multicast packets, they could clone
      skb with unconfirmed conntrack which break the rule that unconfirmed
      skb->_nfct is never shared.  With nfqueue running on my system, the race
      can be easily reproduced with following warning calltrace:
      
      [13257.707525] CPU: 0 PID: 12132 Comm: main Tainted: P        W       4.4.60 #7744
      [13257.707568] Hardware name: Qualcomm (Flattened Device Tree)
      [13257.714700] [<c021f6dc>] (unwind_backtrace) from [<c021bce8>] (show_stack+0x10/0x14)
      [13257.720253] [<c021bce8>] (show_stack) from [<c0449e10>] (dump_stack+0x94/0xa8)
      [13257.728240] [<c0449e10>] (dump_stack) from [<c022a7e0>] (warn_slowpath_common+0x94/0xb0)
      [13257.735268] [<c022a7e0>] (warn_slowpath_common) from [<c022a898>] (warn_slowpath_null+0x1c/0x24)
      [13257.743519] [<c022a898>] (warn_slowpath_null) from [<c06ee450>] (__nf_conntrack_confirm+0xa8/0x618)
      [13257.752284] [<c06ee450>] (__nf_conntrack_confirm) from [<c0772670>] (ipv4_confirm+0xb8/0xfc)
      [13257.761049] [<c0772670>] (ipv4_confirm) from [<c06e7a60>] (nf_iterate+0x48/0xa8)
      [13257.769725] [<c06e7a60>] (nf_iterate) from [<c06e7af0>] (nf_hook_slow+0x30/0xb0)
      [13257.777108] [<c06e7af0>] (nf_hook_slow) from [<c07f20b4>] (br_nf_post_routing+0x274/0x31c)
      [13257.784486] [<c07f20b4>] (br_nf_post_routing) from [<c06e7a60>] (nf_iterate+0x48/0xa8)
      [13257.792556] [<c06e7a60>] (nf_iterate) from [<c06e7af0>] (nf_hook_slow+0x30/0xb0)
      [13257.800458] [<c06e7af0>] (nf_hook_slow) from [<c07e5580>] (br_forward_finish+0x94/0xa4)
      [13257.808010] [<c07e5580>] (br_forward_finish) from [<c07f22ac>] (br_nf_forward_finish+0x150/0x1ac)
      [13257.815736] [<c07f22ac>] (br_nf_forward_finish) from [<c06e8df0>] (nf_reinject+0x108/0x170)
      [13257.824762] [<c06e8df0>] (nf_reinject) from [<c06ea854>] (nfqnl_recv_verdict+0x3d8/0x420)
      [13257.832924] [<c06ea854>] (nfqnl_recv_verdict) from [<c06e940c>] (nfnetlink_rcv_msg+0x158/0x248)
      [13257.841256] [<c06e940c>] (nfnetlink_rcv_msg) from [<c06e5564>] (netlink_rcv_skb+0x54/0xb0)
      [13257.849762] [<c06e5564>] (netlink_rcv_skb) from [<c06e4ec8>] (netlink_unicast+0x148/0x23c)
      [13257.858093] [<c06e4ec8>] (netlink_unicast) from [<c06e5364>] (netlink_sendmsg+0x2ec/0x368)
      [13257.866348] [<c06e5364>] (netlink_sendmsg) from [<c069fb8c>] (sock_sendmsg+0x34/0x44)
      [13257.874590] [<c069fb8c>] (sock_sendmsg) from [<c06a03dc>] (___sys_sendmsg+0x1ec/0x200)
      [13257.882489] [<c06a03dc>] (___sys_sendmsg) from [<c06a11c8>] (__sys_sendmsg+0x3c/0x64)
      [13257.890300] [<c06a11c8>] (__sys_sendmsg) from [<c0209b40>] (ret_fast_syscall+0x0/0x34)
      
      The original code just triggered the warning but do nothing. It will
      caused the shared conntrack moves to the dying list and the packet be
      droppped (nf_ct_resolve_clash returns NF_DROP for dying conntrack).
      
      - Reproduce steps:
      
      +----------------------------+
      |          br0(bridge)       |
      |                            |
      +-+---------+---------+------+
        | eth0|   | eth1|   | eth2|
        |     |   |     |   |     |
        +--+--+   +--+--+   +---+-+
           |         |          |
           |         |          |
        +--+-+     +-+--+    +--+-+
        | PC1|     | PC2|    | PC3|
        +----+     +----+    +----+
      
      iptables -A FORWARD -m mark --mark 0x1000000/0x1000000 -j NFQUEUE --queue-num 100 --queue-bypass
      
      ps: Our nfq userspace program will set mark on packets whose connection
      has already been processed.
      
      PC1 sends broadcast packets simulated by hping3:
      
      hping3 --rand-source --udp 192.168.1.255 -i u100
      
      - Broadcast racing flow chart is as follow:
      
      br_handle_frame
        BR_HOOK(NFPROTO_BRIDGE, NF_BR_PRE_ROUTING, br_handle_frame_finish)
        // skb->_nfct (unconfirmed conntrack) is constructed at PRE_ROUTING stage
        br_handle_frame_finish
          // check if this packet is broadcast
          br_flood_forward
            br_flood
              list_for_each_entry_rcu(p, &br->port_list, list) // iterate through each port
                maybe_deliver
                  deliver_clone
                    skb = skb_clone(skb)
                    __br_forward
                      BR_HOOK(NFPROTO_BRIDGE, NF_BR_FORWARD,...)
                      // queue in our nfq and received by our userspace program
                      // goto __nf_conntrack_confirm with process context on CPU 1
          br_pass_frame_up
            BR_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN,...)
            // goto __nf_conntrack_confirm with softirq context on CPU 0
      
      Because conntrack confirm can happen at both INPUT and POSTROUTING
      stage.  So with NFQUEUE running, skb->_nfct with the same unconfirmed
      conntrack could race on different core.
      
      This patch fixes a repeating kernel splat, now it is only displayed
      once.
      Signed-off-by: default avatarChieh-Min Wang <chiehminw@synology.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3a1ce979
    • Masami Hiramatsu's avatar
      kprobes: Prohibit probing on RCU debug routine · d53b295f
      Masami Hiramatsu authored
      [ Upstream commit a39f15b9 ]
      
      Since kprobe itself depends on RCU, probing on RCU debug
      routine can cause recursive breakpoint bugs.
      
      Prohibit probing on RCU debug routines.
      
      int3
       ->do_int3()
         ->ist_enter()
           ->RCU_LOCKDEP_WARN()
             ->debug_lockdep_rcu_enabled() -> int3
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrea Righi <righi.andrea@gmail.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/154998807741.31052.11229157537816341591.stgit@devboxSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d53b295f
    • Andrea Righi's avatar
      kprobes: Prohibit probing on bsearch() · bc9d7143
      Andrea Righi authored
      [ Upstream commit 02106f88 ]
      
      Since kprobe breakpoing handler is using bsearch(), probing on this
      routine can cause recursive breakpoint problem.
      
      int3
       ->do_int3()
         ->ftrace_int3_handler()
           ->ftrace_location()
             ->ftrace_location_range()
               ->bsearch() -> int3
      
      Prohibit probing on bsearch().
      Signed-off-by: default avatarAndrea Righi <righi.andrea@gmail.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.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: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/154998813406.31052.8791425358974650922.stgit@devboxSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bc9d7143
    • Tycho Andersen's avatar
      selftests: skip seccomp get_metadata test if not real root · c63cc8d1
      Tycho Andersen authored
      [ Upstream commit 3aa415dd ]
      
      The get_metadata() test requires real root, so let's skip it if we're not
      real root.
      
      Note that I used XFAIL here because that's what the test does later if
      CONFIG_CHEKCKPOINT_RESTORE happens to not be enabled. After looking at the
      code, there doesn't seem to be a nice way to skip tests defined as TEST(),
      since there's no return code (I tried exit(KSFT_SKIP), but that didn't work
      either...). So let's do it this way to be consistent, and easier to fix
      when someone comes along and fixes it.
      Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarShuah Khan <shuah@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c63cc8d1
    • Hans de Goede's avatar
      ACPI / video: Refactor and fix dmi_is_desktop() · 2df541d0
      Hans de Goede authored
      [ Upstream commit cecf3e3e ]
      
      This commit refactors the chassis-type detection introduced by
      commit 53fa1f6e ("ACPI / video: Only default only_lcd to true on
      Win8-ready _desktops_") (where desktop means anything without a builtin
      screen).
      
      The DMI chassis_type is an unsigned integer, so rather then doing a
      whole bunch of string-compares on it, convert it to an int and feed
      the result to a switch case.
      
      Note the switch case uses hex values, this is done because the spec
      uses hex values too. This changes the check for "Main Server Chassis"
      from checking for 11 decimal to 11 hexadecimal, this is a bug fix,
      the original check for 11 decimal was wrong.
      
      Fixes: 53fa1f6e ("ACPI / video: Only default only_lcd to true ...")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      [ rjw: Drop redundant return statements ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2df541d0
    • Sara Sharon's avatar
      iwlwifi: pcie: fix emergency path · d6310584
      Sara Sharon authored
      [ Upstream commit c6ac9f9f ]
      
      Allocator swaps the pending requests with 0 when it starts
      working. This means that relying on it n RX path to decide if
      to move to emergency is not always a good idea, since it may
      be zero, but there are still a lot of unallocated RBs in the
      system. Change allocator to decrement the pending requests on
      real time. It is more expensive since it accesses the atomic
      variable more times, but it gives the RX path a better idea
      of the system's status.
      Reported-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarSara Sharon <sara.sharon@intel.com>
      Fixes: 868a1e86 ("iwlwifi: pcie: avoid empty free RB queue")
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d6310584
    • Thomas Richter's avatar
      perf report: Add s390 diagnosic sampling descriptor size · 5cdd0259
      Thomas Richter authored
      [ Upstream commit 2187d87e ]
      
      On IBM z13 machine types 2964 and 2965 the descriptor
      sizes for sampling and diagnostic sampling entries
      might be missing in the trailer entry and are set to zero.
      
      This leads to a perf report failure when processing diagnostic
      sampling entries.
      
      This patch adds missing descriptor sizes when the trailer entry
      contains zero for these fields.
      
      Output before:
        [root@s38lp82 perf]#  ./perf report --stdio | fgrep Samples
        0xabbf0 [0x8]: failed to process type: 68
        Error:
        failed to process sample
        [root@s38lp82 perf]#
      
      Output after:
        [root@s38lp82 perf]#  ./perf report --stdio | fgrep Samples
        # Total Lost Samples: 0
        # Samples: 3K of event 'SF_CYCLES_BASIC_DIAG'
        # Samples: 162  of event 'CF_DIAG'
        [root@s38lp82 perf]#
      
      Fixes: 2b1444f2 ("perf report: Add raw report support for s390 auxiliary trace")
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Link: http://lkml.kernel.org/r/20190211100627.85714-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5cdd0259
    • Michal Kazior's avatar
      leds: lp55xx: fix null deref on firmware load failure · 5658279f
      Michal Kazior authored
      [ Upstream commit 5ddb0869 ]
      
      I've stumbled upon a kernel crash and the logs
      pointed me towards the lp5562 driver:
      
      > <4>[306013.841294] lp5562 0-0030: Direct firmware load for lp5562 failed with error -2
      > <4>[306013.894990] lp5562 0-0030: Falling back to user helper
      > ...
      > <3>[306073.924886] lp5562 0-0030: firmware request failed
      > <1>[306073.939456] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      > <4>[306074.251011] PC is at _raw_spin_lock+0x1c/0x58
      > <4>[306074.255539] LR is at release_firmware+0x6c/0x138
      > ...
      
      After taking a look I noticed firmware_release()
      could be called with either NULL or a dangling
      pointer.
      
      Fixes: 10c06d17 ("leds-lp55xx: support firmware interface")
      Signed-off-by: default avatarMichal Kazior <michal@plume.com>
      Signed-off-by: default avatarJacek Anaszewski <jacek.anaszewski@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5658279f
    • Theodore Ts'o's avatar
      jbd2: fix race when writing superblock · 91544201
      Theodore Ts'o authored
      [ Upstream commit 538bcaa6 ]
      
      The jbd2 superblock is lockless now, so there is probably a race
      condition between writing it so disk and modifing contents of it, which
      may lead to checksum error. The following race is the one case that we
      have captured.
      
      jbd2                                fsstress
      jbd2_journal_commit_transaction
       jbd2_journal_update_sb_log_tail
        jbd2_write_superblock
         jbd2_superblock_csum_set         jbd2_journal_revoke
                                           jbd2_journal_set_features(revork)
                                           modify superblock
         submit_bh(checksum incorrect)
      
      Fix this by locking the buffer head before modifing it.  We always
      write the jbd2 superblock after we modify it, so this just means
      calling the lock_buffer() a little earlier.
      
      This checksum corruption problem can be reproduced by xfstests
      generic/475.
      Reported-by: default avatarzhangyi (F) <yi.zhang@huawei.com>
      Suggested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      91544201
    • Tejun Heo's avatar
      cgroup, rstat: Don't flush subtree root unless necessary · a74ebf04
      Tejun Heo authored
      [ Upstream commit b4ff1b44 ]
      
      cgroup_rstat_cpu_pop_updated() is used to traverse the updated cgroups
      on flush.  While it was only visiting updated ones in the subtree, it
      was visiting @root unconditionally.  We can easily check whether @root
      is updated or not by looking at its ->updated_next just as with the
      cgroups in the subtree.
      
      * Remove the unnecessary cgroup_parent() test.  The system root cgroup
        is never updated and thus its ->updated_next is always NULL.  No
        need to test whether cgroup_parent() exists in addition to
        ->updated_next.
      
      * Terminate traverse if ->updated_next is NULL.  This can only happen
        for subtree @root and there's no reason to visit it if it's not
        marked updated.
      
      This reduces cpu consumption when reading a lot of rstat backed files.
      In a micro benchmark reading stat from ~1600 cgroups, the sys time was
      lowered by >40%.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a74ebf04
    • Hong Liu's avatar
      HID: intel-ish-hid: avoid binding wrong ishtp_cl_device · b13eb524
      Hong Liu authored
      [ Upstream commit 0d28f494 ]
      
      When performing a warm reset in ishtp bus driver, the ishtp_cl_device
      will not be removed, its fw_client still points to the already freed
      ishtp_device.fw_clients array.
      
      Later after driver finishing ishtp client enumeration, this dangling
      pointer may cause driver to bind the wrong ishtp_cl_device to the new
      client, causing wrong callback to be called for messages intended for
      the new client.
      
      This helps in development of firmware where frequent switching of
      firmwares is required without Linux reboot.
      Signed-off-by: default avatarHong Liu <hong.liu@intel.com>
      Tested-by: default avatarHongyan Song <hongyan.song@intel.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b13eb524
    • Aurelien Jarno's avatar
      vfs: fix preadv64v2 and pwritev64v2 compat syscalls with offset == -1 · c26d61ea
      Aurelien Jarno authored
      [ Upstream commit cc4b1242 ]
      
      The preadv2 and pwritev2 syscalls are supposed to emulate the readv and
      writev syscalls when offset == -1. Therefore the compat code should
      check for offset before calling do_compat_preadv64 and
      do_compat_pwritev64. This is the case for the preadv2 and pwritev2
      syscalls, but handling of offset == -1 is missing in their 64-bit
      equivalent.
      
      This patch fixes that, calling do_compat_readv and do_compat_writev when
      offset == -1. This fixes the following glibc tests on x32:
       - misc/tst-preadvwritev2
       - misc/tst-preadvwritev64v2
      
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c26d61ea
    • Oleksandr Andrushchenko's avatar
      xen/gntdev: Do not destroy context while dma-bufs are in use · 7273c2b1
      Oleksandr Andrushchenko authored
      [ Upstream commit fa13e665 ]
      
      If there are exported DMA buffers which are still in use and
      grant device is closed by either normal user-space close or by
      a signal this leads to the grant device context to be destroyed,
      thus making it not possible to correctly destroy those exported
      buffers when they are returned back to gntdev and makes the module
      crash:
      
      [  339.617540] [<ffff00000854c0d8>] dmabuf_exp_ops_release+0x40/0xa8
      [  339.617560] [<ffff00000867a6e8>] dma_buf_release+0x60/0x190
      [  339.617577] [<ffff0000082211f0>] __fput+0x88/0x1d0
      [  339.617589] [<ffff000008221394>] ____fput+0xc/0x18
      [  339.617607] [<ffff0000080ed4e4>] task_work_run+0x9c/0xc0
      [  339.617622] [<ffff000008089714>] do_notify_resume+0xfc/0x108
      
      Fix this by referencing gntdev on each DMA buffer export and
      unreferencing on buffer release.
      Signed-off-by: default avatarOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
      Reviewed-by: Boris Ostrovsky@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7273c2b1
    • Lorenzo Bianconi's avatar
      mt76: usb: do not run mt76u_queues_deinit twice · e9cd7f54
      Lorenzo Bianconi authored
      [ Upstream commit b3098121 ]
      
      Do not call mt76u_queues_deinit routine in mt76u_alloc_queues error path
      since it will be run in mt76x0u_register_device or
      mt76x2u_register_device error path. Current implementation triggers the
      following kernel warning:
      
      [   67.005516] WARNING: CPU: 2 PID: 761 at lib/refcount.c:187 refcount_sub_and_test_checked+0xa4/0xb8
      [   67.019513] refcount_t: underflow; use-after-free.
      [   67.099872] Hardware name: BCM2835
      [   67.106268] Backtrace:
      [   67.111584] [<8010c91c>] (dump_backtrace) from [<8010cc00>] (show_stack+0x20/0x24)
      [   67.124974]  r6:60000013 r5:ffffffff r4:00000000 r3:a50bade6
      [   67.132226] [<8010cbe0>] (show_stack) from [<807ca5f4>] (dump_stack+0xc8/0x114)
      [   67.141225] [<807ca52c>] (dump_stack) from [<8011e65c>] (__warn+0xf4/0x120)
      [   67.149849]  r9:000000bb r8:804d0138 r7:00000009 r6:8099dc84 r5:00000000 r4:b66c7b58
      [   67.160767] [<8011e568>] (__warn) from [<8011e6d0>] (warn_slowpath_fmt+0x48/0x50)
      [   67.171436]  r9:7f65e128 r8:80d1419c r7:80c0bac4 r6:b97b3044 r5:b7368e00 r4:00000000
      [   67.182433] [<8011e68c>] (warn_slowpath_fmt) from [<804d0138>] (refcount_sub_and_test_checked+0xa4/0xb8)
      [   67.195221]  r3:80c91c25 r2:8099dc94
      [   67.200370]  r4:00000000
      [   67.204397] [<804d0094>] (refcount_sub_and_test_checked) from [<804d0164>] (refcount_dec_and_test_checked+0x18/0x1c)
      [   67.218046]  r4:b7368e00 r3:00000001
      [   67.223125] [<804d014c>] (refcount_dec_and_test_checked) from [<805db49c>] (usb_free_urb+0x20/0x4c)
      [   67.235358] [<805db47c>] (usb_free_urb) from [<7f639804>] (mt76u_buf_free+0x98/0xac [mt76_usb])
      [   67.247302]  r4:00000001 r3:00000001
      [   67.252468] [<7f63976c>] (mt76u_buf_free [mt76_usb]) from [<7f639ef8>] (mt76u_queues_deinit+0x44/0x100 [mt76_usb])
      [   67.266102]  r8:b8fe8600 r7:b5dac480 r6:b5dace20 r5:00000001 r4:00000000 r3:00000080
      [   67.277132] [<7f639eb4>] (mt76u_queues_deinit [mt76_usb]) from [<7f65c040>] (mt76x0u_cleanup+0x40/0x4c [mt76x0u])
      [   67.290737]  r7:b5dac480 r6:b8fe8600 r5:ffffffea r4:b5dace20
      [   67.298069] [<7f65c000>] (mt76x0u_cleanup [mt76x0u]) from [<7f65c564>] (mt76x0u_probe+0x1f0/0x354 [mt76x0u])
      [   67.311174]  r4:b5dace20 r3:00000000
      [   67.316312] [<7f65c374>] (mt76x0u_probe [mt76x0u]) from [<805e0b6c>] (usb_probe_interface+0x104/0x240)
      [   67.328915]  r7:00000000 r6:7f65e034 r5:b6634800 r4:b8fe8620
      [   67.336276] [<805e0a68>] (usb_probe_interface) from [<8056a8bc>] (really_probe+0x224/0x2f8)
      [   67.347965]  r10:b65f0a00 r9:00000019 r8:7f65e034 r7:80d3e124 r6:00000000 r5:80d3e120
      [   67.359175]  r4:b8fe8620 r3:805e0a68
      [   67.364384] [<8056a698>] (really_probe) from [<8056ab60>] (driver_probe_device+0x6c/0x180)
      [   67.375974]  r10:b65f0a00 r9:7f65e2c0 r8:b8fe8620 r7:00000000 r6:7f65e034 r5:7f65e034
      [   67.387170]  r4:b8fe8620 r3:00000000
      [   67.392378] [<8056aaf4>] (driver_probe_device) from [<8056ad54>] (__driver_attach+0xe0/0xe4)
      [   67.404097]  r9:7f65e2c0 r8:7f65d22c r7:00000000 r6:b8fe8654 r5:7f65e034 r4:b8fe8620
      [   67.415122] [<8056ac74>] (__driver_attach) from [<8056880c>] (bus_for_each_dev+0x68/0xa0)
      [   67.426628]  r6:8056ac74 r5:7f65e034 r4:00000000 r3:00000027
      [   67.434017] [<805687a4>] (bus_for_each_dev) from [<8056a1cc>] (driver_attach+0x28/0x30)
      [   67.445394]  r6:80c6ddc8 r5:b7368f80 r4:7f65e034
      [   67.451703] [<8056a1a4>] (driver_attach) from [<80569c24>] (bus_add_driver+0x194/0x21c)
      [   67.463081] [<80569a90>] (bus_add_driver) from [<8056b504>] (driver_register+0x8c/0x124)
      [   67.474560]  r7:80c6ddc8 r6:7f65e034 r5:00000000 r4:7f65e034
      [   67.481964] [<8056b478>] (driver_register) from [<805df510>] (usb_register_driver+0x74/0x140)
      [   67.493901]  r5:00000000 r4:7f65e000
      [   67.499131] [<805df49c>] (usb_register_driver) from [<7f661024>] (mt76x0_driver_init+0x24/0x1000 [mt76x0u])
      [   67.512258]  r9:00000001 r8:7f65e308 r7:00000000 r6:80c08d48 r5:7f661000 r4:7f65e2c0
      [   67.523404] [<7f661000>] (mt76x0_driver_init [mt76x0u]) from [<80102f6c>] (do_one_initcall+0x4c/0x210)
      [   67.536142] [<80102f20>] (do_one_initcall) from [<801ae63c>] (do_init_module+0x6c/0x21c)
      [   67.547639]  r8:7f65e308 r7:80c08d48 r6:b65f0ac0 r5:7f65e2c0 r4:7f65e2c0
      [   67.556129] [<801ae5d0>] (do_init_module) from [<801ad68c>] (load_module+0x1d10/0x2304)
      
      Fixes: b40b15e1 ("mt76: add usb support to mt76 layer")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e9cd7f54
    • Ezequiel Garcia's avatar
      media: mtk-jpeg: Correct return type for mem2mem buffer helpers · 5cde7721
      Ezequiel Garcia authored
      [ Upstream commit 1b275e4e ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: default avatarEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5cde7721
    • Ezequiel Garcia's avatar
      media: mx2_emmaprp: Correct return type for mem2mem buffer helpers · 745cdc34
      Ezequiel Garcia authored
      [ Upstream commit 8d20dcef ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: default avatarEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      745cdc34
    • Ezequiel Garcia's avatar
      media: s5p-g2d: Correct return type for mem2mem buffer helpers · 73a4cc59
      Ezequiel Garcia authored
      [ Upstream commit 30fa627b ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: default avatarEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      73a4cc59
    • Ezequiel Garcia's avatar
      media: rockchip/rga: Correct return type for mem2mem buffer helpers · 3c6cd079
      Ezequiel Garcia authored
      [ Upstream commit da2d3a4e ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: default avatarEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3c6cd079
    • Ezequiel Garcia's avatar
      media: s5p-jpeg: Correct return type for mem2mem buffer helpers · 55919fc2
      Ezequiel Garcia authored
      [ Upstream commit 4a88f898 ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: default avatarEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      55919fc2
    • Ezequiel Garcia's avatar
      media: sh_veu: Correct return type for mem2mem buffer helpers · a23fd268
      Ezequiel Garcia authored
      [ Upstream commit 43c14519 ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: default avatarEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a23fd268
    • Akinobu Mita's avatar
      media: ov7740: fix runtime pm initialization · 635fabdd
      Akinobu Mita authored
      [ Upstream commit 12aceee1 ]
      
      The runtime PM of this device is enabled after v4l2_ctrl_handler_setup(),
      and this makes this device's runtime PM usage count a negative value.
      
      The ov7740_set_ctrl() tries to do something only if the device's runtime
      PM usage counter is nonzero.
      
      ov7740_set_ctrl()
      {
      	if (!pm_runtime_get_if_in_use(&client->dev))
      		return 0;
      
      	<do something>;
      
      	pm_runtime_put(&client->dev);
      
      	return ret;
      }
      
      However, the ov7740_set_ctrl() is called by v4l2_ctrl_handler_setup()
      while the runtime PM of this device is not yet enabled.  In this case,
      the pm_runtime_get_if_in_use() returns -EINVAL (!= 0).
      
      Therefore we can't bail out of this function and the usage count is
      decreased by pm_runtime_put() without increment.
      
      This fixes this problem by enabling the runtime PM of this device before
      v4l2_ctrl_handler_setup() so that the ov7740_set_ctrl() is always called
      when the runtime PM is enabled.
      
      Cc: Wenyou Yang <wenyou.yang@microchip.com>
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Tested-by: default avatarEugen Hristev <eugen.hristev@microchip.com>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      635fabdd
    • Wen Yang's avatar
      SoC: imx-sgtl5000: add missing put_device() · 1d836ce7
      Wen Yang authored
      [ Upstream commit 8fa857da ]
      
      The of_find_device_by_node() takes a reference to the underlying device
      structure, we should release that reference.
      
      Detected by coccinelle with the following warnings:
      ./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
      call of_find_device_by_node on line 105, but without a corresponding
      object release within this function.
      ./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
      call of_find_device_by_node on line 105, but without a corresponding
      object release within this function.
      Signed-off-by: default avatarWen Yang <yellowriver2010@hotmail.com>
      Cc: Timur Tabi <timur@kernel.org>
      Cc: Nicolin Chen <nicoleotsuka@gmail.com>
      Cc: Xiubo Li <Xiubo.Lee@gmail.com>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
      Cc: NXP Linux Team <linux-imx@nxp.com>
      Cc: alsa-devel@alsa-project.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1d836ce7
    • He Kuang's avatar
      perf report: Don't shadow inlined symbol with different addr range · d41687c8
      He Kuang authored
      [ Upstream commit 7346195e ]
      
      We can't assume inlined symbols with the same name are equal, because
      their address range may be different. This will cause the symbols with
      different addresses be shadowed when adding to the hist entry, and lead
      to ERANGE error when checking the symbol address during sample parse,
      the addr should be within the range of [sym.start, sym.end].
      
      The error message is like: "0x36aea60f [0x8]: failed to process type: 68".
      
      The second parameter of symbol__new() is the length of the fake symbol
      for the inline frame, which is the subtraction of the end and start
      address of base_sym.
      Signed-off-by: default avatarHe Kuang <hekuang@huawei.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Milian Wolff <milian.wolff@kdab.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: aa441895 ("perf report: Compare symbol name for inlined frames when sorting")
      Link: http://lkml.kernel.org/r/20190219130531.15692-1-hekuang@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d41687c8
    • Brian Norris's avatar
      mwifiex: don't advertise IBSS features without FW support · 801b8d8c
      Brian Norris authored
      [ Upstream commit 6f21ab30 ]
      
      As it is, doing something like
      
        # iw phy phy0 interface add foobar type ibss
      
      on a firmware that doesn't have ad-hoc support just yields failures of
      HostCmd_CMD_SET_BSS_MODE, which happened to return a '-1' error code
      (-EPERM? not really right...) and sometimes may even crash the firmware
      along the way.
      
      Let's parse the firmware capability flag while registering the wiphy, so
      we don't allow attempting IBSS at all, and we get a proper -EOPNOTSUPP
      from nl80211 instead.
      
      Fixes: e267e71e ("mwifiex: Disable adhoc feature based on firmware capability")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      801b8d8c
    • Thomas Richter's avatar
      perf test: Fix failure of 'evsel-tp-sched' test on s390 · d323e59f
      Thomas Richter authored
      [ Upstream commit 03d30971 ]
      
      Commit 489338a7 ("perf tests evsel-tp-sched: Fix bitwise operator")
      causes test case 14 "Parse sched tracepoints fields" to fail on s390.
      
      This test succeeds on x86.
      
      In fact this test now fails on all architectures with type char treated
      as type unsigned char.
      
      The root cause is the signed-ness of character arrays in the tracepoints
      sched_switch for structure members prev_comm and next_comm.
      
      On s390 the output of:
      
       [root@m35lp76 perf]# cat /sys/kernel/debug/tracing/events/sched/sched_switch/format
       name: sched_switch
       ID: 287
       format:
         field:unsigned short common_type; offset:0; size:2;	signed:0;
         ...
         field:char prev_comm[16]; offset:8; size:16;	signed:0;
         ...
         field:char next_comm[16]; offset:40; size:16; signed:0;
      
      reveals the character arrays prev_comm and next_comm are per
      default unsigned char and have values in the range of 0..255.
      
      On x86 both fields are signed as this output shows:
       [root@f29]# cat /sys/kernel/debug/tracing/events/sched/sched_switch/format
       name: sched_switch
       ID: 287
       format:
         field:unsigned short common_type; offset:0; size:2;	signed:0;
         ...
         field:char prev_comm[16]; offset:8; size:16;	signed:1;
         ...
         field:char next_comm[16]; offset:40; size:16; signed:1;
      
      and the character arrays prev_comm and next_comm are per default signed
      char and have values in the range of -1..127.  The implementation of
      type char is architecture specific.
      
      Since the character arrays in both tracepoints sched_switch and
      sched_wakeup should contain ascii characters, simply omit the check for
      signedness in the test case.
      
      Output before:
      
        [root@m35lp76 perf]# ./perf test -F 14
        14: Parse sched tracepoints fields                        :
        --- start ---
        sched:sched_switch: "prev_comm" signedness(0) is wrong, should be 1
        sched:sched_switch: "next_comm" signedness(0) is wrong, should be 1
        sched:sched_wakeup: "comm" signedness(0) is wrong, should be 1
        ---- end ----
        14: Parse sched tracepoints fields                        : FAILED!
        [root@m35lp76 perf]#
      
      Output after:
      
        [root@m35lp76 perf]# ./perf test -Fv 14
        14: Parse sched tracepoints fields                        :
        --- start ---
        ---- end ----
        Parse sched tracepoints fields: Ok
        [root@m35lp76 perf]#
      
      Fixes: 489338a7 ("perf tests evsel-tp-sched: Fix bitwise operator")
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Link: http://lkml.kernel.org/r/20190219153639.31267-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d323e59f
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Clear stream->mode_changed after commit · 345c7757
      Nicholas Kazlauskas authored
      [ Upstream commit d8d2f174 ]
      
      [Why]
      The stream->mode_changed flag can persist in the following sequence
      of atomic commits:
      
      Commit 1:
      Enable CRTC0 (mode_changed = true), Enable CRTC1 (mode_changed = true)
      
      Commit 2:
      Disable CRTC1 (mode_changed = false)
      
      In this sequence we want to keep the exiting CRTC0 but it's not in the
      atomic state for the commit since it hasn't been modified. In this case
      the stream->mode_changed flag persists as true and we don't re-program
      the planes for the existing stream.
      
      [How]
      The flag needs to be cleared and it makes the most sense to do it within
      DC after the state has been committed. Nothing following dc_commit_state
      should think that the stream's mode has changed.
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarLeo Li <sunpeng.li@amd.com>
      Acked-by: default avatarTony Cheng <Tony.Cheng@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      345c7757
    • Sedat Dilek's avatar
      scsi: fcoe: make use of fip_mode enum complete · 1ef1b20f
      Sedat Dilek authored
      [ Upstream commit 8beb90aa ]
      
      commit 1917d42d ("fcoe: use enum for fip_mode") introduces a separate
      enum for the fip_mode that shall be used during initialisation handling
      until it is passed to fcoe_ctrl_link_up to set the initial fip_state.  That
      change was incomplete and gcc quietly converted in various places between
      the fip_mode and the fip_state enum values with implicit enum conversions,
      which fortunately cannot cause any issues in the actual code's execution.
      
      clang however warns about these implicit enum conversions in the scsi
      drivers. This commit consolidates the use of the two enums, guided by
      clang's enum-conversion warnings.
      
      This commit now completes the use of the fip_mode: It expects and uses
      fip_mode in {bnx2fc,fcoe}_interface_create and fcoe_ctlr_init, and it calls
      fcoe_ctrl_set_set() with the correct values in fcoe_ctlr_link_up().  It
      also breaks the association between FIP_MODE_AUTO and FIP_ST_AUTO to
      indicate these two enums are distinct.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/151
      Fixes: 1917d42d ("fcoe: use enum for fip_mode")
      Reported-by: default avatarDmitry Golovin <dima@golovin.in>
      Original-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      CC: Lukas Bulwahn <lukas.bulwahn@gmail.com>
      CC: Nick Desaulniers <ndesaulniers@google.com>
      CC: Nathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Tested-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Suggested-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1ef1b20f
    • Jason Yan's avatar
      scsi: megaraid_sas: return error when create DMA pool failed · 8032fc91
      Jason Yan authored
      [ Upstream commit bcf3b67d ]
      
      when create DMA pool for cmd frames failed, we should return -ENOMEM,
      instead of 0.
      In some case in:
      
          megasas_init_adapter_fusion()
      
          -->megasas_alloc_cmds()
             -->megasas_create_frame_pool
                create DMA pool failed,
              --> megasas_free_cmds() [1]
      
          -->megasas_alloc_cmds_fusion()
             failed, then goto fail_alloc_cmds.
          -->megasas_free_cmds() [2]
      
      we will call megasas_free_cmds twice, [1] will kfree cmd_list,
      [2] will use cmd_list.it will cause a problem:
      
      Unable to handle kernel NULL pointer dereference at virtual address
      00000000
      pgd = ffffffc000f70000
      [00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003,
      *pmd=0000001fbf894003, *pte=006000006d000707
      Internal error: Oops: 96000005 [#1] SMP
       Modules linked in:
       CPU: 18 PID: 1 Comm: swapper/0 Not tainted
       task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000
       PC is at megasas_free_cmds+0x30/0x70
       LR is at megasas_free_cmds+0x24/0x70
       ...
       Call trace:
       [<ffffffc0005b779c>] megasas_free_cmds+0x30/0x70
       [<ffffffc0005bca74>] megasas_init_adapter_fusion+0x2f4/0x4d8
       [<ffffffc0005b926c>] megasas_init_fw+0x2dc/0x760
       [<ffffffc0005b9ab0>] megasas_probe_one+0x3c0/0xcd8
       [<ffffffc0004a5abc>] local_pci_probe+0x4c/0xb4
       [<ffffffc0004a5c40>] pci_device_probe+0x11c/0x14c
       [<ffffffc00053a5e4>] driver_probe_device+0x1ec/0x430
       [<ffffffc00053a92c>] __driver_attach+0xa8/0xb0
       [<ffffffc000538178>] bus_for_each_dev+0x74/0xc8
        [<ffffffc000539e88>] driver_attach+0x28/0x34
       [<ffffffc000539a18>] bus_add_driver+0x16c/0x248
       [<ffffffc00053b234>] driver_register+0x6c/0x138
       [<ffffffc0004a5350>] __pci_register_driver+0x5c/0x6c
       [<ffffffc000ce3868>] megasas_init+0xc0/0x1a8
       [<ffffffc000082a58>] do_one_initcall+0xe8/0x1ec
       [<ffffffc000ca7be8>] kernel_init_freeable+0x1c8/0x284
       [<ffffffc0008d90b8>] kernel_init+0x1c/0xe4
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      Acked-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8032fc91