Hi Taehee,
On 6/22/24 2:50 오후, Taehee Yoo wrote:
> On Sat, Jun 22, 2024 at 1:58 PM wrote:
>>
>> From: Yunseong Kim
>>
>
> Hi Yunseong,
> Thanks a lot for this work!
Thank you Taehee for reviewing our patch. It's greatly appreciated.
>> During qdisc initialization, qdisc was being set to noop_
On Sat, Jun 22, 2024 at 1:58 PM wrote:
>
> From: Yunseong Kim
>
Hi Yunseong,
Thanks a lot for this work!
> In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
>
> qdisc->dev_queue->dev ->name
>
> This situation simulated from bunch of veths and Bluetooth dis/reconnection.
>
> Durin
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop_queue.
In veth_init_queue, the initial tx_num w
Hi Jakub,
On 6/22/24 9:05 오전, Jakub Kicinski wrote:
> On Sat, 22 Jun 2024 01:25:54 +0900 ysk...@gmail.com wrote:
>> Subject: [PATCH net v2] net/sched: Fixes: 51270d573a8d NULL ptr deref in
>> perf_trace_qdisc_reset()
>
> the Fixes tag goes before your signoff, rather than as title.
> try
>
>
On 6/21/2024 15:01, Yazen Ghannam wrote:
> On Fri, Jun 21, 2024 at 06:58:23PM +0200, Borislav Petkov wrote:
>> On Thu, May 30, 2024 at 04:16:16PM -0500, Avadhut Naik wrote:
>>> arch/x86/include/asm/mce.h | 20 ++-
>>> arch/x86/kernel/cpu/mce/apei.c | 111 ++
>>
On Thu, 20 Jun 2024 03:44:53 -0400 Michael S. Tsirkin wrote:
> Moving initialization of stats structure into
> __free_old_xmit reduces the code size slightly.
> It also makes it clearer that this function shouldn't
> be called multiple times on the same stats struct.
>
> Signed-off-by: Michael S.
On Sat, 22 Jun 2024 01:25:54 +0900 ysk...@gmail.com wrote:
> Subject: [PATCH net v2] net/sched: Fixes: 51270d573a8d NULL ptr deref in
> perf_trace_qdisc_reset()
the Fixes tag goes before your signoff, rather than as title.
try
git log --grep=Fixes
--
pw-bot: cr
Request in-kernel protection domain mapper to be started before starting
Qualcomm DSP and release it once DSP is stopped. Once all DSPs are
stopped, the PD mapper will be stopped too.
Reviewed-by: Chris Lew
Tested-by: Steev Klimaszewski
Tested-by: Neil Armstrong # on SM8550-QRD
Signed-off-by: D
Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was started but the corresponding
directory is mounted
The in-kernel PD mapper is going to use same message structures as the
QCOM_PDR_HELPERS module. Extract message marshalling data to separate
module that can be used by both PDR helpers and by PD mapper.
Reviewed-by: Bryan O'Donoghue
Tested-by: Steev Klimaszewski
Tested-by: Alexey Minnekhanov
Te
While parsing the domains list, start offsets from 0 rather than from
domains_read. The domains_read is equal to the total count of the
domains we have seen, while the domains list in the message starts from
offset 0.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
T
If the service locator server is restarted fast enough, the PDR can
rewrite locator_addr fields concurrently. Protect them by placing
modification of those fields under the main pdr->lock.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Tested-by: Neil Armstrong # o
Protection domain mapper is a QMI service providing mapping between
'protection domains' and services supported / allowed in these domains.
For example such mapping is required for loading of the WiFi firmware or
for properly starting up the UCSI / altmode / battery manager support.
The existing u
ff-by: Valeriy Klimin
> ---
> Changes in v2:
> - Reordered dt-bindings and dts commits
> - Link to v1:
> https://lore.kernel.org/r/20240621-sony-aries-v1-0-bcf968769...@gmail.com
Please let reviewers finish their job first. It's recommended to post
once in 24 hours timeframe. Otherwise yo
On Fri, Jun 21, 2024 at 05:16:58PM GMT, Gokul Sriram Palanisamy wrote:
> Add WCSSAON reset required for Q6v5 on IPQ8074 SoC.
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
Three authors for a single line?
> Acked-by: Stephen Boyd
> -
On Fri, Jun 21, 2024 at 05:16:51PM GMT, Gokul Sriram Palanisamy wrote:
> IPQ8074 needs support for secure pil as well.
> Also, currently only unified firmware is supported.
> IPQ8074 supports split firmware for q6 and m3, so
> adding support for that.
>
> changes since v8:
> - Rebased on top of L
On Fri, Jun 21, 2024 at 05:16:55PM GMT, Gokul Sriram Palanisamy wrote:
> Add name for ssr subdevice on IPQ8074 SoC.
Is it SSR or ssr? Why is it necessary?
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
Three authors for a single-line
On Fri, Jun 21, 2024 at 05:16:51PM GMT, Gokul Sriram Palanisamy wrote:
> IPQ8074 needs support for secure pil as well.
Could you please settle on 'pil' or 'PIL'. Just use one of them.
Explain, what is secure PIL.
> Also, currently only unified firmware is supported.
What is unified firmware? Wha
On Fri, Jun 21, 2024 at 05:16:53PM GMT, Gokul Sriram Palanisamy wrote:
> IPQ8074 uses secure PIL. Hence, adding the support for the same.
See Documentation/process/submitting-patches.rst
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
On Fri, Jun 21, 2024 at 05:16:52PM GMT, Gokul Sriram Palanisamy wrote:
> PRNG clock is needed by the secure PIL, support for the same
> is added in subsequent patches.
Which 'same'?
What is 'secure PIL'?
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sr
On Fri, Jun 21, 2024 at 10:42:31AM GMT, Luca Weiss wrote:
> PM8008 regulators are used for the cameras found on FP5. Configure the
> chip and its voltages.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 105
> -
> 1 file changed, 1
On Fri, Jun 21, 2024 at 10:42:30AM GMT, Luca Weiss wrote:
> PM8008 regulators are used for the cameras found on FP4. Configure the
> chip and its voltages.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 109
> +-
> 1 file changed, 1
On Fri, Jun 21, 2024 at 11:14:46AM GMT, Valeriy Klimin wrote:
> Add the dts for the Z3 Compact. This is currently almost the same
> as the plain Z3 as they share almost the same hardware and
> nothing device-specific is currently supported.
>
> Signed-off-by: Valeriy Klimin
> ---
> arch/arm/boot
On Fri, Jun 21, 2024 at 11:14:48AM GMT, Valeriy Klimin wrote:
> SD cards would exhibit errors similar to ones described in commit
> 27fe0fc05f35 ("ARM: dts: msm8974-FP2: Increase load on l20 for sdhci")
>
> This patch applies the same change to the regulator for sdhc2.
>
> Signed-off-by: Valeriy
On Fri, Jun 21, 2024 at 06:58:23PM +0200, Borislav Petkov wrote:
> On Thu, May 30, 2024 at 04:16:16PM -0500, Avadhut Naik wrote:
> > arch/x86/include/asm/mce.h | 20 ++-
> > arch/x86/kernel/cpu/mce/apei.c | 111 ++
> > arch/x86/kernel/cpu/mce/core.c | 19
Previous calculation of 'free_space' was wrong (but worked as expected
in most cases, see below), because it didn't account number of bytes in
rx queue. Let's rework 'free_space' calculation in the following way:
as this value is considered free space at rx side from tx point of view,
it must be eq
This test checks, that we send exactly expected number of credit
update packets during deferred credit update optimization. Test
work in client/server modes:
1) Client just connects to server and send 256Kb of data. 256Kb
is chosen because it is default space for vsock peer. After
transmissio
This patchset contains:
0001 - patch which reworks deferred credit update. Pls see commit message,
it contains full description of this problem.
0002 - test which uses vsockmon interface, and checks that deferred
credit update works as expected by parsing raw packets.
Arseniy Krasno
On Fri, 21 Jun 2024 13:34:44 +0200 Ilya Leoshkevich wrote:
> v6 -> v7: Drop the ptdump patch.
> All patches are reviewed.
I added v7 to mm.git (and hence linux-next).
On Thu, May 30, 2024 at 04:16:16PM -0500, Avadhut Naik wrote:
> arch/x86/include/asm/mce.h | 20 ++-
> arch/x86/kernel/cpu/mce/apei.c | 111 ++
> arch/x86/kernel/cpu/mce/core.c | 191 ++--
> arch/x86/kernel/cpu/mce/dev-mcelog.c|
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop_queue.
In veth_init_queue, the initial tx_num w
On 6/21/2024 5:16 PM, Gokul Sriram Palanisamy wrote:
Add binding for WCSSAON reset required for Q6v5 reset on IPQ8074 SoC.
Can we include ipq8074 in the title? "dt-bindings: clock: qcom: ipq8074:
Add reset for WCSSAON"
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed
On 6/21/2024 5:16 PM, Gokul Sriram Palanisamy wrote:
Add WCSSAON reset required for Q6v5 on IPQ8074 SoC.
Commit title can be written as "clk: qcom: ipq8074: Add WCSSAON reset" ?
With that,
Reviewed-by: Kathiravan Thirumoorthy
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
On 6/21/2024 5:16 PM, Gokul Sriram Palanisamy wrote:
Enable remoteproc WCSS PIL driver with glink. Also,
configure shared memory and enables smp2p required for IPC.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/q
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
> Add name for ssr subdevice on IPQ8074 SoC.
Why?
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
Three people developed that single line?
Something is really odd with your DCO chai
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
> Enable remoteproc WCSS PIL driver with glink. Also,
> configure shared memory and enables smp2p required for IPC.
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
> ---
> arch/arm64/b
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
> Add binding for WCSSAON reset required for Q6v5 reset on IPQ8074 SoC.
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
Again, three people contributed to this one define?
Best regard
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
> Fixed issue in reading halt-regs parameter from device-tree.
What issue?
That's a terrible commit msg. Explain what is the problem, how can it be
reproduced.
>
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
> ---
>
Function rb_check_pages() validates the integrity of a specified per-CPU
tracing ring buffer. It does so by walking the underlying linked
list and checking its next and prev links.
To guarantee that the list doesn't get modified during the check,
a caller typically needs to take cpu_buffer->reader
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
>
> -static int q6v5_wcss_init_clock(struct q6v5_wcss *wcss)
> +static int ipq8074_init_clock(struct q6v5_wcss *wcss)
> +{
> + int ret;
> +
> + wcss->prng_clk = devm_clk_get(wcss->dev, "prng");
Missing binding.
Best regards,
Krzysztof
Hi Pedro,
On 6/21/24 11:24 오후, Pedro Tammela wrote:
> On 21/06/2024 08:45, ysk...@gmail.com wrote:
>> From: Yunseong Kim
>>
>> In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
>>
>> qdisc->dev_queue->dev ->name
>>
>> This situation simulated from bunch of veths and Bluetooth
>> d
ret variable was used to test reset status, get from
reset_control_status() call. But this variable was overwritten by
ti_sci_proc_get_status() a few lines bellow.
And as ti_sci_proc_get_status() returns 0 or a negative value (in this
latter case, followed by a return), the expression !ret was alwa
Introduce software IPC handshake between the K3-R5 remote proc driver
and the R5 MCU to gracefully stop/reset the remote core.
Upon a stop request, K3-R5 remote proc driver sends a RP_MBOX_SHUTDOWN
mailbox message to the remote R5 core.
The remote core is expected to:
- relinquish all the resource
In the next commit, a RP_MBOX_SHUTDOWN message will be sent in
k3_r5_rproc_stop() to the remote proc (in lockstep on not)
Thus, the sanity check "do not allow core 0 to stop before core 1"
should be moved at the beginning of the function so that the generic case
can be dealt with.
In order to have
This patch adds the support for system suspend/resume to the ti_k3_R5
remoteproc driver.
In order to save maximum power, the approach here is to shutdown
completely the cores that were started by the kernel (i.e. those in
RUNNING state).
Those which were started before the kernel (in attached mode
This series enables the suspend to ram with R5F remote processors on TI K3
platform.
The 1st patch is actually a fix, independent from the others
The 2nd patch introduces the suspend/resume handlers.
On suspend, the running rprocs will be stopped (or detached) and then
re-loaded in resume.
The lo
Main updates from version V7[1]
Update the series based on Mathieu Poirier's comments.
Details of the updates are listed in the commit messages of the patches.
[1]
https://lore.kernel.org/linux-arm-kernel/20240611073904.475019-1-arnaud.pouliq...@foss.st.com/
base-commit: 1613e604df0cd359cf2a7fb
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted Execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE device
trees:
- In OP-TEE, a node is defined in the device tree with the
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without remoteproc TEE support.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 84 +++-
1 file changed, 51 insertions(+), 33 deletions(-
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this driver offers a client
interface to load a firmware by the secure part.
This firmware could be authenticated by the secure trusted a
When a resource table is loaded by an external entity such as U-boot or
OP-TEE, we do not necessarily get the device address(da) but the physical
address(pa).
This helper performs similar translation than the rproc_da_to_va()
but based on a physical address.
Signed-off-by: Arnaud Pouliquen
---
up
The new TEE remoteproc device is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format de
SD cards would exhibit errors similar to ones described in commit
27fe0fc05f35 ("ARM: dts: msm8974-FP2: Increase load on l20 for sdhci")
This patch applies the same change to the regulator for sdhc2.
Signed-off-by: Valeriy Klimin
---
arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-co
Add the dts for the Z3 Compact. This is currently almost the same
as the plain Z3 as they share almost the same hardware and
nothing device-specific is currently supported.
Signed-off-by: Valeriy Klimin
---
arch/arm/boot/dts/qcom/Makefile| 1 +
.../qcom-msm8974pro-sony-xperi
Add the compatible for this device.
Signed-off-by: Valeriy Klimin
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
b/Documentation/devicetree/bindings/arm/qcom.yaml
index ae885414b181..e53f061
://lore.kernel.org/r/20240621-sony-aries-v1-0-bcf968769...@gmail.com
---
Valeriy Klimin (3):
dt-bindings: arm: qcom: Add Sony Xperia Z3 Compact
ARM: dts: qcom: Add Sony Xperia Z3 Compact smartphone
ARM: dts: qcom: msm8974-sony-shinano: increase load on l21 for sdhc2
Documentation
On 21/06/2024 08:45, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop
Am 18.06.2024 um 21:58 schrieb Luis Chamberlain:
On Thu, Jun 06, 2024 at 03:31:49PM +0200, Daniel v. Kirschten wrote:
If a module is being loaded, and the .gnu.linkonce.this_module section
in the module's ELF file does not have the WRITE flag, the kernel will
map the finished module struct of th
On Thu, 2024-06-20 at 14:37 +0200, Peter Hilber wrote:
> Should implement .gettimex64 instead.
Thanks. This look sane?
As noted in the code comment, in the *ideal* case we just build all
three pre/post/device timestamps from the very same counter read. So
sts->pre_ts == sts->post_ts.
In the less
On 6/21/24 6:14 AM, Beleswar Prasad Padhi wrote:
Hi Andrew,
On 04/06/24 22:40, Andrew Davis wrote:
On 6/4/24 12:17 AM, Beleswar Padhi wrote:
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for m
On Fri, Jun 21, 2024 at 02:01:50PM +0200, Oleg Nesterov wrote:
> On 06/20, Andrii Nakryiko wrote:
> >
> > On Thu, Jun 20, 2024 at 12:40 PM Oleg Nesterov wrote:
> > >
> > > But I can't understand what does it do, it calls emit_break() and
> > > git grep -w emit_break finds nothing.
> > >
> >
> > It
On Fri, Jun 21, 2024 at 12:35 PM Alice Ryhl wrote:
>
> Make it possible to have Rust code call into tracepoints defined by C
> code. It is still required that the tracepoint is declared in a C
> header, and that this header is included in the input to bindgen.
>
> Signed-off-by: Alice Ryhl
> ---
On 06/20, Andrii Nakryiko wrote:
>
> On Thu, Jun 20, 2024 at 12:40 PM Oleg Nesterov wrote:
> >
> > But I can't understand what does it do, it calls emit_break() and
> > git grep -w emit_break finds nothing.
> >
>
> It's DEF_EMIT_REG0I15_FORMAT(break, break_op) in
> arch/loongarch/include/asm/inst.
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop_queue.
In veth_init_queue, the initial tx_num w
Enable remoteproc WCSS PIL driver with glink. Also,
configure shared memory and enables smp2p required for IPC.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 80 +++
1 file c
Add WCSSAON reset required for Q6v5 on IPQ8074 SoC.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
Acked-by: Stephen Boyd
---
drivers/clk/qcom/gcc-ipq8074.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/gcc-ipq8074.c b/
Add binding for WCSSAON reset required for Q6v5 reset on IPQ8074 SoC.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
Acked-by: Rob Herring
Acked-by: Stephen Boyd
---
include/dt-bindings/clock/qcom,gcc-ipq8074.h | 1 +
1 file changed, 1 inser
Fixed issue in reading halt-regs parameter from device-tree.
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
Add name for ssr subdevice on IPQ8074 SoC.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
b/drivers/remoteproc/qco
IPQ8074 uses secure PIL. Hence, adding the support for the same.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 43 +++--
1 file changed, 40 insertions(+), 3 deletions(-)
diff
PRNG clock is needed by the secure PIL, support for the same
is added in subsequent patches.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 65 +
1 file changed, 47 insertio
IPQ8074 supports split firmware for q6 and m3 as well.
So add support for loading the m3 firmware before q6.
Now the drivers works fine for both split and unified
firmwares.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc
IPQ8074 needs support for secure pil as well.
Also, currently only unified firmware is supported.
IPQ8074 supports split firmware for q6 and m3, so
adding support for that.
changes since v8:
- Rebased on top of Linux 6.10-rc4
Gokul Sriram Palanisamy (8):
remoteproc: qcom: Add PRNG proxy clock
The unwind code can read uninitialized frames. Furthermore, even in
the good case, KMSAN does not emit shadow for backchains. Therefore
disable it for the unwinding functions.
Reviewed-by: Alexander Potapenko
Acked-by: Heiko Carstens
Signed-off-by: Ilya Leoshkevich
---
arch/s390/kernel/unwind_
This is normally done by the generic entry code, but the
kernel_stack_overflow() flow bypasses it.
Reviewed-by: Alexander Potapenko
Acked-by: Heiko Carstens
Signed-off-by: Ilya Leoshkevich
---
arch/s390/kernel/traps.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/s390/kernel/t
arch_kmsan_get_meta_or_null() finds the lowcore shadow by querying the
prefix and calling kmsan_get_metadata() again.
kmsan_virt_addr_valid() delegates to virt_addr_valid().
Acked-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/include/asm/
uaccess.h uses instrument_get_user() and instrument_put_user(), which
are defined in linux/instrumented.h. Currently we get this header from
somewhere else by accident; prefer to be explicit about it and include
it directly.
Suggested-by: Alexander Potapenko
Reviewed-by: Alexander Potapenko
Sign
Add KMSAN support for the s390 implementations of the string functions.
Do this similar to how it's already done for KASAN, except that the
optimized memset{16,32,64}() functions need to be disabled: it's
important for KMSAN to know that they initialized something.
The way boot code is built with
Lockdep generates the following false positives with KMSAN on s390x:
[6.063666] DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled())
[ ...]
[6.577050] Call Trace:
[6.619637] [<0690d2de>] check_flags+0x1fe/0x210
[6.665411] ([<0690d2da>] check_flags+0x1fa/0x210)
[
Diagnose 224 stores 4k bytes, which currently cannot be deduced from
the inline assembly constraints. This leads to KMSAN false positives.
Fix the constraints by using a 4k-sized struct instead of a raw
pointer. While at it, prettify them too.
Suggested-by: Heiko Carstens
Reviewed-by: Alexander
The pages for the KMSAN metadata associated with most kernel mappings
are taken from memblock by the common code. However, vmalloc and module
metadata needs to be defined by the architectures.
Be a little bit more careful than x86: allocate exactly MODULES_LEN
for the module shadow and origins, an
s390 uses assembly code to initialize ftrace_regs and call
kprobe_ftrace_handler(). Therefore, from the KMSAN's point of view,
ftrace_regs is poisoned on kprobe_ftrace_handler() entry. This causes
KMSAN warnings when running the ftrace testsuite.
Fix by trusting the assembly code and always unpois
Now that everything else is in place, enable KMSAN in Kconfig.
Acked-by: Heiko Carstens
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c59d2b54df49..3cba4993d
stcctm() uses the "Q" constraint for dest, therefore KMSAN does not
understand that it fills multiple doublewords pointed to by dest, not
just one. This results in false positives.
Unpoison the whole dest manually with kmsan_unpoison_memory().
Reported-by: Alexander Gordeev
Reviewed-by: Alexande
Adjust the stack size for the KMSAN-enabled kernel like it was done
for the KASAN-enabled one in commit 7fef92ccadd7 ("s390/kasan: double
the stack size"). Both tools have similar requirements.
Reviewed-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
Prevent KMSAN from complaining about buffers filled by cpacf_trng()
being uninitialized.
Tested-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Acked-by: Heiko Carstens
Signed-off-by: Ilya Leoshkevich
---
arch/s390/include/asm/cpacf.h | 3 +++
1 file changed, 3 insertions(+)
diff --gi
KMSAN warns about check_canary() accessing the canary.
The reason is that, even though set_canary() is properly instrumented
and sets shadow, slub explicitly poisons the canary's address range
afterwards.
Unpoisoning the canary is not the right thing to do: only
check_canary() is supposed to ever
put_user() uses inline assembly with precise constraints, so Clang is
in principle capable of instrumenting it automatically. Unfortunately,
one of the constraints contains a dereferenced user pointer, and Clang
does not currently distinguish user and kernel pointers. Therefore
KMSAN attempts to ac
All other sanitizers are disabled for boot as well. While at it, add a
comment explaining why we need this.
Reviewed-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/boot/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/s39
Even though the KMSAN warnings generated by memchr_inv() are suppressed
by metadata_access_enable(), its return value may still be poisoned.
The reason is that the last iteration of memchr_inv() returns
`*start != value ? start : NULL`, where *start is poisoned. Because of
this, somewhat counterin
Improve the readability by replacing the custom aligning logic with
ALIGN_DOWN(). Unlike other places where a similar sequence is used,
there is no size parameter that needs to be adjusted, so the standard
macro fits.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan
Add a KMSAN check to the CKSM inline assembly, similar to how it was
done for ASAN in commit e42ac7789df6 ("s390/checksum: always use cksm
instruction").
Acked-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/include/asm/checksum.h | 2 ++
1
Like for KASAN, it's useful to temporarily disable KMSAN checks around,
e.g., redzone accesses. Introduce kmsan_disable_current() and
kmsan_enable_current(), which are similar to their KASAN counterparts.
Make them reentrant in order to handle memory allocations in interrupt
context. Repurpose the
The constraints of the DFLTCC inline assembly are not precise: they
do not communicate the size of the output buffers to the compiler, so
it cannot automatically instrument it.
Add the manual kmsan_unpoison_memory() calls for the output buffers.
The logic is the same as in [1].
[1]
https://githu
Each s390 CPU has lowcore pages associated with it. Each CPU sees its
own lowcore at virtual address 0 through a hardware mechanism called
prefixing. Additionally, all lowcores are mapped to non-0 virtual
addresses stored in the lowcore_ptr[] array.
When lowcore is accessed through virtual address
Building the kernel with CONFIG_SLUB_DEBUG and CONFIG_KMSAN causes
KMSAN to complain about touching redzones in kfree().
Fix by extending the existing KASAN-related metadata_access_enable()
and metadata_access_disable() functions to KMSAN.
Acked-by: Vlastimil Babka
Reviewed-by: Alexander Potapen
When building the kmsan test as a module, modpost fails with the
following error message:
ERROR: modpost: "panic_on_kmsan" [mm/kmsan/kmsan_test.ko] undefined!
Export panic_on_kmsan in order to improve the KMSAN usability for
modules.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leos
KMSAN_WARN_ON() is required for implementing s390-specific KMSAN
functions, but right now it's available only to the KMSAN internal
functions. Expose it to subsystems through .
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
include/linux/kmsan.h | 25 ++
The inline assembly block in s390's chsc() stores that much.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan/instrumentation.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/kmsan/instrumentation.c b/mm/kmsan/instrumentation.c
index c
On s390 the virtual address 0 is valid (current CPU's lowcore is mapped
there), therefore KMSAN should not complain about it.
Disable the respective check on s390. There doesn't seem to be a
Kconfig option to describe this situation, so explicitly check for
s390.
Reviewed-by: Alexander Potapenko
1 - 100 of 134 matches
Mail list logo
