In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
referenced patch should be replaced with lockdep_assert_held(_write)().
Replace those, and additionally, replace a couple of other
WARN_ON_ONCE() introduced in the same patch for actual failure
cases (i.e. when acquiring a semaphor
On Tue, 2024-04-02 at 11:34 +0800, maobibo wrote:
> Are you sure that it's impossible to read some data used by the kernel
> internally?
Yes.
> There is another issue, since kernel restore T0-T7 registers and user
> space save T0-T7. Why T0-T7 is scratch registers rather than preserve
> registe
On Sun, Mar 31, 2024 at 11:11:10PM +0800, kernel test robot wrote:
> kernel test robot noticed "UBSAN:shift-out-of-bounds_in_fs/proc/page.c" on:
>
> commit: 30e5296811312a13938b83956a55839ac1e3aa40 ("[PATCH 7/9] mm: Free up
> PG_slab")
Quite right. Spotted another one while I was at it. Not ab
On Mon, Apr 1, 2024 at 7:30 PM James Houghton wrote:
>
> Participate in bitmap-based aging while grabbing the KVM MMU lock for
> reading. Ideally we wouldn't need to grab this lock at all, but that
> would require a more intrustive and risky change.
^^ intrusive
This
On Fri, Mar 22, 2024 at 08:59:12AM +0100, Luca Weiss wrote:
> On Mon Dec 4, 2023 at 6:28 PM CET, Manivannan Sadhasivam wrote:
> > On Mon, Dec 04, 2023 at 01:21:42PM +0100, Luca Weiss wrote:
> > > On Mon Dec 4, 2023 at 1:15 PM CET, Nitin Rawat wrote:
> > > >
> > > >
> > > > On 12/4/2023 3:54 PM, Luc
On 2024/4/2 上午10:49, Xi Ruoyao wrote:
On Tue, 2024-04-02 at 09:43 +0800, maobibo wrote:
Sorry for the late reply, but I think it may be a bit non-constructive
to repeatedly submit the same code without due explanation in our
previous review threads. Let me try to recollect some of the details
From: Wardenjohn
In livepatch, using KLP_UNDEFINED is seems to be confused.
When kernel is ready, livepatch is ready too, which state is
idle but not undefined. What's more, if one livepatch process
is finished, the klp state should be idle rather than undefined.
Therefore, using KLP_IDLE to rep
From: Wardenjohn
---
include/linux/livepatch.h | 1 +
kernel/livepatch/patch.c | 2 +-
kernel/livepatch/transition.c | 24
3 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 9b9b38e89563
On 2024/4/2 上午10:49, Xi Ruoyao wrote:
On Tue, 2024-04-02 at 09:43 +0800, maobibo wrote:
Sorry for the late reply, but I think it may be a bit non-constructive
to repeatedly submit the same code without due explanation in our
previous review threads. Let me try to recollect some of the details
On Tue, Apr 02, 2024 at 09:50:54AM +0800, Ubisectech Sirius wrote:
> > On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> > Recently, our team has discovered a issue in Linux kernel 6.7. Atta
On Tue, 2024-04-02 at 09:43 +0800, maobibo wrote:
> > Sorry for the late reply, but I think it may be a bit non-constructive
> > to repeatedly submit the same code without due explanation in our
> > previous review threads. Let me try to recollect some of the details
> > though...
> Because your
On 2024/3/24 上午3:02, WANG Xuerui wrote:
On 3/15/24 16:07, Bibo Mao wrote:
Instruction cpucfg can be used to get processor features. And there
is trap exception when it is executed in VM mode, and also it is
to provide cpu features to VM. On real hardware cpucfg area 0 - 20
is used. Here one
Make cgroup test scripts ash compatible.
Remove cg-tools dependency.
Add documentation for functions.
Tested with busybox on Ubuntu.
Signed-off-by: Haitao Huang
---
v2:
- Fixes for v2 cgroup
- Turn off swapping before memcontrol tests and back on after
- Add comments and reformat
---
tools/test
On 2024/3/24 上午2:40, WANG Xuerui wrote:
On 3/15/24 16:11, Bibo Mao wrote:
[snip]
+KVM hypercall ABI
+=
+
+Hypercall ABI on KVM is simple, only one scratch register a0 and at most
+five generic registers used as input parameter. FP register and
vector register
+is not used for
The current implementation treats emulated memory devices, such as
CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
(E820_TYPE_RAM). However, these emulated devices have different
characteristics than traditional DRAM, making it important to
distinguish them. Thus, we mod
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
Reviewed-by: "Huang, Ying"
---
drivers/dax/kmem.c | 20 ++--
When a memory device, such as CXL1.1 type3 memory, is emulated as
normal memory (E820_TYPE_RAM), the memory device is indistinguishable from
normal DRAM in terms of memory tiering with the current implementation.
The current memory tiering assigns all detected normal memory nodes to
the same DRAM t
On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel 6.7. Attached to
> the email were a PoC file of the issue.
Thank you for the report!
On 4/1/24 6:39 PM, Hari Nagalla wrote:
On 3/25/24 12:20, Andrew Davis wrote:
The kernel FIFO queue has a couple issues. The biggest issue is that
it causes extra latency in a path that can be used in real-time tasks,
such as communication with real-time remote processors.
The whole FIFO idea it
On 4/1/24 6:31 PM, Hari Nagalla wrote:
On 3/25/24 12:20, Andrew Davis wrote:
static int omap_mbox_chan_send_noirq(struct omap_mbox *mbox, u32 msg)
{
- int ret = -EBUSY;
+ if (mbox_fifo_full(mbox))
+ return -EBUSY;
- if (!mbox_fifo_full(mbox)) {
- omap_mbox_enable_irq(m
On 3/25/24 12:20, Andrew Davis wrote:
The kernel FIFO queue has a couple issues. The biggest issue is that
it causes extra latency in a path that can be used in real-time tasks,
such as communication with real-time remote processors.
The whole FIFO idea itself looks to be a leftover from before
On 3/25/24 12:20, Andrew Davis wrote:
static int omap_mbox_chan_send_noirq(struct omap_mbox *mbox, u32 msg)
{
- int ret = -EBUSY;
+ if (mbox_fifo_full(mbox))
+ return -EBUSY;
- if (!mbox_fifo_full(mbox)) {
- omap_mbox_enable_irq(mbox, IRQ_RX);
-
From: Yu Zhao
Use mmu_notifier_{test,clear}_young_bitmap() to handle KVM PTEs in
batches when the fast path is supported. This reduces the contention on
kvm->mmu_lock when the host is under heavy memory pressure.
An existing selftest can quickly demonstrate the effectiveness of
this patch. On a
Participate in bitmap-based aging while grabbing the KVM MMU lock for
reading. Ideally we wouldn't need to grab this lock at all, but that
would require a more intrustive and risky change. Also pass
KVM_PGTABLE_WALK_SHARED, as this software walker is safe to run in
parallel with other walkers.
It
Only handle the TDP MMU case for now. In other cases, if a bitmap was
not provided, fallback to the slowpath that takes mmu_lock, or, if a
bitmap was provided, inform the caller that the bitmap is unreliable.
Suggested-by: Yu Zhao
Signed-off-by: James Houghton
---
arch/x86/include/asm/kvm_host.
From: Yu Zhao
tdp_mmu_enabled and shadow_accessed_mask are needed to implement
kvm_arch_prepare_bitmap_age().
Signed-off-by: Yu Zhao
Signed-off-by: James Houghton
---
arch/x86/include/asm/kvm_host.h | 6 ++
arch/x86/kvm/mmu.h | 6 --
arch/x86/kvm/mmu/spte.h | 1 -
Add kvm_arch_prepare_bitmap_age() for architectures to indiciate that
they support bitmap-based aging in kvm_mmu_notifier_test_clear_young()
and that they do not need KVM to grab the MMU lock for writing. This
function allows architectures to do other locking or other preparatory
work that it needs
The bitmap is provided for secondary MMUs to use if they support it. For
test_young(), after it returns, the bitmap represents the pages that
were young in the interval [start, end). For clear_young, it represents
the pages that we wish the secondary MMU to clear the accessed/young bit
for.
If a b
To allow new MMU-notifier-related functions to use gfn_to_hva_memslot(),
move some declarations around.
Also move mmu_notifier_to_kvm() for wider use later.
Signed-off-by: James Houghton
---
include/linux/kvm_host.h | 41 +---
virt/kvm/kvm_main.c | 5 --
This patchset adds a fast path in KVM to test and clear access bits on
sptes without taking the mmu_lock. It also adds support for using a
bitmap to (1) test the access bits for many sptes in a single call to
mmu_notifier_test_young, and to (2) clear the access bits for many ptes
in a single call t
Hi SeongJae,
On Mon, Apr 1, 2024 at 11:27 AM Ho-Ren (Jack) Chuang
wrote:
>
> Hi SeongJae,
>
> On Sun, Mar 31, 2024 at 12:09 PM SeongJae Park wrote:
> >
> > Hi Ho-Ren,
> >
> > On Fri, 29 Mar 2024 05:33:52 + "Ho-Ren (Jack) Chuang"
> > wrote:
> >
> > > Since different memory devices require f
On Mon, 01 Apr 2024 09:22:21 -0500, Jarkko Sakkinen
wrote:
On Sun Mar 31, 2024 at 8:44 PM EEST, Haitao Huang wrote:
Make cgroup test scripts ash compatible.
Remove cg-tools dependency.
Add documentation for functions.
Tested with busybox on Ubuntu.
Signed-off-by: Haitao Huang
I'll run t
Fix a small typo in the smatch documentation about the patch submission
process.
Signed-off-by: Javier Carrasco
---
Documentation/submitting-patches.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/submitting-patches.md
b/Documentation/submitting-patches.md
i
Convert existing smatch documentation to RST, and add it to the index
accordingly.
Signed-off-by: Javier Carrasco
---
Documentation/index.rst | 1 +
Documentation/{smatch.txt => smatch.rst} | 56 +---
2 files changed, 31 insertions(+), 26 deletions(-)
renam
A few examples use the '~/progs/smatch/devel/smatch_scripts/' path,
which seems to be a local reference that does not reflect the real
paths in the project (one would not expect 'devel' inside 'smatch').
Use the generic '~/path/to/smatch_dir/' path, which is already used
in some examples.
Signed-
This series converts the existing smatch.txt to RST and adds it to the
index, so it can be built together with the sparse documentation.
When at it, a couple of small fixes has been included.
Signed-off-by: Javier Carrasco
Javier Carrasco (3):
Documentation/smatch: fix paths in the examples
Hi SeongJae,
On Sun, Mar 31, 2024 at 12:09 PM SeongJae Park wrote:
>
> Hi Ho-Ren,
>
> On Fri, 29 Mar 2024 05:33:52 + "Ho-Ren (Jack) Chuang"
> wrote:
>
> > Since different memory devices require finding, allocating, and putting
> > memory types, these common steps are abstracted in this patc
Add node describing wireless connectivity subsystem.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 104 ++
1 file changed, 104 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 776
Add Adreno GPU node.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 65 +++
1 file changed, 65 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 6be310079f5b..77670fce9b8f 100644
--
Add MDSS nodes to support displays on MSM8976 SoC.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 274 +-
1 file changed, 270 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm64/boot/dts/qcom/msm8976.
Add the nodes describing the apps and gpu iommu and its context banks
that are found on msm8976 SoCs.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 81 +++
1 file changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b
This patch series provide support for display subsystem, gpu
and also adds wireless connectivity subsystem support.
Changes since v1
1. Addressed feedback
2. Dropped already applied dt-bindings patches
3. Dropped sdc patch as it was submitted as part of other series
4. Dropped dt-
During rework somehow msm8976 num_clk got removed, restore it.
Fixes: d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus clocks")
Signed-off-by: Adam Skladowski
---
drivers/clk/qcom/clk-smd-rpm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/d
Currently, the microcode field (Microcode Revision) of struct mce is not
exported to userspace through the mce_record tracepoint.
Knowing the microcode version on which the MCE was received is critical
information for debugging. If the version is not recorded, later attempts
to acquire the version
Machine Check Error information from struct mce is exported to userspace
through the mce_record tracepoint.
Currently, however, the PPIN (Protected Processor Inventory Number) field
of struct mce is not exported through the tracepoint.
Export PPIN through the tracepoint as it provides a unique id
This patchset updates the mce_record tracepoint so that the recently added
fields of struct mce are exported through it to userspace.
The first patch adds PPIN (Protected Processor Inventory Number) field to
the tracepoint.
The second patch adds the microcode field (Microcode Revision) to the
tra
On Thu, Mar 28, 2024 at 11:26:24AM -0500, Andrew Davis wrote:
> On 3/28/24 10:28 AM, Mathieu Poirier wrote:
> > Hi Andrew,
> >
> > On Mon, Mar 25, 2024 at 11:58:06AM -0500, Andrew Davis wrote:
> > > The type of message sent using omap-mailbox is always u32. The definition
> > > of mbox_msg_t is ui
On Fri, Mar 29, 2024 at 09:58:11AM +0100, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 3/27/24 18:07, Mathieu Poirier wrote:
> > On Tue, Mar 26, 2024 at 08:18:23PM +0100, Arnaud POULIQUEN wrote:
> >> Hello Mathieu,
> >>
> >> On 3/25/24 17:46, Mathieu Poirier wrote:
> >>> On Fri, Mar 08, 2024 at
On Fri, Mar 29, 2024 at 11:57:43AM +0100, Arnaud POULIQUEN wrote:
>
>
> On 3/27/24 18:14, Mathieu Poirier wrote:
> > On Tue, Mar 26, 2024 at 08:31:33PM +0100, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 3/25/24 17:51, Mathieu Poirier wrote:
> >>> On Fri, Mar 08, 2024 at 03:47:08PM +0100, Arnaud Pou
On Sun, 31 Mar 2024 16:20:30 -0400 Michael S. Tsirkin wrote:
> > Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.")
> > Cc: sta...@vger.kernel.org
>
> net has its own stable process, don't CC stable on net patches.
Not any more, FWIW:
1.5.7. Stable tree
While it used
On Mon, 01 Apr 2024 00:10:42 +0300, Dmitry Baryshkov wrote:
> MSM8996 has limited glink support, allow glink-edge node on MSM8996
> platform.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml | 1 -
> 1 file changed, 1 deletion(-
On Mon Apr 1, 2024 at 12:29 PM EEST, Huang, Kai wrote:
> On Sat, 2024-03-30 at 13:17 +0200, Jarkko Sakkinen wrote:
> > On Thu Mar 28, 2024 at 2:53 PM EET, Huang, Kai wrote:
> > >
> > > > --- /dev/null
> > > > +++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.c
> > > > @@ -0,0 +1,74 @@
> > > > +// SPDX-Lice
On Sun Mar 31, 2024 at 8:44 PM EEST, Haitao Huang wrote:
> Make cgroup test scripts ash compatible.
> Remove cg-tools dependency.
> Add documentation for functions.
>
> Tested with busybox on Ubuntu.
>
> Signed-off-by: Haitao Huang
I'll run this next week on good old NUC7. Thank you.
I really wi
On Mon, Apr 1, 2024 at 8:34 PM wrote:
>
> From: hepeilin
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application experienc
On Sun Mar 31, 2024 at 8:35 PM EEST, Haitao Huang wrote:
> On Sun, 31 Mar 2024 11:19:04 -0500, Jarkko Sakkinen
> wrote:
>
> > On Sat Mar 30, 2024 at 5:32 PM EET, Haitao Huang wrote:
> >> On Sat, 30 Mar 2024 06:15:14 -0500, Jarkko Sakkinen
> >> wrote:
> >>
> >> > On Thu Mar 28, 2024 at 5:54 AM E
KASAN reports a bug:
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
Read of size 8 at addr 888141d40010 by task insmod/424
CPU: 8 PID: 424 Comm: insmod Tainted: GW 6.9.0-rc2+ #213
[...]
Call Trace:
dump_stack_lvl+0x68/0xa0
print_report+0xcf/0x610
From: hepeilin
Introduce a tracepoint for icmp_send, which can help users to get more
detail information conveniently when icmp abnormal events happen.
1. Giving an usecase example:
=
When an application experiences packet loss due to an unreachable UDP
destination po
On Sat, 2024-03-30 at 13:17 +0200, Jarkko Sakkinen wrote:
> On Thu Mar 28, 2024 at 2:53 PM EET, Huang, Kai wrote:
> >
> > > --- /dev/null
> > > +++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.c
> > > @@ -0,0 +1,74 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +// Copyright(c) 2022 Intel Corporation
Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the
email were a PoC file of the issue.
Stack dump:
general protection fault, probably for non-canonical address
0xff1f1b1f1f1f1f24: [
Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the
email were a PoC file of the issue.
Stack dump:
general protection fault, probably for non-canonical address
0xdc001cc6: [
60 matches
Mail list logo
