Allow computation of thread map index from a PID.
Note, with a 'struct perf_cpu_map' the sorted nature allows for a binary
search to compute the index which isn't currently possible with a
'struct perf_thread_map' as they aren't guaranteed sorted.
Signed-off-by: Ian Rogers <irogers@google.com>
Acked-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250519195148.1708988-3-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf_thread_map__nr() returns length 1 if the perf_thread_map is NULL,
meaning index 0 is valid.
When perf_thread_map__pid() of index 0 is read then return the expected
"any" -1 value.
Assert this is only done for index 0.
Signed-off-by: Ian Rogers <irogers@google.com>
Acked-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250519195148.1708988-2-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Bunch of IBS kernel fixes went in v6.15-rc1 [1].
The amd-ibs-period test will fail without those kernel patches.
Skip the test on system running kernel older than v6.15 to distinguish
genuine new failures vs known failure due to old kernel.
Since all the related IBS fixes went in -rc1 itself, the ">= 6.15" check
will work for any custom compiled v6.15-* kernel as well.
Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Suggested-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Closes: https://lore.kernel.org/r/aCfuGXUnNIbnYo_r@x1
Link: https://lore.kernel.org/r/20250115054438.1021-1-ravi.bangoria@amd.com [1]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add thread safety annotations for comm_list and add locking for two
instances where the list is accessed without the lock held (in
contradiction to ____thread__set_comm()).
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: Bill Wendling <morbo@google.com>
Cc: Chaitanya S Prakash <chaitanyas.prakash@arm.com>
Cc: Fei Lang <langfei@huawei.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Justin Stitt <justinstitt@google.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Brennan <stephen.s.brennan@oracle.com>
Link: https://lore.kernel.org/r/20250519224645.1810891-3-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add annotations used by clang's -Wthread-safety.
Fix dsos compilation errors caused by a lock of annotations.
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: Bill Wendling <morbo@google.com>
Cc: Chaitanya S Prakash <chaitanyas.prakash@arm.com>
Cc: Fei Lang <langfei@huawei.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Justin Stitt <justinstitt@google.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Brennan <stephen.s.brennan@oracle.com>
Link: https://lore.kernel.org/r/20250519224645.1810891-2-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The pattern:
```
if (x) {
lock(...)
}
block1;
if (x) {
unlock(...)
}
```
defeats clang's -Wthread-safety analysis where it complains of locks
held on one path and not another.
Add helper functions for "block1" then restructure as:
```
if (x) {
lock(...);
block1();
unlock(...);
} else {
block1();
}
```
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: Bill Wendling <morbo@google.com>
Cc: Chaitanya S Prakash <chaitanyas.prakash@arm.com>
Cc: Fei Lang <langfei@huawei.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Justin Stitt <justinstitt@google.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Brennan <stephen.s.brennan@oracle.com>
Link: https://lore.kernel.org/r/20250519224645.1810891-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The qcom_spi_check_error() function determines the errors of a previous
page read operation solely by using the cached register values in the
register read buffer. The data pointed by the 'data_buf' and the 'oob_buf'
parameters are not used for that at all.
Remove the superfluous parameters of the function along with the related
local variables to simplify the code. Also, remove the variables from the
caller functions which became unused due to the change.
Note:
Althought the similar parse_read_errors() function in the 'qcom_nand'
driver has the same parameters, but that function passes down the
pointers to check_for_erased_page() at the end of the function.
It is not clear, that a similar call is missing here, or the superfluous
parameters are simply leftovers of the development process. Nevertheless,
if additional code is needed, the parameters can be added back later.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://patch.msgid.link/20250520-qpic-snand-superfluous-params-v1-1-86dd4963e90f@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The qcom_spi_check_raw_flash_errors() function can be used to
verify the flash status after raw operations.
Move the function slightly up in the code and change the
qcom_spi_read_last_cw() function to call it instead of using
an open coded implementation of the same check.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://patch.msgid.link/20250514-qpic-snand-error-check-v1-1-c0ebd3aae72a@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Using lx-symbols during s390 early boot fails with:
Error occurred in Python: 'utf-8' codec can't decode byte 0xcb in position 0: invalid continuation byte
The reason is that s390 decompressor's startup_kernel() does not create
vmcoreinfo note, and sets vmcore_info to kernel's physical base. This
confuses get_vmcore_s390().
Fix by handling this special case. Extract vm_layout.kaslr_offset from
the kernel image in physical memory, which is placed there by the
decompressor using the __bootdata_preserved mechanism, and generate a
synthetic vmcoreinfo note from it.
Link: https://lkml.kernel.org/r/20250515155811.114392-4-iii@linux.ibm.com
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Move the code that turns off pagination into a separate function. It will
be useful later in order to prevent hangs when loading symbols for kernel
image in physical memory during s390 early boot.
Link: https://lkml.kernel.org/r/20250515155811.114392-3-iii@linux.ibm.com
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Patch series "scripts/gdb/symbols: determine KASLR offset on s390 during
early boot".
I noticed that debugging s390 early boot using the support I introduced in
commit 28939c3e99 ("scripts/gdb/symbols: determine KASLR offset on
s390") does not work.
The reason is that decompressor does not provide the vmcoreinfo note, so
KASLR offset needs to be extracted in a different way, which this series
implements. Patches 1-2 are trivial refactorings, and patch 3 is the
implementation.
This patch (of 3):
Move the code that determines the current vmlinux file into a separate
function. It will be useful later in order to analyze the kernel image in
physical memory during s390 early boot.
Link: https://lkml.kernel.org/r/20250515155811.114392-1-iii@linux.ibm.com
Link: https://lkml.kernel.org/r/20250515155811.114392-2-iii@linux.ibm.com
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
I've used several email addresses and a previous name to contribute.
Consolidate all of these to my primary email and update my name.
Link: https://lkml.kernel.org/r/20250517223237.15647-2-casey.connolly@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Since commit 013a07052a ("nilfs2: convert metadata aops from writepage
to writepages"), nilfs_mdt_write_folio can't be called from reclaim
context any more. Remove the code keyed of the wbc->for_reclaim flag,
which is now only set for writing out swap or shmem pages inside the swap
code, but never passed to file systems.
Link: https://lkml.kernel.org/r/20250508054938.15894-7-hch@lst.de
Link: https://lkml.kernel.org/r/20250516123417.6779-1-konishi.ryusuke@gmail.com
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The current allocation of VMAP stack memory is using (THREADINFO_GFP &
~__GFP_ACCOUNT) which is a complicated way of saying (GFP_KERNEL |
__GFP_ZERO):
<linux/thread_info.h>:
define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO)
<linux/gfp_types.h>:
define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
This is an unfortunate side-effect of independent changes blurring the
picture:
commit 19809c2da2 changed (THREADINFO_GFP |
__GFP_HIGHMEM) to just THREADINFO_GFP since highmem became implicit.
commit 9b6f7e163c then added stack caching
and rewrote the allocation to (THREADINFO_GFP & ~__GFP_ACCOUNT) as cached
stacks need to be accounted separately. However that code, when it
eventually accounts the memory does this:
ret = memcg_kmem_charge(vm->pages[i], GFP_KERNEL, 0)
so the memory is charged as a GFP_KERNEL allocation.
Define a unique GFP_VMAP_STACK to use
GFP_KERNEL | __GFP_ZERO and move the comment there.
Link: https://lkml.kernel.org/r/20250509-gfp-stack-v1-1-82f6f7efc210@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reported-by: Mateusz Guzik <mjguzik@gmail.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
There are two data types: "struct vm_struct" and "struct vm_stack" that
have the same local variable names: vm_stack, or vm, or s, which makes the
code confusing to read.
Change the code so the naming is consistent:
struct vm_struct is always called vm_area
struct vm_stack is always called vm_stack
One change altering vfree(vm_stack) to vfree(vm_area->addr) may look like
a semantic change but it is not: vm_area->addr points to the vm_stack.
This was done to improve readability.
[linus.walleij@linaro.org: rebased and added new users of the variable names, address review comments]
Link: https://lore.kernel.org/20240311164638.2015063-4-pasha.tatashin@soleen.com
Link: https://lkml.kernel.org/r/20250509-fork-fixes-v3-2-e6c69dd356f2@linaro.org
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Patch series "fork: Page operation cleanups in the fork code", v3.
This patchset consists of outtakes from a 1 year+ old patchset from Pasha,
which all stand on their own. See:
https://lore.kernel.org/all/20240311164638.2015063-1-pasha.tatashin@soleen.com/
These are good cleanups for readability so I split these off, rebased on
v6.15-rc1, addressed review comments and send them separately.
All mentions of dynamic stack are removed from the patchset as we have no
idea whether that will go anywhere.
This patch (of 3):
There is unneeded OR in the ifdef functions that are used to allocate and
free kernel stacks based on direct map or vmap.
Therefore, clean up by changing the order so OR is no longer needed.
[linus.walleij@linaro.org: rebased]
Link: https://lkml.kernel.org/r/20250509-fork-fixes-v3-1-e6c69dd356f2@linaro.org
Link: https://lkml.kernel.org/r/20250509-fork-fixes-v3-0-e6c69dd356f2@linaro.org
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Link: https://lore.kernel.org/20240311164638.2015063-3-pasha.tatashin@soleen.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Expose a simple counter to userspace for monitoring tools.
Link: https://lkml.kernel.org/r/20250504180831.4190860-3-max.kellermann@ionos.com
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Cc: Core Minyard <cminyard@mvista.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Joel Granados <joel.granados@kernel.org>
Cc: Kees Cook <kees@kernel.org>
Cc: Song Liu <song@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Patch series "sysfs: add counters for lockups and stalls", v2.
Commits 9db89b4111 ("exit: Expose "oops_count" to sysfs") and
8b05aa2633 ("panic: Expose "warn_count" to sysfs") added counters for
oopses and warnings to sysfs, and these two patches do the same for
hard/soft lockups and RCU stalls.
All of these counters are useful for monitoring tools to detect whether
the machine is healthy. If the kernel has experienced a lockup or a
stall, it's probably due to a kernel bug, and I'd like to detect that
quickly and easily. There is currently no way to detect that, other than
parsing dmesg. Or observing indirect effects: such as certain tasks not
responding, but then I need to observe all tasks, and it may take a while
until these effects become visible/measurable. I'd rather be able to
detect the primary cause more quickly, possibly before everything falls
apart.
This patch (of 2):
There is /proc/sys/kernel/hung_task_detect_count, /sys/kernel/warn_count
and /sys/kernel/oops_count but there is no userspace-accessible counter
for hard/soft lockups. Having this is useful for monitoring tools.
Link: https://lkml.kernel.org/r/20250504180831.4190860-1-max.kellermann@ionos.com
Link: https://lkml.kernel.org/r/20250504180831.4190860-2-max.kellermann@ionos.com
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Cc:
Cc: Core Minyard <cminyard@mvista.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Joel Granados <joel.granados@kernel.org>
Cc: Song Liu <song@kernel.org>
Cc: Kees Cook <kees@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This adds an addition layer of protection for the saved copy of dm crypt
key. Trying to access the saved copy will cause page fault.
Link: https://lkml.kernel.org/r/20250502011246.99238-9-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Pingfan Liu <kernelfans@gmail.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Jan Pazdziora <jpazdziora@redhat.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
1st kernel will build up the kernel command parameter dmcryptkeys as
similar to elfcorehdr to pass the memory address of the stored info of dm
crypt key to kdump kernel.
Link: https://lkml.kernel.org/r/20250502011246.99238-8-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Jan Pazdziora <jpazdziora@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This reverts commit 693bbf2a50 as kdump LUKS
support (CONFIG_CRASH_DM_CRYPT) depends on __set_memory_prot.
[akpm@linux-foundation.org: x86 set_memory.h needs pgtable_types.h]
Link: https://lkml.kernel.org/r/20250502011246.99238-7-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Jan Pazdziora <jpazdziora@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Crash kernel will retrieve the dm crypt keys based on the dmcryptkeys
command line parameter. When user space writes the key description to
/sys/kernel/config/crash_dm_crypt_key/restore, the crash kernel will save
the encryption keys to the user keyring. Then user space e.g.
cryptsetup's --volume-key-keyring API can use it to unlock the encrypted
device.
Link: https://lkml.kernel.org/r/20250502011246.99238-6-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Jan Pazdziora <jpazdziora@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When there are CPU and memory hot un/plugs, the dm crypt keys may need to
be reloaded again depending on the solution for crash hotplug support.
Currently, there are two solutions. One is to utilizes udev to instruct
user space to reload the kdump kernel image and initrd, elfcorehdr and etc
again. The other is to only update the elfcorehdr segment introduced in
commit 2472627561 ("crash: add generic infrastructure for crash hotplug
support").
For the 1st solution, the dm crypt keys need to be reloaded again. The
user space can write true to /sys/kernel/config/crash_dm_crypt_key/reuse
so the stored keys can be re-used.
For the 2nd solution, the dm crypt keys don't need to be reloaded.
Currently, only x86 supports the 2nd solution. If the 2nd solution gets
extended to all arches, this patch can be dropped.
Link: https://lkml.kernel.org/r/20250502011246.99238-5-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Jan Pazdziora <jpazdziora@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When the kdump kernel image and initrd are loaded, the dm crypts keys will
be read from keyring and then stored in kdump reserved memory.
Assume a key won't exceed 256 bytes thus MAX_KEY_SIZE=256 according to
"cryptsetup benchmark".
Link: https://lkml.kernel.org/r/20250502011246.99238-4-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Jan Pazdziora <jpazdziora@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
A configfs /sys/kernel/config/crash_dm_crypt_keys is provided for user
space to make the dm crypt keys persist for the kdump kernel. Take the
case of dumping to a LUKS-encrypted target as an example, here is the life
cycle of the kdump copies of LUKS volume keys,
1. After the 1st kernel loads the initramfs during boot, systemd uses
an user-input passphrase to de-crypt the LUKS volume keys or simply
TPM-sealed volume keys and then save the volume keys to specified
keyring (using the --link-vk-to-keyring API) and the keys will expire
within specified time.
2. A user space tool (kdump initramfs loader like kdump-utils) create
key items inside /sys/kernel/config/crash_dm_crypt_keys to inform
the 1st kernel which keys are needed.
3. When the kdump initramfs is loaded by the kexec_file_load
syscall, the 1st kernel will iterate created key items, save the
keys to kdump reserved memory.
4. When the 1st kernel crashes and the kdump initramfs is booted, the
kdump initramfs asks the kdump kernel to create a user key using the
key stored in kdump reserved memory by writing yes to
/sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted
device is unlocked with libcryptsetup's --volume-key-keyring API.
5. The system gets rebooted to the 1st kernel after dumping vmcore to
the LUKS encrypted device is finished
Eventually the keys have to stay in the kdump reserved memory for the
kdump kernel to unlock encrypted volumes. During this process, some
measures like letting the keys expire within specified time are desirable
to reduce security risk.
This patch assumes,
1) there are 128 LUKS devices at maximum to be unlocked thus
MAX_KEY_NUM=128.
2) a key description won't exceed 128 bytes thus KEY_DESC_MAX_LEN=128.
And here is a demo on how to interact with
/sys/kernel/config/crash_dm_crypt_keys,
# Add key #1
mkdir /sys/kernel/config/crash_dm_crypt_keys/7d26b7b4-e342-4d2d-b660-7426b0996720
# Add key #1's description
echo cryptsetup:7d26b7b4-e342-4d2d-b660-7426b0996720 > /sys/kernel/config/crash_dm_crypt_keys/description
# how many keys do we have now?
cat /sys/kernel/config/crash_dm_crypt_keys/count
1
# Add key# 2 in the same way
# how many keys do we have now?
cat /sys/kernel/config/crash_dm_crypt_keys/count
2
# the tree structure of /crash_dm_crypt_keys configfs
tree /sys/kernel/config/crash_dm_crypt_keys/
/sys/kernel/config/crash_dm_crypt_keys/
├── 7d26b7b4-e342-4d2d-b660-7426b0996720
│ └── description
├── count
├── fce2cd38-4d59-4317-8ce2-1fd24d52c46a
│ └── description
Link: https://lkml.kernel.org/r/20250502011246.99238-3-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Jan Pazdziora <jpazdziora@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Patch series "Support kdump with LUKS encryption by reusing LUKS volume
keys", v9.
LUKS is the standard for Linux disk encryption, widely adopted by users,
and in some cases, such as Confidential VMs, it is a requirement. With
kdump enabled, when the first kernel crashes, the system can boot into the
kdump/crash kernel to dump the memory image (i.e., /proc/vmcore) to a
specified target. However, there are two challenges when dumping vmcore
to a LUKS-encrypted device:
- Kdump kernel may not be able to decrypt the LUKS partition. For some
machines, a system administrator may not have a chance to enter the
password to decrypt the device in kdump initramfs after the 1st kernel
crashes; For cloud confidential VMs, depending on the policy the
kdump kernel may not be able to unseal the keys with TPM and the
console virtual keyboard is untrusted.
- LUKS2 by default use the memory-hard Argon2 key derivation function
which is quite memory-consuming compared to the limited memory reserved
for kdump. Take Fedora example, by default, only 256M is reserved for
systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
to be reserved for kdump. Note if the memory reserved for kdump can't
be used by 1st kernel i.e. an user sees ~1300M memory missing in the
1st kernel.
Besides users (at least for Fedora) usually expect kdump to work out of
the box i.e. no manual password input or custom crashkernel value is
needed. And it doesn't make sense to derivate the keys again in kdump
kernel which seems to be redundant work.
This patchset addresses the above issues by making the LUKS volume keys
persistent for kdump kernel with the help of cryptsetup's new APIs
(--link-vk-to-keyring/--volume-key-keyring). Here is the life cycle of
the kdump copies of LUKS volume keys,
1. After the 1st kernel loads the initramfs during boot, systemd
use an user-input passphrase to de-crypt the LUKS volume keys
or TPM-sealed key and then save the volume keys to specified keyring
(using the --link-vk-to-keyring API) and the key will expire within
specified time.
2. A user space tool (kdump initramfs loader like kdump-utils) create
key items inside /sys/kernel/config/crash_dm_crypt_keys to inform
the 1st kernel which keys are needed.
3. When the kdump initramfs is loaded by the kexec_file_load
syscall, the 1st kernel will iterate created key items, save the
keys to kdump reserved memory.
4. When the 1st kernel crashes and the kdump initramfs is booted, the
kdump initramfs asks the kdump kernel to create a user key using the
key stored in kdump reserved memory by writing yes to
/sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted
device is unlocked with libcryptsetup's --volume-key-keyring API.
5. The system gets rebooted to the 1st kernel after dumping vmcore to
the LUKS encrypted device is finished
After libcryptsetup saving the LUKS volume keys to specified keyring,
whoever takes this should be responsible for the safety of these copies of
keys. The keys will be saved in the memory area exclusively reserved for
kdump where even the 1st kernel has no direct access. And further more,
two additional protections are added,
- save the copy randomly in kdump reserved memory as suggested by Jan
- clear the _PAGE_PRESENT flag of the page that stores the copy as
suggested by Pingfan
This patchset only supports x86. There will be patches to support other
architectures once this patch set gets merged.
This patch (of 9):
Currently, kexec_buf is placed in order which means for the same machine,
the info in the kexec_buf is always located at the same position each time
the machine is booted. This may cause a risk for sensitive information
like LUKS volume key. Now struct kexec_buf has a new field random which
indicates it's supposed to be placed in a random position.
Note this feature is enabled only when CONFIG_CRASH_DUMP is enabled. So
it only takes effect for kdump and won't impact kexec reboot.
Link: https://lkml.kernel.org/r/20250502011246.99238-1-coxu@redhat.com
Link: https://lkml.kernel.org/r/20250502011246.99238-2-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Jan Pazdziora <jpazdziora@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
With commit 08699d20467b6 ("sched_ext: idle: Consolidate default idle
CPU selection kfuncs") allowing scx_bpf_select_cpu_dfl() to be invoked
from multiple contexts, update the test to validate that the kfunc
behaves correctly when used from ops.enqueue() and via BPF test_run.
Additionally, rename the test to enq_select_cpu, dropping "fails" from
the name, as the logic has now been inverted.
Signed-off-by: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
There is no reason to restrict scx_bpf_select_cpu_dfl() invocations to
ops.select_cpu() while allowing scx_bpf_select_cpu_and() to be used from
multiple contexts, as both provide equivalent functionality, with the
latter simply accepting an additional "allowed" cpumask.
Therefore, unify the two APIs, enabling both kfuncs to be used from
ops.select_cpu(), ops.enqueue(), and unlocked contexts (e.g., via BPF
test_run).
This allows schedulers to implement a consistent idle CPU selection
policy and helps reduce code duplication.
Signed-off-by: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Sophgo:
Add support for SG2044 TOP syscon device. The SG2044 TOP
device provide PLL clock function in its area.
Add RTC support for CV1800 series SoC. The device
is called RTC, but contains control registers of other
HW blocks in its address space, most notably of
Power-on-Reset (PoR) module, DW8051 IP (MCU core),
accompanying SRAM, hence putting it in SoC subsystem.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEdoBX2jyDC9ZCTwZjDCzASqG0i0IFAmgkDx8ACgkQDCzASqG0
i0KzNgwAuwEFXfJZYnWWraIx4+gr7v7tdjfnOz6qw/1Pp3B36R9DIgNe/dNkloGh
ZXUw7wU6FmRu+VYvA9xIbrOjp5o+VEb9lRBIlQDOXtIGwSb3agMpCgein5XwbdrF
78hfVZ95/2v/YkfIJsIWLG3S6t1XIZPiCBDKdZYSEBcXKXhtAINUm7BkO8JpLivS
5a/lV9SYPGILXFou+ca5cgEov0BaIiA/OIJxKx5kylKBAidCRG+tmQcvz1TOGfim
Kap0zjiaS6w+J7jPqIZT3lICk+24qXCrPDMObNCNov7tZMMw+bmCZntAEuleh5nu
VEnigl5Wiuv+V6xo4m4yXzklMhq/y0ESOVSW12qGTRxh/Nvv9SlKfmjEyhTzugkb
RcMojb5udrVeFdx7goT5LJwrkgc4P5ZbOZZXI2HouoU2+Ms8h0wr+LwQ2ls2v1Kr
qiQ1Q0OB3n2elBz/AZ9zLXrLXumroestml/fFqd9ZqoqSyMiK/yJWL8IcH6uOx/R
nKKwLcre
=83uO
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmguDHQACgkQmmx57+YA
GNm+Hw/7BYmkOJkpY51RrloRC+HMlJDs+oQJ+g0iii+FFh4Pfaxa6Lsgxmby0d+X
J5LsERLMJ9TSWVfS3EQkhner4O+CxXqIZjnsu1sslDpYNXb9U3xTDLaDgHnFdt0P
X7TThm92ZDJf8Z8E8Xec6zxIkJ/xfZByJZwjiTzCI2xOXjpINwZ6KCbJ9lne9cWW
qoNJ3uPAqco2lgFhxvb5qnYIk3xf5NL0ZFa51rUfuMpIJtPVLab1A8ZgllXFDVqK
7p3ayFaa5rMmJTgt/1gtpbOUKY+TvA9Ox6eMyoMvUHfG33pwSJTgW0IdbfFb74eg
AYvuN1SL47XULhqz4Nmgc4msK63+3mVxcQUufc27O9Uu876wA/1ulLAjcFZZjzpU
I7VBvlaBpPQmHkMiBODz5nrlpcfQld1VCxdIcHoP0v7Zsv5/93/EfFszEtm4tgkH
S4rCP7YnWmot3IJsUXCZu+zd/tgULqBKKzaDuATYKidm/G9zWDBbgwzuZW2iUvFd
1nXBXWRTHIizP0WzG2LsT0xIwt1XfXnEct2Zb1pPcp1uxaGzM6EBQ+AMdm+cPAW0
UiYhi6Uv/86QEHDqU3WJ2iK9dtqmz965PTkzZGAy7AlkIeJdFqIflWVfAFjGF1Rs
DW7M/nM55fGlWVO2WYZlPJlaXfzWxEeiMPkOMKIhW4ymay7uWoE=
=yVfo
-----END PGP SIGNATURE-----
Merge tag 'riscv-sophgo-soc-for-v6.16' of https://github.com/sophgo/linux into soc/drivers
RISC-V SoC for v6.16
Sophgo:
Add support for SG2044 TOP syscon device. The SG2044 TOP
device provide PLL clock function in its area.
Add RTC support for CV1800 series SoC. The device
is called RTC, but contains control registers of other
HW blocks in its address space, most notably of
Power-on-Reset (PoR) module, DW8051 IP (MCU core),
accompanying SRAM, hence putting it in SoC subsystem.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* tag 'riscv-sophgo-soc-for-v6.16' of https://github.com/sophgo/linux:
soc: sophgo: cv1800: rtcsys: New driver (handling RTC only)
dt-bindings: soc: sophgo: add RTC support for Sophgo CV1800 series
soc: sophgo: sg2044: Add support for SG2044 TOP syscon device
Link: https://lore.kernel.org/r/MA0P287MB2262B041A26A0F5EAD1E296CFE91A@MA0P287MB2262.INDP287.PROD.OUTLOOK.COM
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Allow list QSEECOM for EFI variable services on on the Asus Zenbook A14,
and block list TZMEM on the SM7150 platform to avoid issues with rmtfs.
Extend the last-level cache (llcc) driver to support version 6 of the
hardware and enable SM8750 support.
Also add socinfo for the SM8750 platform.
Re-enable UCSI support on SC8280XP, now that the reported crash has been
dealt with, and filter the altmode notifications to avoid spurious
hotplug events being propagated to user space.
Add SM7150 support to pd-mapper.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmgjv/wVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3F8RkP/jD+a9ye68m4BLZHsROA1CQ1ntpH
tsIDPZ+L2ojrjECPpAqdVYUhXMllKVXhzNFFVpQ+DTuOn5Ny8yDV6V4m1YJou612
CzgtmhHph/MfPo/JxHFEK3qgOp9jIICXAk87WjrFFimOtgQ2v9W0QDPZj0ReoBkG
gQILjam1tOlm7jv0eODQFoY5qgtsCWm2ZDQ+nwwV5vrsA6pp7IM5lLx515jb72NO
EI7YLKWcLm2JL5v+zTKfprN0CM8+g3ZAfSCZJUH6mONYXrDeqOolFjPT+PTOcRba
SuvYJ7044YbLhswFMQcR6EVSFWWGNxQbvm9J46k3K5D6VOETe4DTsIbfzZ8cRzDK
A4yqOI8q41GYw2kDJUgEBOhiClDIYdVaoVYppwjr3IDrb9lwrkZxRqpDGyVxEp9U
h16vXGP+DBxHL07H6QbytdsMz5tz/CCHEFr7tmpOZt+cdD6y4PZ+sj4kxWq5UXWF
eQ7n0bHXJZHYZa6OWbR/czhVtj+aijpf9Q+sHnVkZHFkihyj9KDu11g9cdGmF1du
8Yz+zZkB0LqtIU8I4a7K+DJI4R0u/6D2ef6BWFjVcc7a1yEudLBBnsJilhxwLLog
166SBXq200GNz7TPVjNlaIQf0ulLzl0mdotLJhIb2i9TT+FHYOIoy0vdamsjHxzs
/O/AHFiD13d/Mxvl
=6aIm
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmguDB8ACgkQmmx57+YA
GNlqaA/8DcsemHeTJqNMxCfwX59JcbPKKAISb/JuREi3BnZKWnIsInDnvkqynNpI
QrUyVX+AC6mzGbnIMD/HQfKFtNAmrFgssLe7+FFlmz5IHSSc3pu9J3HJWLhBlRoT
58sXMVvJ2F1leiZocr7fsD54NNpyAPRUyGMAk3uW1qqxzyS3tu8M3luIUAKrSRrO
nWSm2O9lUDQTblYz9dInAZLYx8X7fILSRy4jNGfy8DPl8EKpdbla3K/BLFI7gOUn
OKc+24sfCSezZUaKGU48NnH4I9f9N5iUnoBOWeAL6Hpu8yy7JNsHzTrKy+oxpRAI
xRzO1KjrVAmlXH7z9WUAkyLxF3NrPbK9gw/6Cd6hFaAp/kXmHNyarPXFgrYBJwjm
wkES+nBryiYxyPpEu0BpxAsf83ppLrJn1Fb6jxxE6tm32/kznBMt7XQM9e9RqAk3
HYyGzmq5gX2r8Cf0GNq8+4n3WYiLecg5vDwhl7Jgj/A3/vVuw4YCxBAAMIt4WGuc
/gJVZK0aPZJq1IH2RAw9Z+UIJ7K1LCR3kQNMkA/Txxp0MYsvIyFnR5LO2925t/QC
SYxLL7BOjg7Zhax0NqUQauiZDX92kzr9ZM91Xhj5QjznPXmmxVDplEHxkEZmZsO0
pZJBj1shnG/etOJsbT+ciDKIfS6W8fGlIOniYdTnXd0YTsWtg/g=
=AXtY
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers
Qualcomm driver updates for v6.16
Allow list QSEECOM for EFI variable services on on the Asus Zenbook A14,
and block list TZMEM on the SM7150 platform to avoid issues with rmtfs.
Extend the last-level cache (llcc) driver to support version 6 of the
hardware and enable SM8750 support.
Also add socinfo for the SM8750 platform.
Re-enable UCSI support on SC8280XP, now that the reported crash has been
dealt with, and filter the altmode notifications to avoid spurious
hotplug events being propagated to user space.
Add SM7150 support to pd-mapper.
* tag 'qcom-drivers-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: llcc-qcom: Add support for SM8750
soc: qcom: llcc-qcom: Add support for LLCC V6
dt-bindings: cache: qcom,llcc: Document SM8750 LLCC block
soc: qcom: socinfo: add SM8750 SoC ID
dt-bindings: arm: qcom,ids: add SoC ID for SM8750
dt-bindings: soc: qcom: qcom,rpm: add missing clock/-names properties
dt-bindings: soc: qcom,rpm: add missing clock-controller node
soc: qcom: smem: Update max processor count
firmware: qcom: tzmem: disable sm7150 platform
soc: qcom: pd-mapper: Add support for SM7150
soc: qcom: pmic_glink_altmode: fix spurious DP hotplug events
soc: qcom: smp2p: Fix fallback to qcom,ipc parse
soc: qcom: pmic_glink: enable UCSI on sc8280xp
firmware: qcom: scm: Allow QSEECOM on Asus Zenbook A14
dt-bindings: soc: qcom,rpmh-rsc: Limit power-domains requirement
Link: https://lore.kernel.org/r/20250513215656.44448-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Two cleanups which were missed on mailing lists - align GPIO node names
with DT bindings for Mediatek mt7622 and Nvidia Tegra210-p2894.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmgjIRIQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD132YD/95kvOhmdQmd1qvc+bVSgLThHr2FCvX0VT7
B8Yk8XRalngADyG4Qda0m4XA9lZQ1jiG2i0fWBb2aEXqMDgve4jvq1J9BoNxIloY
eR+ATlRnmIDBiAvGozvPhp/WIPCm17RDscCl8XvJCiEXrRfKUQuVljtj/aOLbeWZ
NKjRPPdXQlKjaBUSUv3geW2z68uPRKEXsrKf5/v8jGAFUoWF7y7eascGuUz/ZQZr
hB11emIOteQ824vsE0rkE5V4a2Szaro50+xryvGw9Ja0YaoXwyog+wEiRgvySYnc
YyTfKjccUYgyIdTjBnIECiTEwlBiy6InPzBfVNx8ezlVFiuPTzt7Yv0v/acKx/D7
OXAs1yEEWYSu5NoHbhHxdGaHbtVScbHwPdS1PV7WPpBD0IBdCorSJKzKF+hNHdjz
Javm/bD5B8ichKJKpPPOWmPiY/8h7TQFUsuzd+zDY4CZQEnHEdNCeC//RZ/AOdIm
KYrcD0JL/NliaDh2i3wDs1AN6rV45Uhv6mBwjFSJfZBhXPqB8ns7wD08PIeyuNoq
Pv6NllWrNoHKlyz+pXYgDIzM7a6iDfCAjydO6gkS8EgE/tYKTaJKDyfvs7NPM5MU
VONtP8DZoGfm7u45JrHMLwvsR4HRaz2IjouAA2C/k6z4SXsICWAODXWjjXX0fPtv
NYg3gFLLKw==
=vSix
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmguCdcACgkQmmx57+YA
GNkaHBAAtJ24IruvIM7TLO1z7yHnWvaGeCzks1AR8yP3Hhl8HppwsQ9UKI0GOiki
iIiYlc4RNJCg79HjA9375UenmzHyC62dcD7fCHZxfWKoNQm/+KTA8WbH2iELZm6A
cBYr+G+AqMHKrNC/JFlVtxULy1HQY+/8ktKbg1YG8vpnBiGTAmZuDk5lgjwB/5qI
0Y8GK/3mUY5AWs7oXgPcBJmkD8mn9f/iYH8YhDfrBLMY6hGelEBFdezvoyBQhE1o
C+hZ06A9adS+GUlOHNRh83F3FbaRqmKDixxn7WGaXOxq5/e8OPc50zEdZPvNtZPY
DhGGiPMexG8+qVCJC+rSsmZedhHHwEjWQlTj3WxJ4RgbhfjhZRHbaMXcD83S6uVG
YF9Og1PiL9T9irw1yLZYNFZTSILr4a7I5oXOS/mlgufU37sW6RZDq1XHZLGEB435
MU2ubBC8oZcswwKMBfekk5+Ah7cGlW/DZrZnj5FqYuMFQWaAgWc53t1YLE70cZtU
litnjKeol9uSKUc2QgISth8MXSrSll+YqAv5A/YdRjcF6uLDWZPJ/Bo9tsgXtSj+
uikuW/0IBLztu3NMe1OaYI9mgMISRH4bn6ClgTfevm1IVIkFZ6hVWCkF9Mi9DyOl
rP4jg9KvwQ3S2HXtSI9QJjKLwc6Gt5CsGq5FMT94PaByjovqH3s=
=QSN1
-----END PGP SIGNATURE-----
Merge tag 'dt64-cleanup-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt into soc/dt
Minor improvements in ARM64 DTS for v6.16
Two cleanups which were missed on mailing lists - align GPIO node names
with DT bindings for Mediatek mt7622 and Nvidia Tegra210-p2894.
* tag 'dt64-cleanup-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt:
arm64: tegra: tegra210-p2894: Align GPIO hog node name with preferred style
arm64: dts: mediatek: mt7622: Align GPIO hog name with bindings
Link: https://lore.kernel.org/r/20250513104216.25803-4-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Enable Cadence DSI and PHY driver support for DSI support on BeagleBone-AI64,
BeaglePlay, BeagleY-AI, All TI EVMs etc.
- Enable hardware spinlock and Quadrature Encoder Pulse (QEP) support for
AM64-SK and other boards.
- Enable TMP102 driver to support Phytec phyCORE-AM68x/TDA4x and the
phyGATE-Tauri-L-iMX8MM
- Enable TPIC2810 for AM64-SK LED GPIO control.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE+KKGk1TrgjIXoxo03bWEnRc2JJ0FAmgiA/MACgkQ3bWEnRc2
JJ29SxAAmRZgxBJ3/ZS+b5Tv///bWnbpZPZVSbGfT1GZO26kHw7gDHI7dIdAPwqv
yJjLMFjPZeR0f79GB6b74Q1vx+GvA27jwDsW6wrufq+CoKub85xST+nSUlsqNX9O
KlGauSgBEJYqC5Y6vmQcVqsYcZkb8PONJ2cGsoP+wVZfICPf8RReOldSqjpjdVA/
AsUuvIsj/KU51x8v+gKZvJKI6Lz/GQihX4vZDPZGBkp4NMFhA3uXTTDZh8MBhVE0
IrIMFHyxGS04k2IjR/96JI8eGalmeU7g9IoZXG0FLub1gP6sSuTEEMxzuyeWYyRc
1Lf6hN5m/GO4FhVJ6Yn9Yj/BKdTYpoLONXpP9vvld5+CzC/SFzmMICRPe2MgPRB6
M6cvsrd2smYmZyabbUmMUeu5a8QRfv5M/fR4v2iRyLMe20I+oXyNp0SvhVfp/zsT
E8hHTsu7PQ7qHG/OxEvqYZXgUoRluCW/nMGNziwj0wtq12Cvdw38qENj7NcIt1a/
fuw7QsAkc97kEmQM39OGDgwtreA9Yintj4/cRjzTvS7fl6hb5JIg/oO+I11dOLcG
OUoyZDP1JdEgaxgn0zTOaL6EIcMtxngvlgTS6JYPkTfgUFxYFRN6wqOMScrbDD47
ij+wwv+n4CXIB2njJtPQ7hwjpxqmQyNFMjbcrFzlcC/bTN2SoLY=
=B+nK
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmguCE0ACgkQmmx57+YA
GNk4EA//clYk+vPVbvDuBhNtBbn2A0/HFFFdYksDgrrpk0l3O9YKPzWM0wYK3f/v
aiGgeTST6bS9AGi5L26uV4uIMj22YvkyRWdFl6zltqLJ/U537LEFCuMQtOK1LE7e
+AbDUJxmt+pcEfz0tVEN7bR2nBjAsLZTHYWRL5lOsOer2uHMsNr4AoCCxGg0gEOe
b/t9B12Cik0jEpIUOMZoup5HhdDo7XRreevTDw4Bpbl7zi8WDd8yZZJycCaTK9ks
8qgViaFoszokr4W2F2DOJNIbTOe6fEYsaR7L/3dRy9ArlGEJCBlX8iTZ/fUUyhOc
yvA95erwC1jn8jyxCZr2pAs5styE2V3DGoHAg0rQnWIRm6NYsI899cFlu2/37bNS
vl25rnY74CFo1+06lfizvCiA5EKcsKD6Z7/A0IzbXd9uhIU56qjd+eUP6BwNqCCN
gkdWtOvGjIxmkiNd5h2ez8YmmA+o7RKtZhvR+jfj1RD1FCilVTgzrQ1UL0h0vnki
jPA3J9CgMzFzU8471GsjQh4Qo2kqCXZTtILi4ozM++bI28CyiMSfO1ONK9P7caSh
a0lIEXG16V/PiwPNPHq/hbQmAVJ5baQhXtSE9tmvdgbouUXF6sUVAkN0egsTVpCP
mdLWL3sEidVmNV4T016Z66jEpxS30jFyp4hV81Zt4EP4skRWHW0=
=RRmY
-----END PGP SIGNATURE-----
Merge tag 'ti-k3-config-for-v6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/defconfig
TI K3 defconfig updates for v6.16
- Enable Cadence DSI and PHY driver support for DSI support on BeagleBone-AI64,
BeaglePlay, BeagleY-AI, All TI EVMs etc.
- Enable hardware spinlock and Quadrature Encoder Pulse (QEP) support for
AM64-SK and other boards.
- Enable TMP102 driver to support Phytec phyCORE-AM68x/TDA4x and the
phyGATE-Tauri-L-iMX8MM
- Enable TPIC2810 for AM64-SK LED GPIO control.
* tag 'ti-k3-config-for-v6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux:
arm64: defconfig: Enable TPIC2810 GPIO expander
arm64: defconfig: Enable TMP102 as module
arm64: defconfig: Enable hwspinlock and eQEP for K3
arm64: defconfig: Add CDNS_DSI and CDNS_PHY config
Link: https://lore.kernel.org/r/20250512144738.dv63fd4fyuly3s44@diocese
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- ti_sci: Bug fix in CPU latency conversion from us to ms for TISCI protocol
- k3-socinfo: Add JTAG ID for AM62LX
- Code cleanups: wkup_m3_ipc: Use dev_err_probe, k3-ringacc: use
device_match_of_probe and knav_qmss_queue: drop unnecessary NULL check
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE+KKGk1TrgjIXoxo03bWEnRc2JJ0FAmgiA5oACgkQ3bWEnRc2
JJ2pfQ//ZwfZ9/QifyvND6E1/xIVe2pk3zCc0Yh5MDCNq0sEC7sw7gHWMW2rwGoQ
6UTLJzqqdjB4FEmr/rWb2ZhYELvlESNrxESrDFULqh//t7J/L9OIqOhxBg2eyADn
PHXYizgICKt5FF4K6v5DOGeSYKhk5QOzTVxbdKMnrU6OPrefbV8wnp2gqbvjtRWh
CPh2xpx8MZgI2y7Joy/vV9XQkNpLOSSqFg59JiT8zA0gLV6OEikXSSbnxbHgKcSg
t30C+7GyUcTQ47cKMPyHzap76vZ707h+CMSJ5UMzjhgJCM1WepquYqE4b+5CWJal
9pajrgLqFABpMXyzGitpv2+MhIfyc8jGY3VY3IsWeezmXucIe8X9AbFb3zvOazVy
qmytSADnYcEV2d9ugIwbmBr0ksXNIG0bKmhHzThxSs0nep2Ezzk7O6A6ujL7dQyy
8SogQtfdZSSaDvTVMVIV1QMvF2SJnUUIJgL2obIj8vv2GSsFP4R8uKZaPxevv2tI
f6Lb5gUlxLJCFXuyUa7uya4l8QgO+OFW7ln+C31R1jJOOWmsUtfxAhjJXGL8rUL+
lhWOmQs/XCu9AxqH3QNEoTHl0A4JtSk0TbqvnuajguQB1IQHO2TGvgzv9f0nRIM3
6BreADgLQkaFi9YE19SHJxHdXhR4zIQDdcNMCUK6v63yV2SUztc=
=2TQF
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmguB6IACgkQmmx57+YA
GNk5Xw//WM1CTqM/MgXDImqDR0u41T1rW6vzwo3CKSlh9+qo3JLAApP1cmfN0LLB
0lip3XUvItb72XqgB28GfUF+9dU7jn8FvhsMzE0tF9gfG9D+2zRtpZoPTt8wUX1b
MMGiIlQXErfSAeBlzHlQ+dujOD2vYbhFf5YXptv3eQZ1XyTOwF3eOuURbiCBQfAJ
Ki8klH/+9p1fVhgyCYXcOrWYJ3IIbGzDj/kwFOYf/kP1FdnfLiG4Fl3uShKzZE4v
twwqEPYDNwcw47rYR3Y/jhLsQmfpLvd2tHt7wJS+Rl29QMzFJ0oSIn8Y84YiWdDQ
hU5QLqIo4NlEZ+0+VqaBm3ulVypBkMXAKwiGUG+GZyCzNTaq2lGxBPrirXRojjsK
1uMYXPJWG9gdBBDiwDu+lVP/nxZtMgU4Vwo0XtbSNOAQ3eW4/4Dz4jmgw5vGwLe7
a8O3cTr1V4DuvpETp4Meo8pwZHoi/3iw6k3fveGfxYlYNWYx2uP7AoRGbDr5dXPz
SYsL5592FCpC6aXLD8+LRJ04PszDAeVx1kyss3/SWwAFeTx6EH0qPLinWrwHi77L
Fi5E45Rk9WWslSMFKEwBRJqGuxtbkyPOtuyATmOmnLPz1Ip2puJCBznCipoBULDr
lVMbkzkMcoLOLJtm7W51Ng+hJIcg4zykITw4SxZDMCFCB7DxEos=
=N/zC
-----END PGP SIGNATURE-----
Merge tag 'ti-driver-soc-for-v6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/drivers
TI SoC driver updates for v6.16
- ti_sci: Bug fix in CPU latency conversion from us to ms for TISCI protocol
- k3-socinfo: Add JTAG ID for AM62LX
- Code cleanups: wkup_m3_ipc: Use dev_err_probe, k3-ringacc: use
device_match_of_probe and knav_qmss_queue: drop unnecessary NULL check
* tag 'ti-driver-soc-for-v6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux:
soc: ti: wkup_m3_ipc: Use dev_err_probe
firmware: ti_sci: Convert CPU latency constraint from us to ms
soc: ti: k3-socinfo: Add JTAG ID for AM62LX
soc: ti: knav_qmss_queue: Remove unnecessary NULL check before free_percpu()
soc: ti: k3-ringacc: Use device_match_of_node()
Link: https://lore.kernel.org/r/20250512144719.mpkyw2jbyzslb5hy@yearly
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
Add helper functions to add DAPM widgets, routes, ALSA controls,
and DAI drivers, these will be used to create SDCA function device
drivers.
This series should provide most of the core functionality needed to
get a device registered and have a working DAPM graph within the
device. There are some features that still need additional work, these
are marked with FIXMEs in the code. The two main things are SDCA
Clock Muxes (not used in our devices and needs some ASoC core work),
and better support for more complex SDCA volume control definitions
(our parts have fairly simple volumes, and SDCA has a large amount of
flexibility in how the volume control is specified).
The next steps in the process are to add helpers for the DAI ops
themselves, some IRQ handling, and firmware download. And finally we
should be able to actually add the SDCA class driver itself.
kmsan_report() calls used to require entering/leaving the runtime around
them. To simplify the things, drop this requirement and move calls to
kmsan_enter_runtime()/kmsan_leave_runtime() into kmsan_report().
Link: https://lkml.kernel.org/r/20250507160012.3311104-5-glider@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Dmitriy Vyukov <dvyukov@google.com>
Cc: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
kmsan_internal_memmove_metadata() transitively calls stack_depot_save()
(via kmsan_internal_chain_origin() and kmsan_save_stack_with_flags()),
which may allocate memory. Guard it with kmsan_enter_runtime() and
kmsan_leave_runtime() to avoid recursion.
This bug was spotted by CONFIG_WARN_CAPABILITY_ANALYSIS=y
Link: https://lkml.kernel.org/r/20250507160012.3311104-4-glider@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Acked-by: Marco Elver <elver@google.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Dmitriy Vyukov <dvyukov@google.com>
Cc: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This function is not defined anywhere.
Link: https://lkml.kernel.org/r/20250507160012.3311104-3-glider@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Acked-by: Marco Elver <elver@google.com>
Cc: Bart van Assche <bvanassche@acm.org>
Cc: Dmitriy Vyukov <dvyukov@google.com>
Cc: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
