1. 30 Sep, 2019 1 commit
  2. 25 Sep, 2019 3 commits
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage() · cf395f7d
      Tony Lindgren authored
      This code is currently unable to find the dts opp tables as ti-cpufreq
      needs to set them up first based on speed binning.
      
      We stopped initializing the opp tables with platform code years ago for
      device tree based booting with commit 92d51856
      
       ("ARM: OMAP3+: do not
      register non-dt OPP tables for device tree boot"), and all of mach-omap2
      is now booting using device tree.
      
      We currently get the following errors on init:
      
      omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu
      omap2_set_init_voltage: unable to set vdd_mpu
      omap2_set_init_voltage: unable to find boot up OPP for vdd_core
      omap2_set_init_voltage: unable to set vdd_core
      omap2_set_init_voltage: unable to find boot up OPP for vdd_iva
      omap2_set_init_voltage: unable to set vdd_iva
      
      Let's just drop the unused code. Nowadays ti-cpufreq should be used to
      to initialize things properly.
      
      Cc: Adam Ford <aford173@gmail.com>
      Cc: André Roth <neolynx@gmail.com>
      Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
      Cc: Nishanth Menon <nm@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      cf395f7d
    • Tony Lindgren's avatar
      ARM: OMAP2+: Add missing LCDC midlemode for am335x · 17529d43
      Tony Lindgren authored
      TRM "Table 13-34. SYSCONFIG Register Field Descriptions" lists both
      standbymode and idlemode that should be just the sidle and midle
      registers where midle is currently unconfigured for lcdc_sysc. As
      the dts data has been generated based on lcdc_sysc, we now have an
      empty "ti,sysc-midle" property.
      
      And so we currently get a warning for lcdc because of a difference
      with dts provided configuration compared to the legacy platform
      data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
      the platform data without configuring the modes.
      
      Let's fix the issue by adding the missing midlemode to lcdc_sysc,
      and configuring the "ti,sysc-midle" property based on the TRM
      values.
      
      Fixes: f711c575
      
       ("ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data")
      Cc: Jyri Sarha <jsarha@ti.com>
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Robert Nelson <robertcnelson@gmail.com>
      Cc: Suman Anna <s-anna@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      17529d43
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix missing reset done flag for am3 and am43 · 8ad8041b
      Tony Lindgren authored
      
      
      For ti,sysc-omap4 compatible devices with no sysstatus register, we do have
      reset done status available in the SOFTRESET bit that clears when the reset
      is done. This is documented for example in am437x TRM for DMTIMER_TIOCP_CFG
      register. The am335x TRM just says that SOFTRESET bit value 1 means reset is
      ongoing, but it behaves the same way clearing after reset is done.
      
      With the ti-sysc driver handling this automatically based on no sysstatus
      register defined, we see warnings if SYSC_HAS_RESET_STATUS is missing in the
      legacy platform data:
      
      ti-sysc 48042000.target-module: sysc_flags 00000222 != 00000022
      ti-sysc 48044000.target-module: sysc_flags 00000222 != 00000022
      ti-sysc 48046000.target-module: sysc_flags 00000222 != 00000022
      ...
      
      Let's fix these warnings by adding SYSC_HAS_RESET_STATUS. Let's also
      remove the useless parentheses while at it.
      
      If it turns out we do have ti,sysc-omap4 compatible devices without a
      working SOFTRESET bit we can set up additional quirk handling for it.
      
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      8ad8041b
  3. 24 Sep, 2019 1 commit
  4. 23 Sep, 2019 6 commits
    • Tony Lindgren's avatar
      ARM: omap2plus_defconfig: Enable more droid4 devices as loadable modules · 1d70ded8
      Tony Lindgren authored
      
      
      Droid4 needs USB option serial driver for modem, and lm3532 for the
      LCD backlight.
      
      Note that the LCD backlight does not yet get enabled automatically,
      but needs to be done manually with:
      
      # echo 50 > /sys/class/leds/lm3532::backlight/brightness
      
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      1d70ded8
    • Adam Ford's avatar
      ARM: omap2plus_defconfig: Enable DRM_TI_TFP410 · 04e0e177
      Adam Ford authored
      The TFP410 driver was removed but the replacement driver was
      never enabled.  This patch enableds the DRM_TI_TFP410
      
      Fixes: be3143d8
      
       ("drm/omap: Remove TFP410 and DVI connector drivers")
      
      Signed-off-by: default avatarAdam Ford <aford173@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      04e0e177
    • Tony Lindgren's avatar
      c01f5120
    • H. Nikolaus Schaller's avatar
      DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again · f1f028ff
      H. Nikolaus Schaller authored
      commit 6953c57a
      
       "gpio: of: Handle SPI chipselect legacy bindings"
      
      did introduce logic to centrally handle the legacy spi-cs-high property
      in combination with cs-gpios. This assumes that the polarity
      of the CS has to be inverted if spi-cs-high is missing, even
      and especially if non-legacy GPIO_ACTIVE_HIGH is specified.
      
      The DTS for the GTA04 was orginally introduced under the assumption
      that there is no need for spi-cs-high if the gpio is defined with
      proper polarity GPIO_ACTIVE_HIGH.
      
      This was not a problem until gpiolib changed the interpretation of
      GPIO_ACTIVE_HIGH and missing spi-cs-high.
      
      The effect is that the missing spi-cs-high is now interpreted as CS being
      low (despite GPIO_ACTIVE_HIGH) which turns off the SPI interface when the
      panel is to be programmed by the panel driver.
      
      Therefore, we have to add the redundant and legacy spi-cs-high property
      to properly activate CS.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      f1f028ff
    • Tony Lindgren's avatar
      ARM: dts: Fix wrong clocks for dra7 mcasp · 2d3c8ba3
      Tony Lindgren authored
      The ahclkr clkctrl clock bit 28 only exists for mcasp 1 and 2 on dra7.
      This causes the following warning on beagle-x15:
      
      ti-sysc 48468000.target-module: could not add child clock ahclkr: -19
      
      Also the mcasp clkctrl clock bits are wrong:
      
      For mcasp1 and 2 we have four clocks at bits 28, 24, 22 and 0:
      
      bit 28 is ahclkr
      bit 24 is ahclkx
      bit 22 is auxclk
      bit 0 is fck
      
      For mcasp3 to 8 we have three clocks at bits 24, 22 and 0.
      
      bit 24 is ahclkx
      bit 22 is auxclk
      bit 0 is fck
      
      We do not have currently mapped auxclk at bit 22 for the drivers, that can
      be added if needed.
      
      Fixes: 5241ccbf
      
       ("ARM: dts: Add missing ranges for dra7 mcasp l3 ports")
      Cc: Suman Anna <s-anna@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      2d3c8ba3
    • Tony Lindgren's avatar
      clk: ti: dra7: Fix mcasp8 clock bits · dd8882a2
      Tony Lindgren authored
      There's a typo for dra7 mcasp clkctrl bit, it should be 22 like the other
      macasp instances, and not 24. And in dra7xx_clks[] we have the bits wrong
      way around.
      
      Fixes: dffa9051
      
       ("clk: ti: dra7: add new clkctrl data")
      Cc: linux-clk@vger.kernel.org
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Stephen Boyd <sboyd@kernel.org>
      Cc: Suman Anna <s-anna@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Acked-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      dd8882a2
  5. 15 Sep, 2019 2 commits
    • Linus Torvalds's avatar
      Linux 5.3 · 4d856f72
      Linus Torvalds authored
      4d856f72
    • Linus Torvalds's avatar
      Revert "ext4: make __ext4_get_inode_loc plug" · 72dbcf72
      Linus Torvalds authored
      This reverts commit b03755ad.
      
      This is sad, and done for all the wrong reasons.  Because that commit is
      good, and does exactly what it says: avoids a lot of small disk requests
      for the inode table read-ahead.
      
      However, it turns out that it causes an entirely unrelated problem: the
      getrandom() system call was introduced back in 2014 by commit
      c6e9d6f3
      
       ("random: introduce getrandom(2) system call"), and people
      use it as a convenient source of good random numbers.
      
      But part of the current semantics for getrandom() is that it waits for
      the entropy pool to fill at least partially (unlike /dev/urandom).  And
      at least ArchLinux apparently has a systemd that uses getrandom() at
      boot time, and the improvements in IO patterns means that existing
      installations suddenly start hanging, waiting for entropy that will
      never happen.
      
      It seems to be an unlucky combination of not _quite_ enough entropy,
      together with a particular systemd version and configuration.  Lennart
      says that the systemd-random-seed process (which is what does this early
      access) is supposed to not block any other boot activity, but sadly that
      doesn't actually seem to be the case (possibly due bogus dependencies on
      cryptsetup for encrypted swapspace).
      
      The correct fix is to fix getrandom() to not block when it's not
      appropriate, but that fix is going to take a lot more discussion.  Do we
      just make it act like /dev/urandom by default, and add a new flag for
      "wait for entropy"? Do we add a boot-time option? Or do we just limit
      the amount of time it will wait for entropy?
      
      So in the meantime, we do the revert to give us time to discuss the
      eventual fix for the fundamental problem, at which point we can re-apply
      the ext4 inode table access optimization.
      
      Reported-by: default avatarAhmed S. Darwish <darwish.07@gmail.com>
      Cc: Ted Ts'o <tytso@mit.edu>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Alexander E. Patrakov <patrakov@gmail.com>
      Cc: Lennart Poettering <mzxreary@0pointer.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      72dbcf72
  6. 14 Sep, 2019 12 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 1609d760
      Linus Torvalds authored
      Pull kvm fixes from Paolo Bonzini:
       "The main change here is a revert of reverts. We recently simplified
        some code that was thought unnecessary; however, since then KVM has
        grown quite a few cond_resched()s and for that reason the simplified
        code is prone to livelocks---one CPUs tries to empty a list of guest
        page tables while the others keep adding to them. This adds back the
        generation-based zapping of guest page tables, which was not
        unnecessary after all.
      
        On top of this, there is a fix for a kernel memory leak and a couple
        of s390 fixlets as well"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: x86/mmu: Reintroduce fast invalidate/zap for flushing memslot
        KVM: x86: work around leak of uninitialized stack contents
        KVM: nVMX: handle page fault in vmread
        KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl
        KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()
      1609d760
    • Linus Torvalds's avatar
      Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost · 1f9c632c
      Linus Torvalds authored
      Pull virtio fix from Michael Tsirkin:
       "A last minute revert
      
        The 32-bit build got broken by the latest defence in depth patch.
        Revert and we'll try again in the next cycle"
      
      * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
        Revert "vhost: block speculation of translated descriptors"
      1f9c632c
    • Linus Torvalds's avatar
      Merge tag 'riscv/for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux · b03c036e
      Linus Torvalds authored
      Pull RISC-V fix from Paul Walmsley:
       "Last week, Palmer and I learned that there was an error in the RISC-V
        kernel image header format that could make it less compatible with the
        ARM64 kernel image header format. I had missed this error during my
        original reviews of the patch.
      
        The kernel image header format is an interface that impacts
        bootloaders, QEMU, and other user tools. Those packages must be
        updated to align with whatever is merged in the kernel. We would like
        to avoid proliferating these image formats by keeping the RISC-V
        header as close as possible to the existing ARM64 header. Since the
        arch/riscv patch that adds support for the image header was merged
        with our v5.3-rc1 pull request as commit 0f327f2a ("RISC-V: Add
        an Image header that boot loader can parse."), we think it wise to try
        to fix this error before v5.3 is released.
      
        The fix itself should be backwards-compatible with any project that
        has already merged support for premature versions of this interface.
        It primarily involves ensuring that the RISC-V image header has
        something useful in the same field as the ARM64 image header"
      
      * tag 'riscv/for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
        riscv: modify the Image header to improve compatibility with the ARM64 header
      b03c036e
    • Michael S. Tsirkin's avatar
      Revert "vhost: block speculation of translated descriptors" · 0d4a3f2a
      Michael S. Tsirkin authored
      This reverts commit a89db445
      
      .
      
      I was hasty to include this patch, and it breaks the build on 32 bit.
      Defence in depth is good but let's do it properly.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      0d4a3f2a
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 36024fcf
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Don't corrupt xfrm_interface parms before validation, from Nicolas
          Dichtel.
      
       2) Revert use of usb-wakeup in btusb, from Mario Limonciello.
      
       3) Block ipv6 packets in bridge netfilter if ipv6 is disabled, from
          Leonardo Bras.
      
       4) IPS_OFFLOAD not honored in ctnetlink, from Pablo Neira Ayuso.
      
       5) Missing ULP check in sock_map, from John Fastabend.
      
       6) Fix receive statistic handling in forcedeth, from Zhu Yanjun.
      
       7) Fix length of SKB allocated in 6pack driver, from Christophe
          JAILLET.
      
       8) ip6_route_info_create() returns an error pointer, not NULL. From
          Maciej Żenczykowski.
      
       9) Only add RDS sock to the hashes after rs_transport is set, from
          Ka-Cheong Poon.
      
      10) Don't double clean TX descriptors in ixgbe, from Ilya Maximets.
      
      11) Presence of transmit IPSEC offload in an SKB is not tested for
          correctly in ixgbe and ixgbevf. From Steffen Klassert and Jeff
          Kirsher.
      
      12) Need rcu_barrier() when register_netdevice() takes one of the
          notifier based failure paths, from Subash Abhinov Kasiviswanathan.
      
      13) Fix leak in sctp_do_bind(), from Mao Wenan.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (72 commits)
        cdc_ether: fix rndis support for Mediatek based smartphones
        sctp: destroy bucket if failed to bind addr
        sctp: remove redundant assignment when call sctp_get_port_local
        sctp: change return type of sctp_get_port_local
        ixgbevf: Fix secpath usage for IPsec Tx offload
        sctp: Fix the link time qualifier of 'sctp_ctrlsock_exit()'
        ixgbe: Fix secpath usage for IPsec TX offload.
        net: qrtr: fix memort leak in qrtr_tun_write_iter
        net: Fix null de-reference of device refcount
        ipv6: Fix the link time qualifier of 'ping_v6_proc_exit_net()'
        tun: fix use-after-free when register netdev failed
        tcp: fix tcp_ecn_withdraw_cwr() to clear TCP_ECN_QUEUE_CWR
        ixgbe: fix double clean of Tx descriptors with xdp
        ixgbe: Prevent u8 wrapping of ITR value to something less than 10us
        mlx4: fix spelling mistake "veify" -> "verify"
        net: hns3: fix spelling mistake "undeflow" -> "underflow"
        net: lmc: fix spelling mistake "runnin" -> "running"
        NFC: st95hf: fix spelling mistake "receieve" -> "receive"
        net/rds: An rds_sock is added too early to the hash table
        mac80211: Do not send Layer 2 Update frame before authorization
        ...
      36024fcf
    • Linus Torvalds's avatar
      Merge tag 'mmc-v5.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · 1c4c5e25
      Linus Torvalds authored
      Pull MMC fixes from Ulf Hansson:
      
       - tmio: Fixup runtime PM management during probe and remove
      
       - sdhci-pci-o2micro: Fix eMMC initialization for an AMD SoC
      
       - bcm2835: Prevent lockups when terminating work
      
      * tag 'mmc-v5.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
        mmc: tmio: Fixup runtime PM management during remove
        mmc: tmio: Fixup runtime PM management during probe
        Revert "mmc: tmio: move runtime PM enablement to the driver implementations"
        Revert "mmc: sdhci: Remove unneeded quirk2 flag of O2 SD host controller"
        Revert "mmc: bcm2835: Terminate timeout work synchronously"
      1c4c5e25
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2019-09-13' of git://anongit.freedesktop.org/drm/drm · 592b8d87
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "From the maintainer summit, just some last minute fixes for final:
      
        lima:
         - fix gem_wait ioctl
      
        core:
         - constify modes list
      
        i915:
         - DP MST high color depth regression
         - GPU hangs on vulkan compute workloads"
      
      * tag 'drm-fixes-2019-09-13' of git://anongit.freedesktop.org/drm/drm:
        drm/lima: fix lima_gem_wait() return value
        drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+
        drm/i915: Limit MST to <= 8bpc once again
        drm/modes: Make the whitelist more const
      592b8d87
    • Paolo Bonzini's avatar
      Merge tag 'kvm-s390-master-5.3-1' of... · a9c20bb0
      Paolo Bonzini authored
      Merge tag 'kvm-s390-master-5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master
      
      KVM: s390: Fixes for 5.3
      
      - prevent a user triggerable oops in the migration code
      - do not leak kernel stack content
      a9c20bb0
    • Sean Christopherson's avatar
      KVM: x86/mmu: Reintroduce fast invalidate/zap for flushing memslot · 002c5f73
      Sean Christopherson authored
      James Harvey reported a livelock that was introduced by commit
      d012a06a ("Revert "KVM: x86/mmu: Zap only the relevant pages when
      removing a memslot"").
      
      The livelock occurs because kvm_mmu_zap_all() as it exists today will
      voluntarily reschedule and drop KVM's mmu_lock, which allows other vCPUs
      to add shadow pages.  With enough vCPUs, kvm_mmu_zap_all() can get stuck
      in an infinite loop as it can never zap all pages before observing lock
      contention or the need to reschedule.  The equivalent of kvm_mmu_zap_all()
      that was in use at the time of the reverted commit (4e103134, "KVM:
      x86/mmu: Zap only the relevant pages when removing a memslot") employed
      a fast invalidate mechanism and was not susceptible to the above livelock.
      
      There are three ways to fix the livelock:
      
      - Reverting the revert (commit d012a06a) is not a viable option as
        the revert is needed to fix a regression that occurs when the guest has
        one or more assigned devices.  It's unlikely we'll root cause the device
        assignment regression soon enough to fix the regression timely.
      
      - Remove the conditional reschedule from kvm_mmu_zap_all().  However, although
        removing the reschedule would be a smaller code change, it's less safe
        in the sense that the resulting kvm_mmu_zap_all() hasn't been used in
        the wild for flushing memslots since the fast invalidate mechanism was
        introduced by commit 6ca18b69 ("KVM: x86: use the fast way to
        invalidate all pages"), back in 2013.
      
      - Reintroduce the fast invalidate mechanism and use it when zapping shadow
        pages in response to a memslot being deleted/moved, which is what this
        patch does.
      
      For all intents and purposes, this is a revert of commit ea145aac
      ("Revert "KVM: MMU: fast invalidate all pages"") and a partial revert of
      commit 7390de1e ("Revert "KVM: x86: use the fast way to invalidate
      all pages""), i.e. restores the behavior of commit 5304b8d3 ("KVM:
      MMU: fast invalidate all pages") and commit 6ca18b69 ("KVM: x86:
      use the fast way to invalidate all pages") respectively.
      
      Fixes: d012a06a
      
       ("Revert "KVM: x86/mmu: Zap only the relevant pages when removing a memslot"")
      Reported-by: default avatarJames Harvey <jamespharvey20@gmail.com>
      Cc: Alex Willamson <alex.williamson@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      002c5f73
    • Fuqian Huang's avatar
      KVM: x86: work around leak of uninitialized stack contents · 541ab2ae
      Fuqian Huang authored
      
      
      Emulation of VMPTRST can incorrectly inject a page fault
      when passed an operand that points to an MMIO address.
      The page fault will use uninitialized kernel stack memory
      as the CR2 and error code.
      
      The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR
      exit to userspace; however, it is not an easy fix, so for now just ensure
      that the error code and CR2 are zero.
      
      Signed-off-by: default avatarFuqian Huang <huangfq.daxian@gmail.com>
      Cc: stable@vger.kernel.org
      [add comment]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      541ab2ae
    • Paolo Bonzini's avatar
      KVM: nVMX: handle page fault in vmread · f7eea636
      Paolo Bonzini authored
      
      
      The implementation of vmread to memory is still incomplete, as it
      lacks the ability to do vmread to I/O memory just like vmptrst.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f7eea636
    • Paul Walmsley's avatar
      riscv: modify the Image header to improve compatibility with the ARM64 header · 474efecb
      Paul Walmsley authored
      
      
      Part of the intention during the definition of the RISC-V kernel image
      header was to lay the groundwork for a future merge with the ARM64
      image header.  One error during my original review was not noticing
      that the RISC-V header's "magic" field was at a different size and
      position than the ARM64's "magic" field.  If the existing ARM64 Image
      header parsing code were to attempt to parse an existing RISC-V kernel
      image header format, it would see a magic number 0.  This is
      undesirable, since it's our intention to align as closely as possible
      with the ARM64 header format.  Another problem was that the original
      "res3" field was not being initialized correctly to zero.
      
      Address these issues by creating a 32-bit "magic2" field in the RISC-V
      header which matches the ARM64 "magic" field.  RISC-V binaries will
      store "RSC\x05" in this field.  The intention is that the use of the
      existing 64-bit "magic" field in the RISC-V header will be deprecated
      over time.  Increment the minor version number of the file format to
      indicate this change, and update the documentation accordingly.  Fix
      the assembler directives in head.S to ensure that reserved fields are
      properly zero-initialized.
      
      Signed-off-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      Reported-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      Reviewed-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      Cc: Atish Patra <atish.patra@wdc.com>
      Cc: Karsten Merker <merker@debian.org>
      Link: https://lore.kernel.org/linux-riscv/194c2f10c9806720623430dbf0cc59a965e50448.camel@wdc.com/T/#u
      Link: https://lore.kernel.org/linux-riscv/mhng-755b14c4-8f35-4079-a7ff-e421fd1b02bc@palmer-si-x1e/T/#t
      474efecb
  7. 13 Sep, 2019 11 commits
    • Bjørn Mork's avatar
      cdc_ether: fix rndis support for Mediatek based smartphones · 4d7ffcf3
      Bjørn Mork authored
      
      
      A Mediatek based smartphone owner reports problems with USB
      tethering in Linux.  The verbose USB listing shows a rndis_host
      interface pair (e0/01/03 + 10/00/00), but the driver fails to
      bind with
      
      [  355.960428] usb 1-4: bad CDC descriptors
      
      The problem is a failsafe test intended to filter out ACM serial
      functions using the same 02/02/ff class/subclass/protocol as RNDIS.
      The serial functions are recognized by their non-zero bmCapabilities.
      
      No RNDIS function with non-zero bmCapabilities were known at the time
      this failsafe was added. But it turns out that some Wireless class
      RNDIS functions are using the bmCapabilities field. These functions
      are uniquely identified as RNDIS by their class/subclass/protocol, so
      the failing test can safely be disabled.  The same applies to the two
      types of Misc class RNDIS functions.
      
      Applying the failsafe to Communication class functions only retains
      the original functionality, and fixes the problem for the Mediatek based
      smartphone.
      
      Tow examples of CDC functional descriptors with non-zero bmCapabilities
      from Wireless class RNDIS functions are:
      
      0e8d:000a  Mediatek Crosscall Spider X5 3G Phone
      
            CDC Header:
              bcdCDC               1.10
            CDC ACM:
              bmCapabilities       0x0f
                connection notifications
                sends break
                line coding and serial state
                get/set/clear comm features
            CDC Union:
              bMasterInterface        0
              bSlaveInterface         1
            CDC Call Management:
              bmCapabilities       0x03
                call management
                use DataInterface
              bDataInterface          1
      
      and
      
      19d2:1023  ZTE K4201-z
      
            CDC Header:
              bcdCDC               1.10
            CDC ACM:
              bmCapabilities       0x02
                line coding and serial state
            CDC Call Management:
              bmCapabilities       0x03
                call management
                use DataInterface
              bDataInterface          1
            CDC Union:
              bMasterInterface        0
              bSlaveInterface         1
      
      The Mediatek example is believed to apply to most smartphones with
      Mediatek firmware.  The ZTE example is most likely also part of a larger
      family of devices/firmwares.
      
      Suggested-by: default avatarLars Melin <larsm17@gmail.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4d7ffcf3
    • David S. Miller's avatar
      Merge branch 'sctp_do_bind-leak' · ae3b06ed
      David S. Miller authored
      
      
      Mao Wenan says:
      
      ====================
      fix memory leak for sctp_do_bind
      
      First two patches are to do cleanup, remove redundant assignment,
      and change return type of sctp_get_port_local.
      Third patch is to fix memory leak for sctp_do_bind if failed
      to bind address.
      
      v2: add one patch to change return type of sctp_get_port_local.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae3b06ed
    • Mao Wenan's avatar
      sctp: destroy bucket if failed to bind addr · 29b99f54
      Mao Wenan authored
      
      
      There is one memory leak bug report:
      BUG: memory leak
      unreferenced object 0xffff8881dc4c5ec0 (size 40):
        comm "syz-executor.0", pid 5673, jiffies 4298198457 (age 27.578s)
        hex dump (first 32 bytes):
          02 00 00 00 81 88 ff ff 00 00 00 00 00 00 00 00  ................
          f8 63 3d c1 81 88 ff ff 00 00 00 00 00 00 00 00  .c=.............
        backtrace:
          [<0000000072006339>] sctp_get_port_local+0x2a1/0xa00 [sctp]
          [<00000000c7b379ec>] sctp_do_bind+0x176/0x2c0 [sctp]
          [<000000005be274a2>] sctp_bind+0x5a/0x80 [sctp]
          [<00000000b66b4044>] inet6_bind+0x59/0xd0 [ipv6]
          [<00000000c68c7f42>] __sys_bind+0x120/0x1f0 net/socket.c:1647
          [<000000004513635b>] __do_sys_bind net/socket.c:1658 [inline]
          [<000000004513635b>] __se_sys_bind net/socket.c:1656 [inline]
          [<000000004513635b>] __x64_sys_bind+0x3e/0x50 net/socket.c:1656
          [<0000000061f2501e>] do_syscall_64+0x72/0x2e0 arch/x86/entry/common.c:296
          [<0000000003d1e05e>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      This is because in sctp_do_bind, if sctp_get_port_local is to
      create hash bucket successfully, and sctp_add_bind_addr failed
      to bind address, e.g return -ENOMEM, so memory leak found, it
      needs to destroy allocated bucket.
      
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarMao Wenan <maowenan@huawei.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29b99f54
    • Mao Wenan's avatar
      sctp: remove redundant assignment when call sctp_get_port_local · e0e4b8de
      Mao Wenan authored
      
      
      There are more parentheses in if clause when call sctp_get_port_local
      in sctp_do_bind, and redundant assignment to 'ret'. This patch is to
      do cleanup.
      
      Signed-off-by: default avatarMao Wenan <maowenan@huawei.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0e4b8de
    • Mao Wenan's avatar
      sctp: change return type of sctp_get_port_local · 8e2ef6ab
      Mao Wenan authored
      Currently sctp_get_port_local() returns a long
      which is either 0,1 or a pointer casted to long.
      It's neither of the callers use the return value since
      commit 62208f12
      
       ("net: sctp: simplify sctp_get_port").
      Now two callers are sctp_get_port and sctp_do_bind,
      they actually assumend a casted to an int was the same as
      a pointer casted to a long, and they don't save the return
      value just check whether it is zero or non-zero, so
      it would better change return type from long to int for
      sctp_get_port_local.
      
      Signed-off-by: default avatarMao Wenan <maowenan@huawei.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e2ef6ab
    • Jeff Kirsher's avatar
      ixgbevf: Fix secpath usage for IPsec Tx offload · 8f6617ba
      Jeff Kirsher authored
      Port the same fix for ixgbe to ixgbevf.
      
      The ixgbevf driver currently does IPsec Tx offloading
      based on an existing secpath. However, the secpath
      can also come from the Rx side, in this case it is
      misinterpreted for Tx offload and the packets are
      dropped with a "bad sa_idx" error. Fix this by using
      the xfrm_offload() function to test for Tx offload.
      
      CC: Shannon Nelson <snelson@pensando.io>
      Fixes: 7f68d430
      
       ("ixgbevf: enable VF IPsec offload operations")
      Reported-by: default avatarJonathan Tooker <jonathan@reliablehosting.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Acked-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f6617ba
    • Ulf Hansson's avatar
      mmc: tmio: Fixup runtime PM management during remove · 87b5d602
      Ulf Hansson authored
      
      
      Accessing the device when it may be runtime suspended is a bug, which is
      the case in tmio_mmc_host_remove(). Let's fix the behaviour.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      87b5d602
    • Ulf Hansson's avatar
      mmc: tmio: Fixup runtime PM management during probe · aa86f1a3
      Ulf Hansson authored
      
      
      The tmio_mmc_host_probe() calls pm_runtime_set_active() to update the
      runtime PM status of the device, as to make it reflect the current status
      of the HW. This works fine for most cases, but unfortunate not for all.
      Especially, there is a generic problem when the device has a genpd attached
      and that genpd have the ->start|stop() callbacks assigned.
      
      More precisely, if the driver calls pm_runtime_set_active() during
      ->probe(), genpd does not get to invoke the ->start() callback for it,
      which means the HW isn't really fully powered on. Furthermore, in the next
      phase, when the device becomes runtime suspended, genpd will invoke the
      ->stop() callback for it, potentially leading to usage count imbalance
      problems, depending on what's implemented behind the callbacks of course.
      
      To fix this problem, convert to call pm_runtime_get_sync() from
      tmio_mmc_host_probe() rather than pm_runtime_set_active(). Additionally, to
      avoid bumping usage counters and unnecessary re-initializing the HW the
      first time the tmio driver's ->runtime_resume() callback is called,
      introduce a state flag to keeping track of this.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      aa86f1a3
    • Ulf Hansson's avatar
      Revert "mmc: tmio: move runtime PM enablement to the driver implementations" · 8861474a
      Ulf Hansson authored
      This reverts commit 7ff21319.
      
      It turns out that the above commit introduces other problems. For example,
      calling pm_runtime_set_active() must not be done prior calling
      pm_runtime_enable() as that makes it fail. This leads to additional
      problems, such as clock enables being wrongly balanced.
      
      Rather than fixing the problem on top, let's start over by doing a revert.
      
      Fixes: 7ff21319
      
       ("mmc: tmio: move runtime PM enablement to the driver implementations")
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      8861474a
    • Linus Torvalds's avatar
      Merge branch 'for-5.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup · a7f89616
      Linus Torvalds authored
      Pull cgroup fix from Tejun Heo:
       "Roman found and fixed a bug in the cgroup2 freezer which allows new
        child cgroup to escape frozen state"
      
      * 'for-5.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
        cgroup: freezer: fix frozen state inheritance
        kselftests: cgroup: add freezer mkdir test
      a7f89616
    • Linus Torvalds's avatar
      Merge tag 'for-5.3-rc8-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux · 1b304a1a
      Linus Torvalds authored
      Pull btrfs fixes from David Sterba:
       "Here are two fixes, one of them urgent fixing a bug introduced in 5.2
        and reported by many users. It took time to identify the root cause,
        catching the 5.3 release is higly desired also to push the fix to 5.2
        stable tree.
      
        The bug is a mess up of return values after adding proper error
        handling and honestly the kind of bug that can cause sleeping
        disorders until it's caught. My appologies to everybody who was
        affected.
      
        Summary of what could happen:
      
        1) either a hang when committing a transaction, if this happens
           there's no risk of corruption, still the hang is very inconvenient
           and can't be resolved without a reboot
      
        2) writeback for some btree nodes may never be started and we end up
           committing a transaction without noticing that, this is really
           serious and that will lead to the "parent transid verify failed"
           messages"
      
      * tag 'for-5.3-rc8-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
        Btrfs: fix unwritten extent buffers and hangs on future writeback attempts
        Btrfs: fix assertion failure during fsync and use of stale transaction
      1b304a1a
  8. 12 Sep, 2019 4 commits
    • Roman Gushchin's avatar
      cgroup: freezer: fix frozen state inheritance · 97a61369
      Roman Gushchin authored
      
      
      If a new child cgroup is created in the frozen cgroup hierarchy
      (one or more of ancestor cgroups is frozen), the CGRP_FREEZE cgroup
      flag should be set. Otherwise if a process will be attached to the
      child cgroup, it won't become frozen.
      
      The problem can be reproduced with the test_cgfreezer_mkdir test.
      
      This is the output before this patch:
        ~/test_freezer
        ok 1 test_cgfreezer_simple
        ok 2 test_cgfreezer_tree
        ok 3 test_cgfreezer_forkbomb
        Cgroup /sys/fs/cgroup/cg_test_mkdir_A/cg_test_mkdir_B isn't frozen
        not ok 4 test_cgfreezer_mkdir
        ok 5 test_cgfreezer_rmdir
        ok 6 test_cgfreezer_migrate
        ok 7 test_cgfreezer_ptrace
        ok 8 test_cgfreezer_stopped
        ok 9 test_cgfreezer_ptraced
        ok 10 test_cgfreezer_vfork
      
      And with this patch:
        ~/test_freezer
        ok 1 test_cgfreezer_simple
        ok 2 test_cgfreezer_tree
        ok 3 test_cgfreezer_forkbomb
        ok 4 test_cgfreezer_mkdir
        ok 5 test_cgfreezer_rmdir
        ok 6 test_cgfreezer_migrate
        ok 7 test_cgfreezer_ptrace
        ok 8 test_cgfreezer_stopped
        ok 9 test_cgfreezer_ptraced
        ok 10 test_cgfreezer_vfork
      
      Reported-by: default avatarMark Crossen <mcrossen@fb.com>
      Signed-off-by: default avatarRoman Gushchin <guro@fb.com>
      Fixes: 76f969e8
      
       ("cgroup: cgroup v2 freezer")
      Cc: Tejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org # v5.2+
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      97a61369
    • Roman Gushchin's avatar
      kselftests: cgroup: add freezer mkdir test · 44e9d308
      Roman Gushchin authored
      
      
      Add a new cgroup freezer selftest, which checks that if a cgroup is
      frozen, their new child cgroups will properly inherit the frozen
      state.
      
      It creates a parent cgroup, freezes it, creates a child cgroup
      and populates it with a dummy process. Then it checks that both
      parent and child cgroup are frozen.
      
      Signed-off-by: default avatarRoman Gushchin <guro@fb.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Shuah Khan <shuah@kernel.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      44e9d308
    • Chris Wilson's avatar
      Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()" · 505a8ec7
      Chris Wilson authored
      
      
      The userptr put_pages can be called from inside try_to_unmap, and so
      enters with the page lock held on one of the object's backing pages. We
      cannot take the page lock ourselves for fear of recursion.
      
      Reported-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Reported-by: default avatarMartin Wilck <Martin.Wilck@suse.com>
      Reported-by: default avatarLeo Kraav <leho@kraav.com>
      Fixes: aa56a292 ("drm/i915/userptr: Acquire the page lock around set_page_dirty()")
      References: https://bugzilla.kernel.org/show_bug.cgi?id=203317
      
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      505a8ec7
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20190912' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux · 98dcb386
      Linus Torvalds authored
      Pull clone3 fix from Christian Brauner:
       "This is a last-minute bugfix for clone3() that should go in before we
        release 5.3 with clone3().
      
        clone3() did not verify that the exit_signal argument was set to a
        valid signal. This can be used to cause a crash by specifying a signal
        greater than NSIG. e.g. -1.
      
        The commit from Eugene adds a check to copy_clone_args_from_user() to
        verify that the exit signal is limited by CSIGNAL as with legacy
        clone() and that the signal is valid. With this we don't get the
        legacy clone behavior were an invalid signal could be handed down and
        would only be detected and then ignored in do_notify_parent(). Users
        of clone3() will now get a proper error right when they pass an
        invalid exit signal. Note, that this is not a change in user-visible
        behavior since no kernel with clone3() has been released yet"
      
      * tag 'for-linus-20190912' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux:
        fork: block invalid exit signals with clone3()
      98dcb386