1. 17 Apr, 2020 8 commits
    • Thomas Gleixner's avatar
      Merge tag 'irqchip-fixes-5.7-2' of... · b5963029
      Thomas Gleixner authored
      Merge tag 'irqchip-fixes-5.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent
      
      Pull irqchip fixes from Marc Zyngier:
      
       - Fix the mbigen driver to properly free its MSI descriptors on teardown
       - Fix the TI INTA driver to avoid handling spurious interrupts from masked interrupts
       - Fix the SiFive PLIC driver to use the correct interrupt priority mask
       - Fix the Amlogic Meson gpio driver creative locking
       - Fix the GICv4.1 virtual SGI set_affinity callback to update the effective affinity
       - Allow the GICv4.x driver to synchronize with the HW pending table parsing
       - Fix a couple of missing static attributes
      b5963029
    • Marc Zyngier's avatar
    • Jason Yan's avatar
      irqchip/irq-bcm7038-l1: Make bcm7038_l1_of_init() static · 8f374923
      Jason Yan authored
      Fix the following sparse warning:
      
      drivers/irqchip/irq-bcm7038-l1.c:419:12: warning: symbol
      'bcm7038_l1_of_init' was not declared. Should it be static?
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Link: https://lore.kernel.org/r/20200417074036.46594-1-yanaijie@huawei.com
      8f374923
    • Jason Yan's avatar
      irqchip/irq-mvebu-icu: Make legacy_bindings static · 9fed9ccb
      Jason Yan authored
      Fix the following sparse warning:
      
      drivers/irqchip/irq-mvebu-icu.c:69:1: warning: symbol 'legacy_bindings'
      was not declared. Should it be static?
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Link: https://lore.kernel.org/r/20200417074046.46771-1-yanaijie@huawei.com
      9fed9ccb
    • Marc Zyngier's avatar
      irqchip/meson-gpio: Fix HARDIRQ-safe -> HARDIRQ-unsafe lock order · 0a66d6f9
      Marc Zyngier authored
      Running a lockedp-enabled kernel on a vim3l board (Amlogic SM1)
      leads to the following splat:
      
      [   13.557138] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
      [   13.587485] ip/456 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      [   13.625922] ffff000059908cf0 (&irq_desc_lock_class){-.-.}-{2:2}, at: __setup_irq+0xf8/0x8d8
      [   13.632273] which would create a new lock dependency:
      [   13.637272]  (&irq_desc_lock_class){-.-.}-{2:2} -> (&ctl->lock){+.+.}-{2:2}
      [   13.644209]
      [   13.644209] but this new dependency connects a HARDIRQ-irq-safe lock:
      [   13.654122]  (&irq_desc_lock_class){-.-.}-{2:2}
      [   13.654125]
      [   13.654125] ... which became HARDIRQ-irq-safe at:
      [   13.664759]   lock_acquire+0xec/0x368
      [   13.666926]   _raw_spin_lock+0x60/0x88
      [   13.669979]   handle_fasteoi_irq+0x30/0x178
      [   13.674082]   generic_handle_irq+0x38/0x50
      [   13.678098]   __handle_domain_irq+0x6c/0xc8
      [   13.682209]   gic_handle_irq+0x5c/0xb0
      [   13.685872]   el1_irq+0xd0/0x180
      [   13.689010]   arch_cpu_idle+0x40/0x220
      [   13.692732]   default_idle_call+0x54/0x60
      [   13.696677]   do_idle+0x23c/0x2e8
      [   13.699903]   cpu_startup_entry+0x30/0x50
      [   13.703852]   rest_init+0x1e0/0x2b4
      [   13.707301]   arch_call_rest_init+0x18/0x24
      [   13.711449]   start_kernel+0x4ec/0x51c
      [   13.715167]
      [   13.715167] to a HARDIRQ-irq-unsafe lock:
      [   13.722426]  (&ctl->lock){+.+.}-{2:2}
      [   13.722430]
      [   13.722430] ... which became HARDIRQ-irq-unsafe at:
      [   13.732319] ...
      [   13.732324]   lock_acquire+0xec/0x368
      [   13.735985]   _raw_spin_lock+0x60/0x88
      [   13.739452]   meson_gpio_irq_domain_alloc+0xcc/0x290
      [   13.744392]   irq_domain_alloc_irqs_hierarchy+0x24/0x60
      [   13.749586]   __irq_domain_alloc_irqs+0x160/0x2f0
      [   13.754254]   irq_create_fwspec_mapping+0x118/0x320
      [   13.759073]   irq_create_of_mapping+0x78/0xa0
      [   13.763360]   of_irq_get+0x6c/0x80
      [   13.766701]   of_mdiobus_register_phy+0x10c/0x238 [of_mdio]
      [   13.772227]   of_mdiobus_register+0x158/0x380 [of_mdio]
      [   13.777388]   mdio_mux_init+0x180/0x2e8 [mdio_mux]
      [   13.782128]   g12a_mdio_mux_probe+0x290/0x398 [mdio_mux_meson_g12a]
      [   13.788349]   platform_drv_probe+0x5c/0xb0
      [   13.792379]   really_probe+0xe4/0x448
      [   13.795979]   driver_probe_device+0xe8/0x140
      [   13.800189]   __device_attach_driver+0x94/0x120
      [   13.804639]   bus_for_each_drv+0x84/0xd8
      [   13.808474]   __device_attach+0xe4/0x168
      [   13.812361]   device_initial_probe+0x1c/0x28
      [   13.816592]   bus_probe_device+0xa4/0xb0
      [   13.820430]   deferred_probe_work_func+0xa8/0x100
      [   13.825064]   process_one_work+0x264/0x688
      [   13.829088]   worker_thread+0x4c/0x458
      [   13.832768]   kthread+0x154/0x158
      [   13.836018]   ret_from_fork+0x10/0x18
      [   13.839612]
      [   13.839612] other info that might help us debug this:
      [   13.839612]
      [   13.850354]  Possible interrupt unsafe locking scenario:
      [   13.850354]
      [   13.855720]        CPU0                    CPU1
      [   13.858774]        ----                    ----
      [   13.863242]   lock(&ctl->lock);
      [   13.866330]                                local_irq_disable();
      [   13.872233]                                lock(&irq_desc_lock_class);
      [   13.878705]                                lock(&ctl->lock);
      [   13.884297]   <Interrupt>
      [   13.886857]     lock(&irq_desc_lock_class);
      [   13.891014]
      [   13.891014]  *** DEADLOCK ***
      
      The issue can occur when CPU1 is doing something like irq_set_type()
      and CPU0 performing an interrupt allocation, for example. Taking
      an interrupt (like the one being reconfigured) would lead to a deadlock.
      
      A solution to this is:
      
      - Reorder the locking so that meson_gpio_irq_update_bits takes the lock
        itself at all times, instead of relying on the caller to lock or not,
        hence making the RMW sequence atomic,
      
      - Rework the critical section in meson_gpio_irq_request_channel to only
        cover the allocation itself, and let the gpio_irq_sel_pin callback
        deal with its own locking if required,
      
      - Take the private spin-lock with interrupts disabled at all times
      Reviewed-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      0a66d6f9
    • Atish Patra's avatar
      irqchip/sifive-plic: Fix maximum priority threshold value · d727be7b
      Atish Patra authored
      As per the PLIC specification, maximum priority threshold value is 0x7
      not 0xF. Even though it doesn't cause any error in qemu/hifive unleashed,
      there may be some implementation which checks the upper bound resulting in
      an illegal access.
      
      Fixes: ccbe80ba ("irqchip/sifive-plic: Enable/Disable external interrupts upon cpu online/offline")
      Signed-off-by: default avatarAtish Patra <atish.patra@wdc.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Link: https://lore.kernel.org/r/20200403014609.71831-1-atish.patra@wdc.com
      d727be7b
    • Grygorii Strashko's avatar
      irqchip/ti-sci-inta: Fix processing of masked irqs · 3688b0db
      Grygorii Strashko authored
      The ti_sci_inta_irq_handler() does not take into account INTA IRQs state
      (masked/unmasked) as it uses INTA_STATUS_CLEAR_j register to get INTA IRQs
      status, which provides raw status value.
      This causes hard IRQ handlers to be called or threaded handlers to be
      scheduled many times even if corresponding INTA IRQ is masked.
      Above, first of all, affects the LEVEL interrupts processing and causes
      unexpected behavior up the system stack or crash.
      
      Fix it by using the Interrupt Masked Status INTA_STATUSM_j register which
      provides masked INTA IRQs status.
      
      Fixes: 9f1463b8 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver")
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Reviewed-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Link: https://lore.kernel.org/r/20200408191532.31252-1-grygorii.strashko@ti.com
      Cc: stable@vger.kernel.org
      3688b0db
    • Zenghui Yu's avatar
      irqchip/mbigen: Free msi_desc on device teardown · edfc23f6
      Zenghui Yu authored
      Using irq_domain_free_irqs_common() on the irqdomain free path will
      leave the MSI descriptor unfreed when platform devices get removed.
      Properly free it by MSI domain free function.
      
      Fixes: 9650c60e ("irqchip/mbigen: Create irq domain for each mbigen device")
      Signed-off-by: default avatarZenghui Yu <yuzenghui@huawei.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Link: https://lore.kernel.org/r/20200408114352.1604-1-yuzenghui@huawei.com
      edfc23f6
  2. 16 Apr, 2020 2 commits
    • Marc Zyngier's avatar
      irqchip/gic-v4.1: Update effective affinity of virtual SGIs · 4b2dfe1e
      Marc Zyngier authored
      Although the vSGIs are not directly visible to the host, they still
      get moved around by the CPU hotplug, for example. This results in
      the kernel moaning on the console, such as:
      
        genirq: irq_chip GICv4.1-sgi did not update eff. affinity mask of irq 38
      
      Updating the effective affinity on set_affinity() fixes it.
      Reviewed-by: default avatarZenghui Yu <yuzenghui@huawei.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      4b2dfe1e
    • Marc Zyngier's avatar
      irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling · 96806229
      Marc Zyngier authored
      When a vPE is made resident, the GIC starts parsing the virtual pending
      table to deliver pending interrupts. This takes place asynchronously,
      and can at times take a long while. Long enough that the vcpu enters
      the guest and hits WFI before any interrupt has been signaled yet.
      The vcpu then exits, blocks, and now gets a doorbell. Rince, repeat.
      
      In order to avoid the above, a (optional on GICv4, mandatory on v4.1)
      feature allows the GIC to feedback to the hypervisor whether it is
      done parsing the VPT by clearing the GICR_VPENDBASER.Dirty bit.
      The hypervisor can then wait until the GIC is ready before actually
      running the vPE.
      
      Plug the detection code as well as polling on vPE schedule. While
      at it, tidy-up the kernel message that displays the GICv4 optional
      features.
      Reviewed-by: default avatarZenghui Yu <yuzenghui@huawei.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      96806229
  3. 14 Apr, 2020 1 commit
  4. 12 Apr, 2020 10 commits
    • Linus Torvalds's avatar
      Linux 5.7-rc1 · 8f3d9f35
      Linus Torvalds authored
      8f3d9f35
    • Linus Torvalds's avatar
      MAINTAINERS: sort field names for all entries · 3b50142d
      Linus Torvalds authored
      This sorts the actual field names too, potentially causing even more
      chaos and confusion at merge time if you have edited the MAINTAINERS
      file.  But the end result is a more consistent layout, and hopefully
      it's a one-time pain minimized by doing this just before the -rc1
      release.
      
      This was entirely scripted:
      
        ./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS --order
      Requested-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3b50142d
    • Linus Torvalds's avatar
      MAINTAINERS: sort entries by entry name · 4400b7d6
      Linus Torvalds authored
      They are all supposed to be sorted, but people who add new entries don't
      always know the alphabet.  Plus sometimes the entry names get edited,
      and people don't then re-order the entry.
      
      Let's see how painful this will be for merging purposes (the MAINTAINERS
      file is often edited in various different trees), but Joe claims there's
      relatively few patches in -next that touch this, and doing it just
      before -rc1 is likely the best time.  Fingers crossed.
      
      This was scripted with
      
        /scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS
      
      but then I also ended up manually upper-casing a few entry names that
      stood out when looking at the end result.
      Requested-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4400b7d6
    • Linus Torvalds's avatar
      Merge tag 'x86-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 4f8a3cc1
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
       "A set of three patches to fix the fallout of the newly added split
        lock detection feature.
      
        It addressed the case where a KVM guest triggers a split lock #AC and
        KVM reinjects it into the guest which is not prepared to handle it.
      
        Add proper sanity checks which prevent the unconditional injection
        into the guest and handles the #AC on the host side in the same way as
        user space detections are handled. Depending on the detection mode it
        either warns and disables detection for the task or kills the task if
        the mode is set to fatal"
      
      * tag 'x86-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        KVM: VMX: Extend VMXs #AC interceptor to handle split lock #AC in guest
        KVM: x86: Emulate split-lock access as a write in emulator
        x86/split_lock: Provide handle_guest_split_lock()
      4f8a3cc1
    • Linus Torvalds's avatar
      Merge tag 'timers-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 0785249f
      Linus Torvalds authored
      Pull time(keeping) updates from Thomas Gleixner:
      
       - Fix the time_for_children symlink in /proc/$PID/ so it properly
         reflects that it part of the 'time' namespace
      
       - Add the missing userns limit for the allowed number of time
         namespaces, which was half defined but the actual array member was
         not added. This went unnoticed as the array has an exessive empty
         member at the end but introduced a user visible regression as the
         output was corrupted.
      
       - Prevent further silent ucount corruption by adding a BUILD_BUG_ON()
         to catch half updated data.
      
      * tag 'timers-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        ucount: Make sure ucounts in /proc/sys/user don't regress again
        time/namespace: Add max_time_namespaces ucount
        time/namespace: Fix time_for_children symlink
      0785249f
    • Linus Torvalds's avatar
      Merge tag 'sched-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 590680d1
      Linus Torvalds authored
      Pull scheduler fixes/updates from Thomas Gleixner:
      
       - Deduplicate the average computations in the scheduler core and the
         fair class code.
      
       - Fix a raise between runtime distribution and assignement which can
         cause exceeding the quota by up to 70%.
      
       - Prevent negative results in the imbalanace calculation
      
       - Remove a stale warning in the workqueue code which can be triggered
         since the call site was moved out of preempt disabled code. It's a
         false positive.
      
       - Deduplicate the print macros for procfs
      
       - Add the ucmap values to the SCHED_DEBUG procfs output for completness
      
      * tag 'sched-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/debug: Add task uclamp values to SCHED_DEBUG procfs
        sched/debug: Factor out printing formats into common macros
        sched/debug: Remove redundant macro define
        sched/core: Remove unused rq::last_load_update_tick
        workqueue: Remove the warning in wq_worker_sleeping()
        sched/fair: Fix negative imbalance in imbalance calculation
        sched/fair: Fix race between runtime distribution and assignment
        sched/fair: Align rq->avg_idle and rq->avg_scan_cost
      590680d1
    • Linus Torvalds's avatar
      Merge tag 'perf-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 20e2aa81
      Linus Torvalds authored
      Pull perf fixes from Thomas Gleixner:
       "Three fixes/updates for perf:
      
         - Fix the perf event cgroup tracking which tries to track the cgroup
           even for disabled events.
      
         - Add Ice Lake server support for uncore events
      
         - Disable pagefaults when retrieving the physical address in the
           sampling code"
      
      * tag 'perf-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf/core: Disable page faults when getting phys address
        perf/x86/intel/uncore: Add Ice Lake server uncore support
        perf/cgroup: Correct indirection in perf_less_group_idx()
        perf/core: Fix event cgroup tracking
      20e2aa81
    • Linus Torvalds's avatar
      Merge tag 'locking-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 652fa53c
      Linus Torvalds authored
      Pull locking fixes from Thomas Gleixner:
       "Three small fixes/updates for the locking core code:
      
         - Plug a task struct reference leak in the percpu rswem
           implementation.
      
         - Document the refcount interaction with PID_MAX_LIMIT
      
         - Improve the 'invalid wait context' data dump in lockdep so it
           contains all information which is required to decode the problem"
      
      * tag 'locking-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        locking/lockdep: Improve 'invalid wait context' splat
        locking/refcount: Document interaction with PID_MAX_LIMIT
        locking/percpu-rwsem: Fix a task_struct refcount
      652fa53c
    • Linus Torvalds's avatar
      Merge tag '5.7-rc-smb3-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6 · 4119bf9f
      Linus Torvalds authored
      Pull cifs fixes from Steve French:
       "Ten cifs/smb fixes:
      
         - five RDMA (smbdirect) related fixes
      
         - add experimental support for swap over SMB3 mounts
      
         - also a fix which improves performance of signed connections"
      
      * tag '5.7-rc-smb3-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6:
        smb3: enable swap on SMB3 mounts
        smb3: change noisy error message to FYI
        smb3: smbdirect support can be configured by default
        cifs: smbd: Do not schedule work to send immediate packet on every receive
        cifs: smbd: Properly process errors on ib_post_send
        cifs: Allocate crypto structures on the fly for calculating signatures of incoming packets
        cifs: smbd: Update receive credits before sending and deal with credits roll back on failure before sending
        cifs: smbd: Check send queue size before posting a send
        cifs: smbd: Merge code to track pending packets
        cifs: ignore cached share root handle closing errors
      4119bf9f
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-5.7-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs · 50bda5fa
      Linus Torvalds authored
      Pull NFS client bugfix from Trond Myklebust:
       "Fix an RCU read lock leakage in pnfs_alloc_ds_commits_list()"
      
      * tag 'nfs-for-5.7-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
        pNFS: Fix RCU lock leakage
      50bda5fa
  5. 11 Apr, 2020 14 commits
  6. 10 Apr, 2020 5 commits