linux-stable.git/include, branch v4.4.256

iommu/vt-d: Don't dereference iommu_device if IOMMU_API is not built

2021-02-03T22:16:17+00:00

commit 9def3b1a07c41e21c68a0eb353e3e569fdd1d2b1 upstream.

Since commit c40aaaac1018 ("iommu/vt-d: Gracefully handle DMAR units
with no supported address widths") dmar.c needs struct iommu_device to
be selected. We can drop this dependency by not dereferencing struct
iommu_device if IOMMU_API is not selected and by reusing the information
stored in iommu->drhd->ignored instead.

This fixes the following build error when IOMMU_API is not selected:

drivers/iommu/dmar.c: In function ‘free_iommu’:
drivers/iommu/dmar.c:1139:41: error: ‘struct iommu_device’ has no member named ‘ops’
 1139 |  if (intel_iommu_enabled && iommu->iommu.ops) {
                                                ^

Fixes: c40aaaac1018 ("iommu/vt-d: Gracefully handle DMAR units with no supported address widths")
Signed-off-by: Bartosz Golaszewski 
Acked-by: Lu Baolu 
Acked-by: David Woodhouse 
Link: https://lore.kernel.org/r/20201013073055.11262-1-brgl@bgdev.pl
Signed-off-by: Joerg Roedel 
[ - context change due to moving drivers/iommu/dmar.c to
    drivers/iommu/intel/dmar.c
  - set the drhr in the iommu like in upstream commit b1012ca8dc4f
    ("iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu") ]
Signed-off-by: Filippo Sironi 
Signed-off-by: Greg Kroah-Hartman

futex: Add mutex around futex exit

2021-02-03T22:16:16+00:00

commit 3f186d974826847a07bc7964d79ec4eded475ad9 upstream.

The mutex will be used in subsequent changes to replace the busy looping of
a waiter when the futex owner is currently executing the exit cleanup to
prevent a potential live lock.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20191106224556.845798895@linutronix.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

futex: Mark the begin of futex exit explicitly

2021-02-03T22:16:16+00:00

commit 18f694385c4fd77a09851fd301236746ca83f3cb upstream.

Instead of relying on PF_EXITING use an explicit state for the futex exit
and set it in the futex exit function. This moves the smp barrier and the
lock/unlock serialization into the futex code.

As with the DEAD state this is restricted to the exit path as exec
continues to use the same task struct.

This allows to simplify that logic in a next step.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20191106224556.539409004@linutronix.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

futex: Split futex_mm_release() for exit/exec

2021-02-03T22:16:16+00:00

commit 150d71584b12809144b8145b817e83b81158ae5f upstream.

To allow separate handling of the futex exit state in the futex exit code
for exit and exec, split futex_mm_release() into two functions and invoke
them from the corresponding exit/exec_mm_release() callsites.

Preparatory only, no functional change.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20191106224556.332094221@linutronix.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

exit/exec: Seperate mm_release()

2021-02-03T22:16:16+00:00

commit 4610ba7ad877fafc0a25a30c6c82015304120426 upstream.

mm_release() contains the futex exit handling. mm_release() is called from
do_exit()->exit_mm() and from exec()->exec_mm().

In the exit_mm() case PF_EXITING and the futex state is updated. In the
exec_mm() case these states are not touched.

As the futex exit code needs further protections against exit races, this
needs to be split into two functions.

Preparatory only, no functional change.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20191106224556.240518241@linutronix.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

futex: Replace PF_EXITPIDONE with a state

2021-02-03T22:16:16+00:00

commit 3d4775df0a89240f671861c6ab6e8d59af8e9e41 upstream.

The futex exit handling relies on PF_ flags. That's suboptimal as it
requires a smp_mb() and an ugly lock/unlock of the exiting tasks pi_lock in
the middle of do_exit() to enforce the observability of PF_EXITING in the
futex code.

Add a futex_state member to task_struct and convert the PF_EXITPIDONE logic
over to the new state. The PF_EXITING dependency will be cleaned up in a
later step.

This prepares for handling various futex exit issues later.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20191106224556.149449274@linutronix.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

futex: Move futex exit handling into futex code

2021-02-03T22:16:16+00:00

commit ba31c1a48538992316cc71ce94fa9cd3e7b427c0 upstream.

The futex exit handling is #ifdeffed into mm_release() which is not pretty
to begin with. But upcoming changes to address futex exit races need to add
more functionality to this exit code.

Split it out into a function, move it into futex code and make the various
futex exit functions static.

Preparatory only and no functional change.

Folded build fix from Borislav.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20191106224556.049705556@linutronix.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

y2038: futex: Move compat implementation into futex.c

2021-02-03T22:16:16+00:00

commit 04e7712f4460585e5eed5b853fd8b82a9943958f upstream.

We are going to share the compat_sys_futex() handler between 64-bit
architectures and 32-bit architectures that need to deal with both 32-bit
and 64-bit time_t, and this is easier if both entry points are in the
same file.

In fact, most other system call handlers do the same thing these days, so
let's follow the trend here and merge all of futex_compat.c into futex.c.

In the process, a few minor changes have to be done to make sure everything
still makes sense: handle_futex_death() and futex_cmpxchg_enabled() become
local symbol, and the compat version of the fetch_robust_entry() function
gets renamed to compat_fetch_robust_entry() to avoid a symbol clash.

This is intended as a purely cosmetic patch, no behavior should
change.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
[Lee: Back-ported to satisfy a build dependency]
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

compiler.h: Raise minimum version of GCC to 5.1 for arm64

2021-01-30T12:25:56+00:00

commit dca5244d2f5b94f1809f0c02a549edf41ccd5493 upstream.

GCC versions >= 4.9 and < 5.1 have been shown to emit memory references
beyond the stack pointer, resulting in memory corruption if an interrupt
is taken after the stack pointer has been adjusted but before the
reference has been executed. This leads to subtle, infrequent data
corruption such as the EXT4 problems reported by Russell King at the
link below.

Life is too short for buggy compilers, so raise the minimum GCC version
required by arm64 to 5.1.

Reported-by: Russell King 
Suggested-by: Arnd Bergmann 
Signed-off-by: Will Deacon 
Tested-by: Nathan Chancellor 
Reviewed-by: Nick Desaulniers 
Reviewed-by: Nathan Chancellor 
Acked-by: Linus Torvalds 
Cc: 
Cc: Theodore Ts'o 
Cc: Florian Weimer 
Cc: Peter Zijlstra 
Cc: Nick Desaulniers 
Link: https://lore.kernel.org/r/20210105154726.GD1551@shell.armlinux.org.uk
Link: https://lore.kernel.org/r/20210112224832.10980-1-will@kernel.org
Signed-off-by: Catalin Marinas 
[will: backport to 4.4.y/4.9.y/4.14.y; add __clang__ check]
Link: https://lore.kernel.org/r/CA+G9fYuzE9WMSB7uGjV4gTzK510SHEdJb_UXQCzsQ5MqA=h9SA@mail.gmail.com
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

Input: uinput - avoid FF flush when destroying device

2021-01-23T14:36:55+00:00

commit e8b95728f724797f958912fd9b765a695595d3a6 upstream.

Normally, when input device supporting force feedback effects is being
destroyed, we try to "flush" currently playing effects, so that the
physical device does not continue vibrating (or executing other effects).
Unfortunately this does not work well for uinput as flushing of the effects
deadlocks with the destroy action:

- if device is being destroyed because the file descriptor is being closed,
  then there is noone to even service FF requests;

- if device is being destroyed because userspace sent UI_DEV_DESTROY,
  while theoretically it could be possible to service FF requests,
  userspace is unlikely to do so (they'd need to make sure FF handling
  happens on a separate thread) even if kernel solves the issue with FF
  ioctls deadlocking with UI_DEV_DESTROY ioctl on udev->mutex.

To avoid lockups like the one below, let's install a custom input device
flush handler, and avoid trying to flush force feedback effects when we
destroying the device, and instead rely on uinput to shut off the device
properly.

NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
...
 <>  [] _raw_spin_lock_irqsave+0x37/0x40
 [] complete+0x1d/0x50
 [] uinput_request_done+0x3c/0x40 [uinput]
 [] uinput_request_submit.part.7+0x47/0xb0 [uinput]
 [] uinput_dev_erase_effect+0x5b/0x76 [uinput]
 [] erase_effect+0xad/0xf0
 [] flush_effects+0x4d/0x90
 [] input_flush_device+0x40/0x60
 [] evdev_cleanup+0xac/0xc0
 [] evdev_disconnect+0x2b/0x60
 [] __input_unregister_device+0xac/0x150
 [] input_unregister_device+0x47/0x70
 [] uinput_destroy_device+0xb5/0xc0 [uinput]
 [] uinput_ioctl_handler.isra.9+0x65e/0x740 [uinput]
 [] ? do_futex+0x12b/0xad0
 [] uinput_ioctl+0x18/0x20 [uinput]
 [] do_vfs_ioctl+0x298/0x480
 [] ? security_file_ioctl+0x43/0x60
 [] SyS_ioctl+0x79/0x90
 [] entry_SYSCALL_64_fastpath+0x12/0x71

Reported-by: Rodrigo Rivas Costa 
Reported-by: Clément VUCHENER 
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=193741
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman