1. 12 3月, 2020 1 次提交
    • H
      x86: Select HARDIRQS_SW_RESEND on x86 · 17e5888e
      Hans de Goede 提交于
      Modern x86 laptops are starting to use GPIO pins as interrupts more
      and more, e.g. touchpads and touchscreens have almost all moved away
      from PS/2 and USB to using I2C with a GPIO pin as interrupt.
      Modern x86 laptops also have almost all moved to using s2idle instead
      of using the system S3 ACPI power state to suspend.
      
      The Intel and AMD pinctrl drivers do not define irq_retrigger handlers
      for the irqchips they register, this is causing edge triggered interrupts
      which happen while suspended using s2idle to get lost.
      
      One specific example of this is the lid switch on some devices, lid
      switches used to be handled by the embedded-controller, but now the
      lid open/closed sensor is sometimes directly connected to a GPIO pin.
      On most devices the ACPI code for this looks like this:
      
      Method (_E00, ...) {
      	Notify (LID0, 0x80) // Status Change
      }
      
      Where _E00 is an ACPI event handler for changes on both edges of the GPIO
      connected to the lid sensor, this event handler is then combined with an
      _LID method which directly reads the pin. When the device is resumed by
      opening the lid, the GPIO interrupt will wake the system, but because the
      pinctrl irqchip doesn't have an irq_retrigger handler, the Notify will not
      happen. This is not a problem in the case the _LID method directly reads
      the GPIO, because the drivers/acpi/button.c code will call _LID on resume
      anyways.
      
      But some devices have an event handler for the GPIO connected to the
      lid sensor which looks like this:
      
      Method (_E00, ...) {
      	if (LID_GPIO == One)
      		LIDS = One
      	else
      		LIDS = Zero
      	Notify (LID0, 0x80) // Status Change
      }
      
      And the _LID method returns the cached LIDS value, since on open we
      do not re-run the edge-interrupt handler when we re-enable IRQS on resume
      (because of the missing irq_retrigger handler), _LID now will keep
      reporting closed, as LIDS was never changed to reflect the open status,
      this causes userspace to re-resume the laptop again shortly after opening
      the lid.
      
      The Intel GPIO controllers do not allow implementing irq_retrigger without
      emulating it in software, at which point we are better of just using the
      generic HARDIRQS_SW_RESEND mechanism rather then re-implementing software
      emulation for this separately in aprox. 14 different pinctrl drivers.
      
      Select HARDIRQS_SW_RESEND to solve the problem of edge-triggered GPIO
      interrupts not being re-triggered on resume when they were triggered during
      suspend (s2idle) and/or when they were the cause of the wakeup.
      
      This requires
      
       008f1d60 ("x86/apic/vector: Force interupt handler invocation to irq context")
       c16816ac ("genirq: Add protection against unsafe usage of generic_handle_irq()")
      
      to protect the APIC based interrupts from being wreckaged by a software
      resend.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20200123210242.53367-1-hdegoede@redhat.com
      17e5888e
  2. 08 3月, 2020 9 次提交
  3. 02 3月, 2020 4 次提交
    • L
      Linux 5.6-rc4 · 98d54f81
      Linus Torvalds 提交于
      98d54f81
    • L
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · e7086982
      Linus Torvalds 提交于
      Pull ext4 fixes from Ted Ts'o:
       "Two more bug fixes (including a regression) for 5.6"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: potential crash on allocation error in ext4_alloc_flex_bg_array()
        jbd2: fix data races at struct journal_head
      e7086982
    • L
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · f853ed90
      Linus Torvalds 提交于
      Pull KVM fixes from Paolo Bonzini:
       "More bugfixes, including a few remaining "make W=1" issues such as too
        large frame sizes on some configurations.
      
        On the ARM side, the compiler was messing up shadow stacks between EL1
        and EL2 code, which is easily fixed with __always_inline"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: VMX: check descriptor table exits on instruction emulation
        kvm: x86: Limit the number of "kvm: disabled by bios" messages
        KVM: x86: avoid useless copy of cpufreq policy
        KVM: allow disabling -Werror
        KVM: x86: allow compiling as non-module with W=1
        KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis
        KVM: Introduce pv check helpers
        KVM: let declaration of kvm_get_running_vcpus match implementation
        KVM: SVM: allocate AVIC data structures based on kvm_amd module parameter
        arm64: Ask the compiler to __always_inline functions used by KVM at HYP
        KVM: arm64: Define our own swab32() to avoid a uapi static inline
        KVM: arm64: Ask the compiler to __always_inline functions used at HYP
        kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe()
        KVM: arm/arm64: Fix up includes for trace.h
      f853ed90
    • O
      KVM: VMX: check descriptor table exits on instruction emulation · 86f7e90c
      Oliver Upton 提交于
      KVM emulates UMIP on hardware that doesn't support it by setting the
      'descriptor table exiting' VM-execution control and performing
      instruction emulation. When running nested, this emulation is broken as
      KVM refuses to emulate L2 instructions by default.
      
      Correct this regression by allowing the emulation of descriptor table
      instructions if L1 hasn't requested 'descriptor table exiting'.
      
      Fixes: 07721fee ("KVM: nVMX: Don't emulate instructions in guest mode")
      Reported-by: NJan Kiszka <jan.kiszka@web.de>
      Cc: stable@vger.kernel.org
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Jim Mattson <jmattson@google.com>
      Signed-off-by: NOliver Upton <oupton@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      86f7e90c
  4. 01 3月, 2020 4 次提交
    • L
      Merge branch 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · fb279f4e
      Linus Torvalds 提交于
      Pull i2c fixes from Wolfram Sang:
       "I2C has three driver bugfixes for you. We agreed on the Mac regression
        to go in via I2C"
      
      * 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        macintosh: therm_windtunnel: fix regression when instantiating devices
        i2c: altera: Fix potential integer overflow
        i2c: jz4780: silence log flood on txabrt
      fb279f4e
    • D
      ext4: potential crash on allocation error in ext4_alloc_flex_bg_array() · 37b0b6b8
      Dan Carpenter 提交于
      If sbi->s_flex_groups_allocated is zero and the first allocation fails
      then this code will crash.  The problem is that "i--" will set "i" to
      -1 but when we compare "i >= sbi->s_flex_groups_allocated" then the -1
      is type promoted to unsigned and becomes UINT_MAX.  Since UINT_MAX
      is more than zero, the condition is true so we call kvfree(new_groups[-1]).
      The loop will carry on freeing invalid memory until it crashes.
      
      Fixes: 7c990728 ("ext4: fix potential race between s_flex_groups online resizing and access")
      Reviewed-by: NSuraj Jitindar Singh <surajjs@amazon.com>
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Link: https://lore.kernel.org/r/20200228092142.7irbc44yaz3by7nb@kili.mountainSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      37b0b6b8
    • W
      macintosh: therm_windtunnel: fix regression when instantiating devices · 38b17afb
      Wolfram Sang 提交于
      Removing attach_adapter from this driver caused a regression for at
      least some machines. Those machines had the sensors described in their
      DT, too, so they didn't need manual creation of the sensor devices. The
      old code worked, though, because manual creation came first. Creation of
      DT devices then failed later and caused error logs, but the sensors
      worked nonetheless because of the manually created devices.
      
      When removing attach_adaper, manual creation now comes later and loses
      the race. The sensor devices were already registered via DT, yet with
      another binding, so the driver could not be bound to it.
      
      This fix refactors the code to remove the race and only manually creates
      devices if there are no DT nodes present. Also, the DT binding is updated
      to match both, the DT and manually created devices. Because we don't
      know which device creation will be used at runtime, the code to start
      the kthread is moved to do_probe() which will be called by both methods.
      
      Fixes: 3e7bed52 ("macintosh: therm_windtunnel: drop using attach_adapter")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723Reported-by: NErhard Furtner <erhard_f@mailbox.org>
      Tested-by: NErhard Furtner <erhard_f@mailbox.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org # v4.19+
      38b17afb
    • Q
      jbd2: fix data races at struct journal_head · 6c5d9112
      Qian Cai 提交于
      journal_head::b_transaction and journal_head::b_next_transaction could
      be accessed concurrently as noticed by KCSAN,
      
       LTP: starting fsync04
       /dev/zero: Can't open blockdev
       EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem
       EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
       ==================================================================
       BUG: KCSAN: data-race in __jbd2_journal_refile_buffer [jbd2] / jbd2_write_access_granted [jbd2]
      
       write to 0xffff99f9b1bd0e30 of 8 bytes by task 25721 on cpu 70:
        __jbd2_journal_refile_buffer+0xdd/0x210 [jbd2]
        __jbd2_journal_refile_buffer at fs/jbd2/transaction.c:2569
        jbd2_journal_commit_transaction+0x2d15/0x3f20 [jbd2]
        (inlined by) jbd2_journal_commit_transaction at fs/jbd2/commit.c:1034
        kjournald2+0x13b/0x450 [jbd2]
        kthread+0x1cd/0x1f0
        ret_from_fork+0x27/0x50
      
       read to 0xffff99f9b1bd0e30 of 8 bytes by task 25724 on cpu 68:
        jbd2_write_access_granted+0x1b2/0x250 [jbd2]
        jbd2_write_access_granted at fs/jbd2/transaction.c:1155
        jbd2_journal_get_write_access+0x2c/0x60 [jbd2]
        __ext4_journal_get_write_access+0x50/0x90 [ext4]
        ext4_mb_mark_diskspace_used+0x158/0x620 [ext4]
        ext4_mb_new_blocks+0x54f/0xca0 [ext4]
        ext4_ind_map_blocks+0xc79/0x1b40 [ext4]
        ext4_map_blocks+0x3b4/0x950 [ext4]
        _ext4_get_block+0xfc/0x270 [ext4]
        ext4_get_block+0x3b/0x50 [ext4]
        __block_write_begin_int+0x22e/0xae0
        __block_write_begin+0x39/0x50
        ext4_write_begin+0x388/0xb50 [ext4]
        generic_perform_write+0x15d/0x290
        ext4_buffered_write_iter+0x11f/0x210 [ext4]
        ext4_file_write_iter+0xce/0x9e0 [ext4]
        new_sync_write+0x29c/0x3b0
        __vfs_write+0x92/0xa0
        vfs_write+0x103/0x260
        ksys_write+0x9d/0x130
        __x64_sys_write+0x4c/0x60
        do_syscall_64+0x91/0xb05
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
       5 locks held by fsync04/25724:
        #0: ffff99f9911093f8 (sb_writers#13){.+.+}, at: vfs_write+0x21c/0x260
        #1: ffff99f9db4c0348 (&sb->s_type->i_mutex_key#15){+.+.}, at: ext4_buffered_write_iter+0x65/0x210 [ext4]
        #2: ffff99f5e7dfcf58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2]
        #3: ffff99f9db4c0168 (&ei->i_data_sem){++++}, at: ext4_map_blocks+0x176/0x950 [ext4]
        #4: ffffffff99086b40 (rcu_read_lock){....}, at: jbd2_write_access_granted+0x4e/0x250 [jbd2]
       irq event stamp: 1407125
       hardirqs last  enabled at (1407125): [<ffffffff980da9b7>] __find_get_block+0x107/0x790
       hardirqs last disabled at (1407124): [<ffffffff980da8f9>] __find_get_block+0x49/0x790
       softirqs last  enabled at (1405528): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c
       softirqs last disabled at (1405521): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0
      
       Reported by Kernel Concurrency Sanitizer on:
       CPU: 68 PID: 25724 Comm: fsync04 Tainted: G L 5.6.0-rc2-next-20200221+ #7
       Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
      
      The plain reads are outside of jh->b_state_lock critical section which result
      in data races. Fix them by adding pairs of READ|WRITE_ONCE().
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NQian Cai <cai@lca.pw>
      Link: https://lore.kernel.org/r/20200222043111.2227-1-cai@lca.pwSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      6c5d9112
  5. 29 2月, 2020 8 次提交
  6. 28 2月, 2020 14 次提交