1. 03 Aug, 2020 5 commits
    • André Almeida's avatar
      selftests: futex: Add futex2 wouldblock test · ff5b565c
      André Almeida authored
      Adapt existing futex wait wouldblock file to test the same mechanism for
      Signed-off-by: André Almeida's avatarAndré Almeida <andrealmeid@collabora.com>
    • André Almeida's avatar
      selftests: futex: Add futex2 timeout test · 7e94285e
      André Almeida authored
      Adapt existing futex wait timeout file to test the same mechanism for
      Signed-off-by: André Almeida's avatarAndré Almeida <andrealmeid@collabora.com>
    • André Almeida's avatar
      selftests: futex: Add futex2 wake/wait test · a659243d
      André Almeida authored
      Add a simple test to test wake/wait mechanism using futex2 interface.
      Create helper files so more tests can evaluate futex2. While 32bit ABIs
      from glibc aren't able to use 64 bit sized time variables, add a
      temporary workaround that implements the required types and calls the
      appropriated syscalls, since futex2 doesn't supports 32 bit sized time.
      Signed-off-by: André Almeida's avatarAndré Almeida <andrealmeid@collabora.com>
    • André Almeida's avatar
      futex2: Add new futex interface · abe30442
      André Almeida authored
      This RFC is a followup to the previous discussion initiated from my last
      patch "futex: Implement mechanism to wait on any of several futexes"[1].
      As stated in the thread, the correct approach to move forward with the
      wait multiple operation would be to create a new syscall that would have
      all new cool features.
      The first patch adds the new interface and just translate the call for
      the old interface, without implementing new features. The goal here is
      to establish the interface and to check if everyone is happy with this
      API. The rest of patches are selftests to show the interface in action.
      I have the following questions:
      - What suggestions do you have to implement this? Start from scratch or
        reuse the most code possible?
      - The interface seems correct and implements the requirements asked by you?
      Those are the cool new features that this syscall should address some
      - Operate with variable bit size futexes, not restricted to 32:
        8, 16 and 64
      - Wait on multiple futexes, using the following semantics:
        struct futex_wait {
      	void *uaddr;
      	unsigned long val;
      	unsigned long flags;
        sys_futex_waitv(struct futex_wait *waiters, unsigned int nr_waiters,
      		  unsigned long flags, struct __kernel_timespec *timo);
      - Have NUMA optimizations: if FUTEX_NUMA_FLAG is set, the `void *uaddr`
        argument won't be a value of type u{8, 16, 32, 64} anymore, but a struct
        containing a NUMA node hint:
        struct futex32_numa {
      	  u32 value __attribute__ ((aligned (8)));
      	  u32 hint;
        struct futex64_numa {
      	  u64 value __attribute__ ((aligned (16)));
      	  u64 hint;
      Changes since v2:
       - Fix kernel-doc format
      v2: https://lore.kernel.org/patchwork/cover/1270504/
      Changes since v1:
       - The timeout argument now uses __kernel_timespec as type
       - time32 interface was removed
      v1: https://lore.kernel.org/patchwork/cover/1255437/
      [1] https://lore.kernel.org/patchwork/patch/1194339/
      --- >8 ---
      Subject: [RFC 1/4] futex2: Add new futex interface
      Add a new futex interface into the kernel, namely futex2. This first
      piece of work just introduces the new interface without new feature for
      now, using all mechanisms of the old interface in order to work. This
      way we can properly formalize the expectations around the new design,
      while being able to expand the code as we need and even in parallel
      efforts if possible.
      This new interface is able just to wait and wake on a 32 bits user futex.
      The wait operation supports timeout with absolute values only, using
      timespec64, in monotonic or realtime mode. This syscall is not compatible
      with ABIs that have timesize as 32 bits, only the ones that support 64
      bits timesize. The code can be found in my git tree[1].
      The design of this syscall was based on the discussion following the
      "futex: Implement mechanism to wait on any of several futexes" patch[2].
      In order to test the code, the glibc 2.31 low level futex code was
      modified to use the new syscall. It's possible to find the code here[3].
      After running the tests of glibc (`make check subdir=nptl`), only 26
      tests of 370 didn't passed, and since they are all related to FUTEX_PI,
      which isn't implemented in the new interface, those failures were expected.
      All kernel selftests were successful.
      [1] https://gitlab.collabora.com/tonyk/linux/-/commits/futex2
      [2] https://lore.kernel.org/patchwork/patch/1194339/
      [3] https://gitlab.collabora.com/tonyk/glibc/-/commits/futex2Signed-off-by: André Almeida's avatarAndré Almeida <andrealmeid@collabora.com>
    • Ingo Molnar's avatar
  2. 01 Aug, 2020 2 commits
  3. 31 Jul, 2020 6 commits
    • Ingo Molnar's avatar
      Merge branch 'linus' into locking/core, to resolve conflict · 28cff52e
      Ingo Molnar authored
      As Stephen Rothwell noted, there's a conflict between this commit
      in locking/core:
        a21ee605 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu variables")
      and this fresh upstream commit:
        aa54ea90 ("ARM: percpu.h: fix build error")
      a21ee605 is a simpler solution to the dependency problem and doesn't
      further increase header hell - so this conflict resolution effectively
      reverts aa54ea90 and uses the a21ee605 solution.
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Marco Elver's avatar
      kcsan: Improve IRQ state trace reporting · 92c209ac
      Marco Elver authored
      To improve the general usefulness of the IRQ state trace events with
      KCSAN enabled, save and restore the trace information when entering and
      exiting the KCSAN runtime as well as when generating a KCSAN report.
      Without this, reporting the IRQ trace events (whether via a KCSAN report
      or outside of KCSAN via a lockdep report) is rather useless due to
      continuously being touched by KCSAN. This is because if KCSAN is
      enabled, every instrumented memory access causes changes to IRQ trace
      events (either by KCSAN disabling/enabling interrupts or taking
      report_lock when generating a report).
      Before "lockdep: Prepare for NMI IRQ state tracking", KCSAN avoided
      touching the IRQ trace events via raw_local_irq_save/restore() and
      Fixes: 248591f5 ("kcsan: Make KCSAN compatible with new IRQ state tracking")
      Signed-off-by: default avatarMarco Elver <elver@google.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Link: https://lore.kernel.org/r/20200729110916.3920464-2-elver@google.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Marco Elver's avatar
      lockdep: Refactor IRQ trace events fields into struct · 0584df9c
      Marco Elver authored
      Refactor the IRQ trace events fields, used for printing information
      about the IRQ trace events, into a separate struct 'irqtrace_events'.
      This improves readability by separating the information only used in
      reporting, as well as enables (simplified) storing/restoring of
      irqtrace_events snapshots.
      No functional change intended.
      Signed-off-by: default avatarMarco Elver <elver@google.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Link: https://lore.kernel.org/r/20200729110916.3920464-1-elver@google.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2020-07-31' of git://anongit.freedesktop.org/drm/drm · d8b9faec
      Linus Torvalds authored
      Pull more drm fixes from Dave Airlie:
       "As mentioned previously this contains the nouveau regression fix.
        amdgpu had three fixes outstanding as well, one revert, an info leak
        and use after free. The use after free is a bit trickier than I'd
        like, and I've personally gone over it to confirm I'm happy that it is
        doing what it says.
         - final modifiers regression fix
         - Revert a fix which caused other regressions
         - Fix potential kernel info leak
         - Fix a use-after-free bug that was uncovered by another change in 5.7"
      * tag 'drm-fixes-2020-07-31' of git://anongit.freedesktop.org/drm/drm:
        drm/nouveau: Accept 'legacy' format modifiers
        Revert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers"
        drm/amd/display: Clear dm_state for fast updates
        drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
    • Dave Airlie's avatar
      Merge tag 'amd-drm-fixes-5.8-2020-07-30' of... · 887c909d
      Dave Airlie authored
      Merge tag 'amd-drm-fixes-5.8-2020-07-30' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
      - Revert a fix which caused other regressions
      - Fix potential kernel info leak
      - Fix a use-after-free bug that was uncovered by another change in 5.7
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      From: Alex Deucher <alexdeucher@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200730154338.244104-1-alexander.deucher@amd.com
    • James Jones's avatar
      drm/nouveau: Accept 'legacy' format modifiers · faa0fcf9
      James Jones authored
      Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
      family of modifiers to handle broken userspace
      Xorg modesetting and Mesa drivers. Existing Mesa
      drivers are still aware of only these older
      format modifiers which do not differentiate
      between different variations of the block linear
      layout. When the format modifier support flag was
      flipped in the nouveau kernel driver, the X.org
      modesetting driver began attempting to use its
      format modifier-enabled framebuffer path. Because
      the set of format modifiers advertised by the
      kernel prior to this change do not intersect with
      the set of format modifiers advertised by Mesa,
      allocating GBM buffers using format modifiers
      fails and the modesetting driver falls back to
      non-modifier allocation. However, it still later
      queries the modifier of the GBM buffer when
      creating its DRM-KMS framebuffer object, receives
      the old-format modifier from Mesa, and attempts
      to create a framebuffer with it. Since the kernel
      is still not aware of these formats, this fails.
      Userspace should not be attempting to query format
      modifiers of GBM buffers allocated with a non-
      format-modifier-aware allocation path, but to
      avoid breaking existing userspace behavior, this
      change accepts the old-style format modifiers when
      creating framebuffers and applying them to planes
      by translating them to the equivalent new-style
      modifier. To accomplish this, some layout
      parameters must be assumed to match properties of
      the device targeted by the relevant ioctls. To
      avoid perpetuating misuse of the old-style
      modifiers, this change does not advertise support
      for them. Doing so would imply compatibility
      between devices with incompatible memory layouts.
      Tested with Xorg 1.20 modesetting driver,
      gnome & KDE wayland desktops from Ubuntu 18.04,
      and sway 1.5
      Reported-by: default avatarKirill A. Shutemov <kirill@shutemov.name>
      Fixes: fa4f4c21 ("drm/nouveau/kms: Support NVIDIA format modifiers")
      Link: https://lkml.org/lkml/2020/6/30/1251Signed-off-by: default avatarJames Jones <jajones@nvidia.com>
      Acked-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  4. 30 Jul, 2020 12 commits
  5. 29 Jul, 2020 15 commits