1. 01 Aug, 2022 2 commits
    • Yury Norov's avatar
      lib/nodemask: inline next_node_in() and node_random() · 36d4b36b
      Yury Norov authored
      The functions are pretty thin wrappers around find_bit engine, and
      keeping them in c-file prevents compiler from small_const_nbits()
      optimization, which must take place for all systems with MAX_NUMNODES
      less than BITS_PER_LONG (default is 16 for me).
      
      Moving them to header file doesn't blow up the kernel size:
      add/remove: 1/2 grow/shrink: 9/5 up/down: 968/-88 (880)
      
      CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: Michael Ellerman <mpe@ellerman.id.au>
      CC: Paul Mackerras <paulus@samba.org>
      CC: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      CC: Stephen Rothwell <sfr@canb.auug.org.au>
      CC: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      36d4b36b
    • Yury Norov's avatar
      powerpc: drop dependency on <asm/machdep.h> in archrandom.h · 3e731203
      Yury Norov authored
      archrandom.h includes <asm/machdep.h> to refer ppc_md. This causes
      circular header dependency, if generic nodemask.h  includes random.h:
      
      In file included from include/linux/cred.h:16,
                       from include/linux/seq_file.h:13,
                       from arch/powerpc/include/asm/machdep.h:6,
                       from arch/powerpc/include/asm/archrandom.h:5,
                       from include/linux/random.h:109,
                       from include/linux/nodemask.h:97,
                       from include/linux/list_lru.h:12,
                       from include/linux/fs.h:13,
                       from include/linux/compat.h:17,
                       from arch/powerpc/kernel/asm-offsets.c:12:
      include/linux/sched.h:1203:9: error: unknown type name 'nodemask_t'
       1203 |         nodemask_t                      mems_allowed;
            |         ^~~~~~~~~~
      
      Fix it by removing <asm/machdep.h> dependency from archrandom.h
      
      Now as arch_get_random_seed_long() moved to c-file, and not exported,
      it's not available for modules. As Michael Ellerman says:
      
        I think we actually don't need it exported to modules, I think it's
        a private detail of the RNG <-> architecture interface, not something
        that modules should be calling.
      
      CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: Michael Ellerman <mpe@ellerman.id.au>
      CC: Paul Mackerras <paulus@samba.org>
      CC: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      CC: Stephen Rothwell <sfr@canb.auug.org.au>
      CC: linuxppc-dev@lists.ozlabs.org
      Suggested-by: Michael Ellerman <mpe@ellerman.id.au> (for non-exporting)
      Acked-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      3e731203
  2. 15 Jul, 2022 9 commits
  3. 14 Jul, 2022 2 commits
  4. 13 Jul, 2022 1 commit
    • Alexander Lobakin's avatar
      iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) · b0b0b77e
      Alexander Lobakin authored
      KASAN reports:
      
      [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
      [    4.676149][    T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0
      [    4.683454][    T0]
      [    4.685638][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838 #1
      [    4.694331][    T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016
      [    4.703196][    T0] Call Trace:
      [    4.706334][    T0]  <TASK>
      [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
      
      after converting the type of the first argument (@nr, bit number)
      of arch_test_bit() from `long` to `unsigned long`[0].
      
      Under certain conditions (for example, when ACPI NUMA is disabled
      via command line), pxm_to_node() can return %NUMA_NO_NODE (-1).
      It is valid 'magic' number of NUMA node, but not valid bit number
      to use in bitops.
      node_online() eventually descends to test_bit() without checking
      for the input, assuming it's on caller side (which might be good
      for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads
      to an insane array index when calculating bit position in memory.
      
      For now, add an explicit check for @node being not %NUMA_NO_NODE
      before calling test_bit(). The actual logics didn't change here
      at all.
      
      [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d
      
      Fixes: ee34b32d ("dmar: support for parsing Remapping Hardware Static Affinity structure")
      Cc: stable@vger.kernel.org # 2.6.33+
      Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      b0b0b77e
  5. 12 Jul, 2022 2 commits
  6. 01 Jul, 2022 9 commits
    • Alexander Lobakin's avatar
      lib: test_bitmap: add compile-time optimization/evaluations assertions · dc34d503
      Alexander Lobakin authored
      Add a function to the bitmap test suite, which will ensure that
      compilers are able to evaluate operations performed by the
      bitops/bitmap helpers to compile-time constants when all of the
      arguments are compile-time constants as well, or trigger a build
      bug otherwise. This should work on all architectures and all the
      optimization levels supported by Kbuild.
      The function doesn't perform any runtime tests and gets optimized
      out to nothing after passing the build assertions.
      Unfortunately, Clang for s390 is currently broken (up to the latest
      Git snapshots) -- see the comment in the code -- so for now there's
      a small workaround for it which doesn't alter the logics. Hope we'll
      be able to remove it one day (bugreport is on its way).
      Suggested-by: default avatarYury Norov <yury.norov@gmail.com>
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      dc34d503
    • Alexander Lobakin's avatar
      bitmap: don't assume compiler evaluates small mem*() builtins calls · 3e7e5baa
      Alexander Lobakin authored
      Intel kernel bot triggered the build bug on ARC architecture that
      in fact is as follows:
      
      	DECLARE_BITMAP(bitmap, BITS_PER_LONG);
      
      	bitmap_clear(bitmap, 0, BITS_PER_LONG);
      	BUILD_BUG_ON(!__builtin_constant_p(*bitmap));
      
      which can be expanded to:
      
      	unsigned long bitmap[1];
      
      	memset(bitmap, 0, sizeof(*bitmap));
      	BUILD_BUG_ON(!__builtin_constant_p(*bitmap));
      
      In most cases, a compiler is able to expand small/simple mem*()
      calls to simple assignments or bitops, in this case that would mean:
      
      	unsigned long bitmap[1] = { 0 };
      
      	BUILD_BUG_ON(!__builtin_constant_p(*bitmap));
      
      and on most architectures this works, but not on ARC, despite having
      -O3 for every build.
      So, to make this work, in case when the last bit to modify is still
      within the first long (small_const_nbits()), just use plain
      assignments for the rest of bitmap_*() functions which still use
      mem*(), but didn't receive such compile-time optimizations yet.
      This doesn't have the same coverage as compilers provide, but at
      least something to start:
      
      text: add/remove: 3/7 grow/shrink: 43/78 up/down: 1848/-3370 (-1546)
      data: add/remove: 1/11 grow/shrink: 0/8 up/down: 4/-356 (-352)
      
      notably cpumask_*() family when NR_CPUS <= BITS_PER_LONG:
      
      netif_get_num_default_rss_queues              38       4     -34
      cpumask_copy                                  90       -     -90
      cpumask_clear                                146       -    -146
      
      and the abovementioned assertion started passing.
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      3e7e5baa
    • Alexander Lobakin's avatar
      net/ice: fix initializing the bitmap in the switch code · 2f7ee2a7
      Alexander Lobakin authored
      Kbuild spotted the following bug during the testing of one of
      the optimizations:
      
      In file included from include/linux/cpumask.h:12,
      [...]
                      from drivers/net/ethernet/intel/ice/ice_switch.c:4:
      drivers/net/ethernet/intel/ice/ice_switch.c: In function 'ice_find_free_recp_res_idx.constprop':
      include/linux/bitmap.h:447:22: warning: 'possible_idx[0]' is used uninitialized [-Wuninitialized]
        447 |                 *map |= GENMASK(start + nbits - 1, start);
            |                      ^~
      In file included from drivers/net/ethernet/intel/ice/ice.h:7,
                       from drivers/net/ethernet/intel/ice/ice_lib.h:7,
                       from drivers/net/ethernet/intel/ice/ice_switch.c:4:
      drivers/net/ethernet/intel/ice/ice_switch.c:4929:24: note: 'possible_idx[0]' was declared here
       4929 |         DECLARE_BITMAP(possible_idx, ICE_MAX_FV_WORDS);
            |                        ^~~~~~~~~~~~
      include/linux/types.h:11:23: note: in definition of macro 'DECLARE_BITMAP'
         11 |         unsigned long name[BITS_TO_LONGS(bits)]
            |                       ^~~~
      
      %ICE_MAX_FV_WORDS is 48, so bitmap_set() here was initializing only
      48 bits, leaving a junk in the rest 16.
      It was previously hidden due to that filling 48 bits makes
      bitmap_set() call external __bitmap_set(), but after making it use
      plain bit arithmetics on small bitmaps, compilers started seeing
      the issue. It was still working because those 16 weren't used
      anywhere anyhow.
      bitmap_{clear,set}() are not really intended to initialize bitmaps,
      rather to modify already initialized ones, as they don't do anything
      past the passed number of bits. The correct function to do this in
      that particular case is bitmap_fill(), so use it here. It will do
      `*possible_idx = ~0UL` instead of `*possible_idx |= GENMASK(47, 0)`,
      not leaving anything in an undefined state.
      
      Fixes: fd2a6b71 ("ice: create advanced switch recipe")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      2f7ee2a7
    • Alexander Lobakin's avatar
      bitops: let optimize out non-atomic bitops on compile-time constants · b03fc117
      Alexander Lobakin authored
      Currently, many architecture-specific non-atomic bitop
      implementations use inline asm or other hacks which are faster or
      more robust when working with "real" variables (i.e. fields from
      the structures etc.), but the compilers have no clue how to optimize
      them out when called on compile-time constants. That said, the
      following code:
      
      	DECLARE_BITMAP(foo, BITS_PER_LONG) = { }; // -> unsigned long foo[1];
      	unsigned long bar = BIT(BAR_BIT);
      	unsigned long baz = 0;
      
      	__set_bit(FOO_BIT, foo);
      	baz |= BIT(BAZ_BIT);
      
      	BUILD_BUG_ON(!__builtin_constant_p(test_bit(FOO_BIT, foo));
      	BUILD_BUG_ON(!__builtin_constant_p(bar & BAR_BIT));
      	BUILD_BUG_ON(!__builtin_constant_p(baz & BAZ_BIT));
      
      triggers the first assertion on x86_64, which means that the
      compiler is unable to evaluate it to a compile-time initializer
      when the architecture-specific bitop is used even if it's obvious.
      In order to let the compiler optimize out such cases, expand the
      bitop() macro to use the "constant" C non-atomic bitop
      implementations when all of the arguments passed are compile-time
      constants, which means that the result will be a compile-time
      constant as well, so that it produces more efficient and simple
      code in 100% cases, comparing to the architecture-specific
      counterparts.
      
      The savings are architecture, compiler and compiler flags dependent,
      for example, on x86_64 -O2:
      
      GCC 12: add/remove: 78/29 grow/shrink: 332/525 up/down: 31325/-61560 (-30235)
      LLVM 13: add/remove: 79/76 grow/shrink: 184/537 up/down: 55076/-141892 (-86816)
      LLVM 14: add/remove: 10/3 grow/shrink: 93/138 up/down: 3705/-6992 (-3287)
      
      and ARM64 (courtesy of Mark):
      
      GCC 11: add/remove: 92/29 grow/shrink: 933/2766 up/down: 39340/-82580 (-43240)
      LLVM 14: add/remove: 21/11 grow/shrink: 620/651 up/down: 12060/-15824 (-3764)
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Reviewed-by: default avatarMarco Elver <elver@google.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      b03fc117
    • Alexander Lobakin's avatar
      bitops: wrap non-atomic bitops with a transparent macro · e69eb9c4
      Alexander Lobakin authored
      In preparation for altering the non-atomic bitops with a macro, wrap
      them in a transparent definition. This requires prepending one more
      '_' to their names in order to be able to do that seamlessly. It is
      a simple change, given that all the non-prefixed definitions are now
      in asm-generic.
      sparc32 already has several triple-underscored functions, so I had
      to rename them ('___' -> 'sp32_').
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Reviewed-by: default avatarMarco Elver <elver@google.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      e69eb9c4
    • Alexander Lobakin's avatar
      bitops: define const_*() versions of the non-atomics · bb7379bf
      Alexander Lobakin authored
      Define const_*() variants of the non-atomic bitops to be used when
      the input arguments are compile-time constants, so that the compiler
      will be always able to resolve those to compile-time constants as
      well. Those are mostly direct aliases for generic_*() with one
      exception for const_test_bit(): the original one is declared
      atomic-safe and thus doesn't discard the `volatile` qualifier, so
      in order to let optimize code, define it separately disregarding
      the qualifier.
      Add them to the compile-time type checks as well just in case.
      Suggested-by: default avatarMarco Elver <elver@google.com>
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Reviewed-by: default avatarMarco Elver <elver@google.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      bb7379bf
    • Alexander Lobakin's avatar
      bitops: unify non-atomic bitops prototypes across architectures · 0e862838
      Alexander Lobakin authored
      Currently, there is a mess with the prototypes of the non-atomic
      bitops across the different architectures:
      
      ret	bool, int, unsigned long
      nr	int, long, unsigned int, unsigned long
      addr	volatile unsigned long *, volatile void *
      
      Thankfully, it doesn't provoke any bugs, but can sometimes make
      the compiler angry when it's not handy at all.
      Adjust all the prototypes to the following standard:
      
      ret	bool				retval can be only 0 or 1
      nr	unsigned long			native; signed makes no sense
      addr	volatile unsigned long *	bitmaps are arrays of ulongs
      
      Next, some architectures don't define 'arch_' versions as they don't
      support instrumentation, others do. To make sure there is always the
      same set of callables present and to ease any potential future
      changes, make them all follow the rule:
       * architecture-specific files define only 'arch_' versions;
       * non-prefixed versions can be defined only in asm-generic files;
      and place the non-prefixed definitions into a new file in
      asm-generic to be included by non-instrumented architectures.
      
      Finally, add some static assertions in order to prevent people from
      making a mess in this room again.
      I also used the %__always_inline attribute consistently, so that
      they always get resolved to the actual operations.
      Suggested-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarYury Norov <yury.norov@gmail.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      0e862838
    • Alexander Lobakin's avatar
      bitops: always define asm-generic non-atomic bitops · 21bb8af5
      Alexander Lobakin authored
      Move generic non-atomic bitops from the asm-generic header which
      gets included only when there are no architecture-specific
      alternatives, to a separate independent file to make them always
      available.
      Almost no actual code changes, only one comment added to
      generic_test_bit() saying that it's an atomic operation itself
      and thus `volatile` must always stay there with no cast-aways.
      
      Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # comment
      Suggested-by: Marco Elver <elver@google.com> # reference to kernel-doc
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarMarco Elver <elver@google.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      21bb8af5
    • Alexander Lobakin's avatar
      ia64, processor: fix -Wincompatible-pointer-types in ia64_get_irr() · e5a16a5c
      Alexander Lobakin authored
      test_bit(), as any other bitmap op, takes `unsigned long *` as a
      second argument (pointer to the actual bitmap), as any bitmap
      itself is an array of unsigned longs. However, the ia64_get_irr()
      code passes a ref to `u64` as a second argument.
      This works with the ia64 bitops implementation due to that they
      have `void *` as the second argument and then cast it later on.
      This works with the bitmap API itself due to that `unsigned long`
      has the same size on ia64 as `u64` (`unsigned long long`), but
      from the compiler PoV those two are different.
      Define @irr as `unsigned long` to fix that. That implies no
      functional changes. Has been hidden for 16 years!
      
      Fixes: a5878691 ("[IA64] avoid broken SAL_CACHE_FLUSH implementations")
      Cc: stable@vger.kernel.org # 2.6.16+
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarYury Norov <yury.norov@gmail.com>
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      e5a16a5c
  7. 24 Jun, 2022 1 commit
  8. 19 Jun, 2022 11 commits
    • Linus Torvalds's avatar
      Linux 5.19-rc3 · a111daf0
      Linus Torvalds authored
      a111daf0
    • Linus Torvalds's avatar
      Merge tag 'x86-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 05c6ca85
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
      
       - Make RESERVE_BRK() work again with older binutils. The recent
         'simplification' broke that.
      
       - Make early #VE handling increment RIP when successful.
      
       - Make the #VE code consistent vs. the RIP adjustments and add
         comments.
      
       - Handle load_unaligned_zeropad() across page boundaries correctly in
         #VE when the second page is shared.
      
      * tag 'x86-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/tdx: Handle load_unaligned_zeropad() page-cross to a shared page
        x86/tdx: Clarify RIP adjustments in #VE handler
        x86/tdx: Fix early #VE handling
        x86/mm: Fix RESERVE_BRK() for older binutils
      05c6ca85
    • Linus Torvalds's avatar
      Merge tag 'objtool-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 5d770f11
      Linus Torvalds authored
      Pull build tooling updates from Thomas Gleixner:
      
       - Remove obsolete CONFIG_X86_SMAP reference from objtool
      
       - Fix overlapping text section failures in faddr2line for real
      
       - Remove OBJECT_FILES_NON_STANDARD usage from x86 ftrace and replace it
         with finegrained annotations so objtool can validate that code
         correctly.
      
      * tag 'objtool-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/ftrace: Remove OBJECT_FILES_NON_STANDARD usage
        faddr2line: Fix overlapping text section failures, the sequel
        objtool: Fix obsolete reference to CONFIG_X86_SMAP
      5d770f11
    • Linus Torvalds's avatar
      Merge tag 'sched-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 727c3991
      Linus Torvalds authored
      Pull scheduler fix from Thomas Gleixner:
       "A single scheduler fix plugging a race between sched_setscheduler()
        and balance_push().
      
        sched_setscheduler() spliced the balance callbacks accross a lock
        break which makes it possible for an interleaving schedule() to
        observe an empty list"
      
      * tag 'sched-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched: Fix balance_push() vs __sched_setscheduler()
      727c3991
    • Linus Torvalds's avatar
      Merge tag 'locking-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 4afb6515
      Linus Torvalds authored
      Pull lockdep fix from Thomas Gleixner:
       "A RT fix for lockdep.
      
        lockdep invokes prandom_u32() to create cookies. This worked until
        prandom_u32() was switched to the real random generator, which takes a
        spinlock for extraction, which does not work on RT when invoked from
        atomic contexts.
      
        lockdep has no requirement for real random numbers and it turns out
        sched_clock() is good enough to create the cookie. That works
        everywhere and is faster"
      
      * tag 'locking-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        locking/lockdep: Use sched_clock() for random numbers
      4afb6515
    • Linus Torvalds's avatar
      Merge tag 'irq-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 36da9f5f
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "A set of interrupt subsystem updates:
      
        Core:
      
         - Ensure runtime power management for chained interrupts
      
        Drivers:
      
         - A collection of OF node refcount fixes
      
         - Unbreak MIPS uniprocessor builds
      
         - Fix xilinx interrupt controller Kconfig dependencies
      
         - Add a missing compatible string to the Uniphier driver"
      
      * tag 'irq-urgent-2022-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip/loongson-liointc: Use architecture register to get coreid
        irqchip/uniphier-aidet: Add compatible string for NX1 SoC
        dt-bindings: interrupt-controller/uniphier-aidet: Add bindings for NX1 SoC
        irqchip/realtek-rtl: Fix refcount leak in map_interrupts
        irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions
        irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions
        irqchip/apple-aic: Fix refcount leak in aic_of_ic_init
        irqchip/apple-aic: Fix refcount leak in build_fiq_affinity
        irqchip/gic/realview: Fix refcount leak in realview_gic_of_init
        irqchip/xilinx: Remove microblaze+zynq dependency
        genirq: PM: Use runtime PM for chained interrupts
      36da9f5f
    • Linus Torvalds's avatar
      Merge tag 'char-misc-5.19-rc3-take2' of... · bc94632c
      Linus Torvalds authored
      Merge tag 'char-misc-5.19-rc3-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
      
      Pull char/misc driver fixes for real from Greg KH:
       "Let's tag the proper branch this time...
      
        Here are some small char/misc driver fixes for 5.19-rc3 that resolve
        some reported issues.
      
        They include:
      
         - mei driver fixes
      
         - comedi driver fix
      
         - rtsx build warning fix
      
         - fsl-mc-bus driver fix
      
        All of these have been in linux-next for a while with no reported
        issues"
      
      This is what the merge in commit f0ec9c65 _should_ have merged, but
      Greg fat-fingered the pull request and I got some small changes from
      linux-next instead there. Credit to Nathan Chancellor for eagle-eyes.
      
      Link: https://lore.kernel.org/all/Yqywy+Md2AfGDu8v@dev-arch.thelio-3990X/
      
      * tag 'char-misc-5.19-rc3-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
        bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()
        mei: me: add raptor lake point S DID
        mei: hbm: drop capability response on early shutdown
        mei: me: set internal pg flag to off on hardware reset
        misc: rtsx: Fix clang -Wsometimes-uninitialized in rts5261_init_from_hw()
        comedi: vmk80xx: fix expression for tx buffer size
      bc94632c
    • Linus Torvalds's avatar
      Merge tag 'i2c-for-5.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · ee4eb6ee
      Linus Torvalds authored
      Pull i2c fixes from Wolfram Sang:
       "MAINTAINERS rectifications and a few minor driver fixes"
      
      * tag 'i2c-for-5.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        i2c: mediatek: Fix an error handling path in mtk_i2c_probe()
        i2c: designware: Use standard optional ref clock implementation
        MAINTAINERS: core DT include belongs to core
        MAINTAINERS: add include/dt-bindings/i2c to I2C SUBSYSTEM HOST DRIVERS
        i2c: npcm7xx: Add check for platform_driver_register
        MAINTAINERS: Update Synopsys DesignWare I2C to Supported
      ee4eb6ee
    • Linus Torvalds's avatar
      Merge tag 'xfs-5.19-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 063232b6
      Linus Torvalds authored
      Pull xfs fixes from Darrick Wong:
       "There's not a whole lot this time around (I'm still on vacation) but
        here are some important fixes for new features merged in -rc1:
      
         - Fix a bug where inode flag changes would accidentally drop nrext64
      
         - Fix a race condition when toggling LARP mode"
      
      * tag 'xfs-5.19-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: preserve DIFLAG2_NREXT64 when setting other inode attributes
        xfs: fix variable state usage
        xfs: fix TOCTOU race involving the new logged xattrs control knob
      063232b6
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 354c6e07
      Linus Torvalds authored
      Pull ext4 fixes from Ted Ts'o:
       "Fix a variety of bugs, many of which were found by folks using fuzzing
        or error injection.
      
        Also fix up how test_dummy_encryption mount option is handled for the
        new mount API.
      
        Finally, fix/cleanup a number of comments and ext4 Documentation
        files"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: fix a doubled word "need" in a comment
        ext4: add reserved GDT blocks check
        ext4: make variable "count" signed
        ext4: correct the judgment of BUG in ext4_mb_normalize_request
        ext4: fix bug_on ext4_mb_use_inode_pa
        ext4: fix up test_dummy_encryption handling for new mount API
        ext4: use kmemdup() to replace kmalloc + memcpy
        ext4: fix super block checksum incorrect after mount
        ext4: improve write performance with disabled delalloc
        ext4: fix warning when submitting superblock in ext4_commit_super()
        ext4, doc: remove unnecessary escaping
        ext4: fix incorrect comment in ext4_bio_write_page()
        fs: fix jbd2_journal_try_to_free_buffers() kernel-doc comment
      354c6e07
    • Linus Torvalds's avatar
      Merge tag '5.19-rc2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6 · ace2045e
      Linus Torvalds authored
      Pull cifs client fixes from Steve French:
       "Two cifs debugging improvements - one found to deal with debugging a
        multichannel problem and one for a recent fallocate issue
      
        This does include the two larger multichannel reconnect (dynamically
        adjusting interfaces on reconnect) patches, because we recently found
        an additional problem with multichannel to one server type that I want
        to include at the same time"
      
      * tag '5.19-rc2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
        cifs: when a channel is not found for server, log its connection id
        smb3: add trace point for SMB2_set_eof
      ace2045e
  9. 18 Jun, 2022 3 commits