1. 15 Jul, 2022 6 commits
    • Steven Rostedt (Google)'s avatar
      tracing/brcm: Use the new __vstring() helper · b6d18ab3
      Steven Rostedt (Google) authored
      Instead of open coding a __dynamic_array() with a fixed length (which
      defeats the purpose of the dynamic array in the first place). Use the new
      __vstring() helper that will use a va_list and only write enough of the
      string into the ring buffer that is needed.
      
      Link: https://lkml.kernel.org/r/20220705224749.622796175@goodmis.org
      
      Cc: Arend van Spriel <aspriel@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Franky Lin <franky.lin@broadcom.com>
      Cc: Hante Meuleman <hante.meuleman@broadcom.com>
      Cc: Kalle Valo <kvalo@kernel.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: linux-wireless@vger.kernel.org
      Cc: brcm80211-dev-list.pdl@broadcom.com
      Cc: SHA-cyfmac-dev-list@infineon.com
      Cc: netdev@vger.kernel.org
      Acked-by: default avatarKalle Valo <kvalo@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      b6d18ab3
    • Steven Rostedt (Google)'s avatar
      tracing/ath: Use the new __vstring() helper · c01406f8
      Steven Rostedt (Google) authored
      Instead of open coding a __dynamic_array() with a fixed length (which
      defeats the purpose of the dynamic array in the first place). Use the new
      __vstring() helper that will use a va_list and only write enough of the
      string into the ring buffer that is needed.
      
      Link: https://lkml.kernel.org/r/20220705224749.430339634@goodmis.org
      
      Cc: Kalle Valo <kvalo@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: ath10k@lists.infradead.org
      Cc: linux-wireless@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: ath11k@lists.infradead.org
      Acked-by: default avatarKalle Valo <kvalo@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      c01406f8
    • Steven Rostedt (Google)'s avatar
      tracing/IB/hfi1: Use the new __vstring() helper · 8d7f5df0
      Steven Rostedt (Google) authored
      Instead of open coding a __dynamic_array() with a fixed length (which
      defeats the purpose of the dynamic array in the first place). Use the new
      __vstring() helper that will use a va_list and only write enough of the
      string into the ring buffer that is needed.
      
      Link: https://lkml.kernel.org/r/20220705224749.239494531@goodmis.org
      
      Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: linux-rdma@vger.kernel.org
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      8d7f5df0
    • Steven Rostedt (Google)'s avatar
      tracing/events: Add __vstring() and __assign_vstr() helper macros · 0563231f
      Steven Rostedt (Google) authored
      There's several places that open code the following logic:
      
        TP_STRUCT__entry(__dynamic_array(char, msg, MSG_MAX)),
        TP_fast_assign(vsnprintf(__get_str(msg), MSG_MAX, vaf->fmt, *vaf->va);)
      
      To load a string created by variable array va_list.
      
      The main issue with this approach is that "MSG_MAX" usage in the
      __dynamic_array() portion. That actually just reserves the MSG_MAX in the
      event, and even wastes space because there's dynamic meta data also saved
      in the event to denote the offset and size of the dynamic array. It would
      have been better to just use a static __array() field.
      
      Instead, create __vstring() and __assign_vstr() that work like __string
      and __assign_str() but instead of taking a destination string to copy,
      take a format string and a va_list pointer and fill in the values.
      
      It uses the helper:
      
       #define __trace_event_vstr_len(fmt, va)		\
       ({							\
      	va_list __ap;					\
      	int __ret;					\
      							\
      	va_copy(__ap, *(va));				\
      	__ret = vsnprintf(NULL, 0, fmt, __ap) + 1;	\
      	va_end(__ap);					\
      							\
      	min(__ret, TRACE_EVENT_STR_MAX);		\
       })
      
      To figure out the length to store the string. It may be slightly slower as
      it needs to run the vsnprintf() twice, but it now saves space on the ring
      buffer.
      
      Link: https://lkml.kernel.org/r/20220705224749.053570613@goodmis.org
      
      Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: Kalle Valo <kvalo@kernel.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: Arend van Spriel <aspriel@gmail.com>
      Cc: Franky Lin <franky.lin@broadcom.com>
      Cc: Hante Meuleman <hante.meuleman@broadcom.com>
      Cc: Gregory Greenman <gregory.greenman@intel.com>
      Cc: Peter Chen <peter.chen@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Mathias Nyman <mathias.nyman@intel.com>
      Cc: Chunfeng Yun <chunfeng.yun@mediatek.com>
      Cc: Bin Liu <b-liu@ti.com>
      Cc: Marek Lindner <mareklindner@neomailbox.ch>
      Cc: Simon Wunderlich <sw@simonwunderlich.de>
      Cc: Antonio Quartulli <a@unstable.cc>
      Cc: Sven Eckelmann <sven@narfation.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Jim Cromie <jim.cromie@gmail.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      0563231f
    • Steven Rostedt (Google)'s avatar
      neighbor: tracing: Have neigh_create event use __string() · 43b2aef3
      Steven Rostedt (Google) authored
      The dev field of the neigh_create event uses __dynamic_array() with a
      fixed size, which defeats the purpose of __dynamic_array(). Looking at the
      logic, as it already uses __assign_str(), just use the same logic in
      __string to create the size needed. It appears that because "dev" can be
      NULL, it needs the check. But __string() can have the same checks as
      __assign_str() so use them there too.
      
      Link: https://lkml.kernel.org/r/20220705183741.35387e3f@rorschach.local.home
      
      Cc: David Ahern <dsahern@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      43b2aef3
    • Steven Rostedt (Google)'s avatar
      tracing/ipv4/ipv6: Use static array for name field in fib*_lookup_table event · fca8300f
      Steven Rostedt (Google) authored
      The fib_lookup_table and fib6_lookup_table events declare name as a
      dynamic_array, but also give it a fixed size, which defeats the purpose of
      the dynamic array, especially since the dynamic array also includes meta
      data in the event to specify its size.
      
      Since the size of the name is at most 16 bytes (defined by IFNAMSIZ),
      it is not worth spending the effort to determine the size of the string.
      
      Just use a fixed size array and copy into it. This will save 4 bytes that
      are used for the meta data that saves the size and position of a dynamic
      array, and even slightly speed up the event processing.
      
      Link: https://lkml.kernel.org/r/20220704091436.3705edbf@rorschach.local.home
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      fca8300f
  2. 14 Jul, 2022 1 commit
  3. 12 Jul, 2022 8 commits
  4. 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
  5. 02 Jul, 2022 8 commits
  6. 01 Jul, 2022 13 commits