1. 25 Sep, 2022 2 commits
  2. 29 Aug, 2022 1 commit
  3. 28 Aug, 2022 1 commit
  4. 23 Aug, 2022 2 commits
  5. 22 Aug, 2022 1 commit
  6. 11 Aug, 2022 2 commits
  7. 02 Aug, 2022 2 commits
  8. 28 Jul, 2022 1 commit
  9. 20 Jul, 2022 2 commits
  10. 11 Jul, 2022 1 commit
  11. 09 Jul, 2022 3 commits
  12. 08 Jul, 2022 13 commits
  13. 06 Jul, 2022 1 commit
  14. 03 Jul, 2022 4 commits
    • Linus Torvalds's avatar
      Linux 5.19-rc5 · 88084a3d
      Linus Torvalds authored
      88084a3d
    • Linus Torvalds's avatar
      lockref: remove unused 'lockref_get_or_lock()' function · b8d5109f
      Linus Torvalds authored
      Looking at the conditional lock acquire functions in the kernel due to
      the new sparse support (see commit 4a557a5d "sparse: introduce
      conditional lock acquire function attribute"), it became obvious that
      the lockref code has a couple of them, but they don't match the usual
      naming convention for the other ones, and their return value logic is
      also reversed.
      
      In the other very similar places, the naming pattern is '*_and_lock()'
      (eg 'atomic_put_and_lock()' and 'refcount_dec_and_lock()'), and the
      function returns true when the lock is taken.
      
      The lockref code is superficially very similar to the refcount code,
      only with the special "atomic wrt the embedded lock" semantics.  But
      instead of the '*_and_lock()' naming it uses '*_or_lock()'.
      
      And instead of returning true in case it took the lock, it returns true
      if it *didn't* take the lock.
      
      Now, arguably the reflock code is quite logical: it really is a "either
      decrement _or_ lock" kind of situation - and the return value is about
      whether the operation succeeded without any special care needed.
      
      So despite the similarities, the differences do make some sense, and
      maybe it's not worth trying to unify the different conditional locking
      primitives in this area.
      
      But while looking at this all, it did become obvious that the
      'lockref_get_or_lock()' function hasn't actually had any users for
      almost a decade.
      
      The only user it ever had was the shortlived 'd_rcu_to_refcount()'
      function, and it got removed and replaced with 'lockref_get_not_dead()'
      back in 2013 in commits 0d98439e ("vfs: use lockred 'dead' flag to
      mark unrecoverably dead dentries") and e5c832d5 ("vfs: fix dentry
      RCU to refcounting possibly sleeping dput()")
      
      In fact, that single use was removed less than a week after the whole
      function was introduced in commit b3abd802 ("lockref: add
      'lockref_get_or_lock() helper") so this function has been around for a
      decade, but only had a user for six days.
      
      Let's just put this mis-designed and unused function out of its misery.
      
      We can think about the naming and semantic oddities of the remaining
      'lockref_put_or_lock()' later, but at least that function has users.
      
      And while the naming is different and the return value doesn't match,
      that function matches the whole '{atomic,refcount}_dec_and_test()'
      pattern much better (ie the magic happens when the count goes down to
      zero, not when it is incremented from zero).
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b8d5109f
    • Linus Torvalds's avatar
      sparse: introduce conditional lock acquire function attribute · 4a557a5d
      Linus Torvalds authored
      The kernel tends to try to avoid conditional locking semantics because
      it makes it harder to think about and statically check locking rules,
      but we do have a few fundamental locking primitives that take locks
      conditionally - most obviously the 'trylock' functions.
      
      That has always been a problem for 'sparse' checking for locking
      imbalance, and we've had a special '__cond_lock()' macro that we've used
      to let sparse know how the locking works:
      
          # define __cond_lock(x,c)        ((c) ? ({ __acquire(x); 1; }) : 0)
      
      so that you can then use this to tell sparse that (for example) the
      spinlock trylock macro ends up acquiring the lock when it succeeds, but
      not when it fails:
      
          #define raw_spin_trylock(lock)  __cond_lock(lock, _raw_spin_trylock(lock))
      
      and then sparse can follow along the locking rules when you have code like
      
              if (!spin_trylock(&dentry->d_lock))
                      return LRU_SKIP;
      	.. sparse sees that the lock is held here..
              spin_unlock(&dentry->d_lock);
      
      and sparse ends up happy about the lock contexts.
      
      However, this '__cond_lock()' use does result in very ugly header files,
      and requires you to basically wrap the real function with that macro
      that uses '__cond_lock'.  Which has made PeterZ NAK things that try to
      fix sparse warnings over the years [1].
      
      To solve this, there is now a very experimental patch to sparse that
      basically does the exact same thing as '__cond_lock()' did, but using a
      function attribute instead.  That seems to make PeterZ happy [2].
      
      Note that this does not replace existing use of '__cond_lock()', but
      only exposes the new proposed attribute and uses it for the previously
      unannotated 'refcount_dec_and_lock()' family of functions.
      
      For existing sparse installations, this will make no difference (a
      negative output context was ignored), but if you have the experimental
      sparse patch it will make sparse now understand code that uses those
      functions, the same way '__cond_lock()' makes sparse understand the very
      similar 'atomic_dec_and_lock()' uses that have the old '__cond_lock()'
      annotations.
      
      Note that in some cases this will silence existing context imbalance
      warnings.  But in other cases it may end up exposing new sparse warnings
      for code that sparse just didn't see the locking for at all before.
      
      This is a trial, in other words.  I'd expect that if it ends up being
      successful, and new sparse releases end up having this new attribute,
      we'll migrate the old-style '__cond_lock()' users to use the new-style
      '__cond_acquires' function attribute.
      
      The actual experimental sparse patch was posted in [3].
      
      Link: https://lore.kernel.org/all/20130930134434.GC12926@twins.programming.kicks-ass.net/ [1]
      Link: https://lore.kernel.org/all/Yr60tWxN4P568x3W@worktop.programming.kicks-ass.net/ [2]
      Link: https://lore.kernel.org/all/CAHk-=wjZfO9hGqJ2_hGQG3U_XzSh9_XaXze=HgPdvJbgrvASfA@mail.gmail.com/ [3]
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Alexander Aring <aahringo@redhat.com>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4a557a5d
    • Linus Torvalds's avatar
      Merge tag 'xfs-5.19-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 20855e4c
      Linus Torvalds authored
      Pull xfs fixes from Darrick Wong:
       "This fixes some stalling problems and corrects the last of the
        problems (I hope) observed during testing of the new atomic xattr
        update feature.
      
         - Fix statfs blocking on background inode gc workers
      
         - Fix some broken inode lock assertion code
      
         - Fix xattr leaf buffer leaks when cancelling a deferred xattr update
           operation
      
         - Clean up xattr recovery to make it easier to understand.
      
         - Fix xattr leaf block verifiers tripping over empty blocks.
      
         - Remove complicated and error prone xattr leaf block bholding mess.
      
         - Fix a bug where an rt extent crossing EOF was treated as "posteof"
           blocks and cleaned unnecessarily.
      
         - Fix a UAF when log shutdown races with unmount"
      
      * tag 'xfs-5.19-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: prevent a UAF when log IO errors race with unmount
        xfs: dont treat rt extents beyond EOF as eofblocks to be cleared
        xfs: don't hold xattr leaf buffers across transaction rolls
        xfs: empty xattr leaf header blocks are not corruption
        xfs: clean up the end of xfs_attri_item_recover
        xfs: always free xattri_leaf_bp when cancelling a deferred op
        xfs: use invalidate_lock to check the state of mmap_lock
        xfs: factor out the common lock flags assert
        xfs: introduce xfs_inodegc_push()
        xfs: bound maximum wait time for inodegc work
      20855e4c
  15. 02 Jul, 2022 4 commits
    • Linus Torvalds's avatar
      Merge tag 'nfsd-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux · 69cb6c65
      Linus Torvalds authored
      Pull nfsd fixes from Chuck Lever:
       "Notable regression fixes:
      
         - Fix NFSD crash during NFSv4.2 READ_PLUS operation
      
         - Fix incorrect status code returned by COMMIT operation"
      
      * tag 'nfsd-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux:
        SUNRPC: Fix READ_PLUS crasher
        NFSD: restore EINVAL error translation in nfsd_commit()
      69cb6c65
    • Linus Torvalds's avatar
      Merge tag 'for-5.19/parisc-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 34074da5
      Linus Torvalds authored
      Pull parisc architecture fixes from Helge Deller:
       "Two important fixes for bugs in code which was added in 5.18:
      
         - Fix userspace signal failures on 32-bit kernel due to a bug in vDSO
      
         - Fix 32-bit load-word unalignment exception handler which returned
           wrong values"
      
      * tag 'for-5.19/parisc-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Fix vDSO signal breakage on 32-bit kernel
        parisc/unaligned: Fix emulate_ldw() breakage
      34074da5
    • Helge Deller's avatar
      parisc: Fix vDSO signal breakage on 32-bit kernel · aa78fa90
      Helge Deller authored
      Addition of vDSO support for parisc in kernel v5.18 suddenly broke glibc
      signal testcases on a 32-bit kernel.
      
      The trampoline code (sigtramp.S) which is mapped into userspace includes
      an offset to the context data on the stack, which is used by gdb and
      glibc to get access to registers.
      
      In a 32-bit kernel we used by mistake the offset into the compat context
      (which is valid on a 64-bit kernel only) instead of the offset into the
      "native" 32-bit context.
      Reported-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Tested-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Fixes: 	df24e178 ("parisc: Add vDSO support")
      CC: stable@vger.kernel.org # 5.18
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      aa78fa90
    • Linus Torvalds's avatar
      Merge tag 'perf-tools-fixes-for-v5.19-2022-07-02' of... · bb7c5126
      Linus Torvalds authored
      Merge tag 'perf-tools-fixes-for-v5.19-2022-07-02' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
      
      Pull perf tools fixes from Arnaldo Carvalho de Melo:
      
       - BPF program info linear (BPIL) data is accessed assuming 64-bit
         alignment resulting in undefined behavior as the data is just byte
         aligned. Fix it, Found using -fsanitize=undefined.
      
       - Fix 'perf offcpu' build on old kernels wrt task_struct's
         state/__state field.
      
       - Fix perf_event_attr.sample_type setting on the 'offcpu-time' event
         synthesized by the 'perf offcpu' tool.
      
       - Don't bail out when synthesizing PERF_RECORD_ events for pre-existing
         threads when one goes away while parsing its procfs entries.
      
       - Don't sort the task scan result from /proc, its not needed and
         introduces bugs when the main thread isn't the first one to be
         processed.
      
       - Fix uninitialized 'offset' variable on aarch64 in the unwind code.
      
       - Sync KVM headers with the kernel sources.
      
      * tag 'perf-tools-fixes-for-v5.19-2022-07-02' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
        perf synthetic-events: Ignore dead threads during event synthesis
        perf synthetic-events: Don't sort the task scan result from /proc
        perf unwind: Fix unitialized 'offset' variable on aarch64
        tools headers UAPI: Sync linux/kvm.h with the kernel sources
        perf bpf: 8 byte align bpil data
        tools kvm headers arm64: Update KVM headers from the kernel sources
        perf offcpu: Accept allowed sample types only
        perf offcpu: Fix build failure on old kernels
      bb7c5126