Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel
6.8.0-rc1-gecb1b8288dc7. Attached to the email were a POC file of the issue.
Stack dump:
rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: {
Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel
6.8.0-rc2-g6764c317b6bb. Attached to the email were a POC file of the issue.
Stack dump:
rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: {
On Wed, Jan 31, 2024 at 09:54:04AM +0530, Krishna chaitanya chundru wrote:
> This change adds ftrace support for following functions which
> helps in debugging the issues when there is Channel state & MHI
> state change and also when we receive data and control events:
> 1. mhi_intvec_mhi_states
>
On Wed, Jan 31, 2024 at 09:54:04AM +0530, Krishna chaitanya chundru wrote:
> This change adds ftrace support for following functions which
> helps in debugging the issues when there is Channel state & MHI
> state change and also when we receive data and control events:
> 1. mhi_intvec_mhi_states
>
On Sat, Feb 3, 2024 at 12:20 AM Jesper Dangaard Brouer wrote:
>
>
>
> On 02/02/2024 13.11, Liang Chen wrote:
> > The RSS hash report is a feature that's part of the virtio specification.
> > Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
> > (still a work in progress as
On Fri, Feb 2, 2024 at 6:56 AM Alexandru Elisei
wrote:
>
> Hi Peter,
>
> On Thu, Feb 01, 2024 at 08:02:40PM -0800, Peter Collingbourne wrote:
> > On Thu, Jan 25, 2024 at 8:45 AM Alexandru Elisei
> > wrote:
> > >
> > > Linux restores tags when a page is swapped in and there are tags
> > >
On Fri, Feb 2, 2024 at 6:56 AM Alexandru Elisei
wrote:
>
> Hi Peter,
>
> On Thu, Feb 01, 2024 at 08:02:40PM -0800, Peter Collingbourne wrote:
> > On Thu, Jan 25, 2024 at 8:45 AM Alexandru Elisei
> > wrote:
> > >
> > > Linux restores tags when a page is swapped in and there are tags
> > >
Hi Tim,
On Fri, 02 Feb 2024 17:45:05 -0600, Tim Chen
wrote:
On Mon, 2024-01-22 at 09:20 -0800, Haitao Huang wrote:
@@ -1047,29 +1037,38 @@ static struct mem_cgroup
*sgx_encl_get_mem_cgroup(struct sgx_encl *encl)
* @encl: an enclave pointer
* @page_index:enclave page
On Mon, 2024-01-22 at 09:20 -0800, Haitao Huang wrote:
>
> @@ -1047,29 +1037,38 @@ static struct mem_cgroup
> *sgx_encl_get_mem_cgroup(struct sgx_encl *encl)
> * @encl:an enclave pointer
> * @page_index: enclave page index
> * @backing: data for accessing backing storage for the
On Thu, Jan 25, 2024 at 8:44 AM Alexandru Elisei
wrote:
>
> Before enabling MTE tag storage management, make sure that the CMA areas
> have been successfully activated. If a CMA area fails activation, the pages
> are kept as reserved. Reserved pages are never used by the page allocator.
>
> If
On Fri, Feb 02, 2024 at 11:55:34AM -0600, Hari Nagalla wrote:
> K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
> The remote processor's life cycle management and IPC mechanisms are
> similar across the R5F and M4F cores from remote processor driver
> point of view. However,
On 2/2/2024 1:14 PM, Andrew Davis wrote:
> On 2/2/24 2:51 PM, Unnathi Chalicheemala wrote:
>>
>>
>> On 1/23/2024 10:46 AM, Andrew Davis wrote:
>>> Use the device lifecycle managed allocation function. This helps prevent
>>> mistakes like freeing out of order in cleanup functions and forgetting to
On 2/2/24 2:51 PM, Unnathi Chalicheemala wrote:
On 1/23/2024 10:46 AM, Andrew Davis wrote:
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
On 1/23/2024 10:46 AM, Andrew Davis wrote:
> Use the device lifecycle managed allocation function. This helps prevent
> mistakes like freeing out of order in cleanup functions and forgetting to
> free on error paths.
>
> Signed-off-by: Andrew Davis
> ---
> drivers/remoteproc/qcom_q6v5_wcss.c
On Thu, Feb 01, 2024 at 07:33:35PM +0100, Arnaud POULIQUEN wrote:
>
>
> On 2/1/24 17:02, Mathieu Poirier wrote:
> > On Thu, Feb 01, 2024 at 04:06:37PM +0100, Arnaud POULIQUEN wrote:
> >> hello Mathieu,
> >>
> >> On 1/31/24 19:52, Mathieu Poirier wrote:
> >>> On Tue, Jan 30, 2024 at 10:13:48AM
On Fri, 02 Feb 2024 11:55:34 -0600, Hari Nagalla wrote:
> K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
> The remote processor's life cycle management and IPC mechanisms are
> similar across the R5F and M4F cores from remote processor driver
> point of view. However, there
User_events now has multi-format events which allow for the same
register name, but with different formats. When this occurs, different
tracepoints are created with unique names.
Add a new test that ensures the same name can be used for two different
formats. Ensure they are isolated from each
Currently user_events supports 1 event with the same name and must have
the exact same format when referenced by multiple programs. This opens
an opportunity for malicous or poorly thought through programs to
create events that others use with different formats. Another scenario
is user programs
The current code for finding and deleting events assumes that there will
never be cases when user_events are registered with the same name, but
different formats. In the future this scenario will exist to ensure
user programs can be updated or modify their events and run different
versions of
User programs can now ask user_events to handle the synchronization of
multiple different formats for an event with the same name via the new
USER_EVENT_REG_MULTI_FORMAT flag.
Add a section for USER_EVENT_REG_MULTI_FORMAT that explains the intended
purpose and caveats of using it. Explain how
Currently user_events supports 1 event with the same name and must have
the exact same format when referenced by multiple programs. This opens
an opportunity for malicous or poorly thought through programs to
create events that others use with different formats. Another scenario
is user programs
On Tue, Jan 23, 2024 at 12:46:32PM -0600, Andrew Davis wrote:
> Use the device lifecycle managed allocation function. This helps prevent
> mistakes like freeing out of order in cleanup functions and forgetting to
> free on error paths.
>
> Signed-off-by: Andrew Davis
> ---
>
On Thu, Feb 01, 2024 at 03:27:54PM +0100, Marco Pagani wrote:
>
> On 2024-01-30 21:47, Luis Chamberlain wrote:
> >
> > It very much sounds like there is a desire to have this but without a
> > user, there is no justification.
>
> I was working on a set of patches to fix an issue in the fpga
On Sat, 3 Feb 2024 00:01:26 +0900 Masahiro Yamada wrote:
> I do not see why it is useful.
> As you discussed in 3/4, if UTS_RELEASE is unneeded,
> it is better to get rid of it.
To be clear - the discussion on 3/4 was about the fact that netdev
already prints UTS_RELEASE into the version member
On Sat, Feb 03, 2024 at 12:20:38AM +0900, Masahiro Yamada wrote:
> On Fri, Feb 2, 2024 at 3:05 AM Luis Chamberlain wrote:
> >
> > On Wed, Jan 31, 2024 at 02:11:44PM -0800, Luis Chamberlain wrote:
> > > On Mon, Jan 29, 2024 at 11:26:39AM -0800, Luis Chamberlain wrote:
> > > > Masahiro, if there no
Hi Andrew,
On Tue, Jan 23, 2024 at 12:49:09PM -0600, Andrew Davis wrote:
> Use the device lifecycle managed TI-SCI get() function. This helps prevent
> mistakes like not put()'ing in the wrong order in cleanup functions and
> forgetting to put() on error paths.
>
> Signed-off-by: Andrew Davis
>
Hi!
> > --- /dev/null
> > +++ b/drivers/usb/typec/anx7688.c
> > @@ -0,0 +1,1866 @@
> > +/*
> > + * ANX7688 USB-C HDMI bridge/PD driver
> > + *
>
>
>
> Did this pass checkpatch? I need a spdx line for new files please,
> don't force us to go back and guess in the future, that isn't nice.
From: Martyn Welch
In the next commit we will be adding the M4F driver which shares a lot of
commonality with the DSP driver. Move this shared functionality out so
that it can be used by both drivers.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
---
Changes since v2:
- New patch
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and starting the M4F
Enable CONFIG_TI_K3_M4_REMOTEPROC
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.
Signed-off-by: Hari Nagalla
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Martyn Welch
We will be adding the M4F driver which shares a lot of commonality
with the DSP driver. Common data structures are introduced here.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
---
Changes since v5:
- Created a separate patch for data structures to ease review
The following series introduces K3 M4F remoteproc driver support for
AM64x and AM62x SoC families. These SoCs have a ARM Cortex M4F core in
the MCU voltage domain. For safety oriented applications, this core is
operated independently with out any IPC to other cores on the SoC.
However, for non
On Fri, Feb 2, 2024 at 3:35 PM Yan Zhao wrote:
> Remove the broken pfn_to_virt() on architectures csky/hexagon/openrisc.
>
> The pfn_to_virt() on those architectures takes PFN instead of PA as the
> input to macro __va(), with PAGE_SHIFT applying to the converted VA, which
> is not right,
Dear RT Folks,
This is the RT stable review cycle of patch 4.19.306-rt132-rc1.
I reverted one -rt specific commit to be able to merge the 4.19.306
release:
0cb152421350 ("crypto: scompress - serialize RT percpu scratch buffer access
with a local lock")
because the stable backport
This reverts commit 0cb152421350004d4dcf3a4523d88c002d0a7973.
The stable backport f8f261f9ade2 ("crypto: scompress - Use per-CPU
struct instead multiple variables") replaces this downstream workaround.
Signed-off-by: Daniel Wagner
---
crypto/scompress.c | 6 ++
1 file changed, 2
Hello,
On Fri, Feb 02, 2024 at 10:34:29AM -0600, Haitao Huang wrote:
> @tj, I had your Reviewed-by tags previously but dropped it due to some
> changes for refactoring suggested by other reviewers. Could you take a look
> at patches 1-2 for MiscController and confirm if I can have your
From: Jakub Kicinski
softnet_data->time_squeeze is sometimes used as a proxy for
host overload or indication of scheduling problems. In practice
this statistic is very noisy and has hard to grasp units -
e.g. is 10 squeezes a second to be expected, or high?
Delaying network (NAPI) processing
On Thu, 01 Feb 2024 17:28:32 -0600, Jarkko Sakkinen
wrote:
On Tue Jan 30, 2024 at 4:09 AM EET, Haitao Huang wrote:
From: Sean Christopherson
Introduce a data structure to wrap the existing reclaimable list and its
spinlock. Each cgroup later will have one instance of this structure to
On Thu, 01 Feb 2024 17:24:40 -0600, Jarkko Sakkinen
wrote:
On Tue Jan 30, 2024 at 4:09 AM EET, Haitao Huang wrote:
From: Kristen Carlson Accardi
The misc cgroup controller (subsystem) currently does not perform
resource type specific action for Cgroups Subsystem State (CSS) events:
the
On Fri, Feb 2, 2024 at 4:49 PM Andy Shevchenko
wrote:
>
> On Mon, Nov 20, 2023 at 07:19:44PM +0200, Andy Shevchenko wrote:
> > On Mon, Nov 20, 2023 at 04:11:54PM +0100, Rafael J. Wysocki wrote:
> > > On Mon, Nov 20, 2023 at 4:03 PM Andy Shevchenko
> > > wrote:
> > > > On Thu, Oct 19, 2023 at
On 02/02/2024 13.11, Liang Chen wrote:
The RSS hash report is a feature that's part of the virtio specification.
Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
(still a work in progress as per [1]) support this feature. While the
capability to obtain the RSS hash has
On Fri, Feb 2, 2024, at 15:05, Yan Zhao wrote:
> Remove the broken pfn_to_virt() on architectures csky/hexagon/openrisc.
>
> The pfn_to_virt() on those architectures takes PFN instead of PA as the
> input to macro __va(), with PAGE_SHIFT applying to the converted VA, which
> is not right,
On Mon, Nov 20, 2023 at 07:19:44PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 20, 2023 at 04:11:54PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Nov 20, 2023 at 4:03 PM Andy Shevchenko
> > wrote:
> > > On Thu, Oct 19, 2023 at 06:03:28PM -0700, Dan Williams wrote:
> > > > Andy Shevchenko wrote:
>
On Fri, Feb 2, 2024 at 3:05 AM Luis Chamberlain wrote:
>
> On Wed, Jan 31, 2024 at 02:11:44PM -0800, Luis Chamberlain wrote:
> > On Mon, Jan 29, 2024 at 11:26:39AM -0800, Luis Chamberlain wrote:
> > > Masahiro, if there no issues feel free to take this or I can take them in
> > > too via the
On Wed, Jan 31, 2024 at 7:49 PM John Garry wrote:
>
> When hacking it is a waste of time and compute energy that we need to
> rebuild much kernel code just for changing the head git commit, like this:
>
> > touch include/generated/utsrelease.h
> > time make -j3
> mkdir -p
Hi Peter,
On Thu, Feb 01, 2024 at 08:02:40PM -0800, Peter Collingbourne wrote:
> On Thu, Jan 25, 2024 at 8:45 AM Alexandru Elisei
> wrote:
> >
> > Linux restores tags when a page is swapped in and there are tags associated
> > with the swap entry which the new page will replace. The saved tags
On Fri, Feb 02, 2024 at 08:04:34AM +0100, Arnd Bergmann wrote:
> On Fri, Feb 2, 2024, at 02:02, Yan Zhao wrote:
> > On Thu, Feb 01, 2024 at 06:46:46AM +0100, Arnd Bergmann wrote:
> >>
> >> I think it's fair to assume we won't need asm-generic/page.h any
> >> more, as we likely won't be adding new
Remove the broken pfn_to_virt() on architectures csky/hexagon/openrisc.
The pfn_to_virt() on those architectures takes PFN instead of PA as the
input to macro __va(), with PAGE_SHIFT applying to the converted VA, which
is not right, especially when there's a non-zero offset in __va(). [1]
The
Linus,
On Fri, 02 Feb 2024, Karel Balej wrote:
> Lee Jones, 2024-02-02T12:45:50+00:00:
> > On Thu, 01 Feb 2024, Karel Balej wrote:
> >
> > > Lee Jones, 2024-01-31T11:03:11+00:00:
> > > > On Sun, 28 Jan 2024, Karel Balej wrote:
> > > > > > > + /* GPIO1: DVC, GPIO0: input */
> > > > > > > +
Hello Steve,
On 02.02.24 02:46, Steven Rostedt wrote:
> On Thu, 1 Feb 2024 13:21:37 +0100
> Ahmad Fatoum wrote:
>> For this to be maximally useful, I need to configure this not only at
>> boot-time,
>> but also dump the ftrace buffer at boot time. Probe deferral can hinder the
>> kernel from
Hello Masami-san,
On 02.02.24 07:04, Masami Hiramatsu (Google) wrote:
> On Thu, 1 Feb 2024 13:21:37 +0100
> Ahmad Fatoum wrote:
>> For drivers that don't call dev_err_probe, I find myself sometimes doing
>> printf
>> debugging inside the probe function.
[snip]
>> I would like to replace this
Lee Jones, 2024-02-02T12:45:50+00:00:
> On Thu, 01 Feb 2024, Karel Balej wrote:
>
> > Lee Jones, 2024-01-31T11:03:11+00:00:
> > > On Sun, 28 Jan 2024, Karel Balej wrote:
> > > > > > + /* GPIO1: DVC, GPIO0: input */
> > > > > > + REG_SEQ0(PM88X_REG_GPIO_CTRL1, 0x40),
> > > > >
> > > > >
On Thu, 01 Feb 2024, Karel Balej wrote:
> Lee Jones, 2024-01-31T11:03:11+00:00:
> > On Sun, 28 Jan 2024, Karel Balej wrote:
> > > > > + /* GPIO1: DVC, GPIO0: input */
> > > > > + REG_SEQ0(PM88X_REG_GPIO_CTRL1, 0x40),
> > > >
> > > > Shouldn't you set these up using Pintrl?
> > >
> > >
On 2024/2/2 16:36, Paolo Abeni wrote:
> On Fri, 2024-02-02 at 10:10 +0800, Yunsheng Lin wrote:
>> On 2024/2/1 21:16, Paolo Abeni wrote:
>>
>>> from the __page_frag_cache_refill() allocator - which never accesses
>>> the memory reserves.
>>
>> I am not really sure I understand the above commemt.
>>
On 2024/2/2 12:05, Jason Wang wrote:
> On Tue, Jan 30, 2024 at 7:38 PM Yunsheng Lin wrote:
>>
>> introduce vhost_net_test basing on virtio_test to test
>> vhost_net changing in the kernel.
>
> Let's describe what kind of test is being done and how it is done here.
How about something like
On 27.01.2024 18:32, Luca Weiss wrote:
> On Freitag, 26. Jänner 2024 00:50:43 CET Konrad Dybcio wrote:
>> On 1/25/24 22:56, Luca Weiss wrote:
>>> From: Vladimir Lypak
>>>
>>> Add the GPU node for the Adreno 506 found on this family of SoCs. The
>>> clock speeds are a bit different per SoC
On 27.01.2024 18:24, Luca Weiss wrote:
> On Freitag, 26. Jänner 2024 00:49:55 CET Konrad Dybcio wrote:
>> On 1/25/24 23:24, Dmitry Baryshkov wrote:
>>> On 25/01/2024 23:56, Luca Weiss wrote:
From: Vladimir Lypak
Add the IOMMU used for the GPU on MSM8953.
Signed-off-by:
The RSS hash report is a feature that's part of the virtio specification.
Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
(still a work in progress as per [1]) support this feature. While the
capability to obtain the RSS hash has been enabled in the normal path,
it's
On Wed, 31 Jan 2024 18:01:41 -0500, Jeff Layton wrote:
> I'm not sure this is much prettier than the last, but contracting
> "fl_core" to "c", as Neil suggested is a bit easier on the eyes.
>
> I also added a few small helpers and converted several users over to
> them. That reduces the size of
On Fri, Feb 2, 2024 at 5:58 PM Xuan Zhuo wrote:
>
> On Fri, 2 Feb 2024 17:25:02 +0800, Liang Chen
> wrote:
> > On Thu, Feb 1, 2024 at 1:37 PM Jason Wang wrote:
> > >
> > > On Wed, Jan 31, 2024 at 11:55 AM Liang Chen
> > > wrote:
> > > >
> > > > The RSS hash report is a feature that's part of
On Fri, 2 Feb 2024 17:25:02 +0800, Liang Chen wrote:
> On Thu, Feb 1, 2024 at 1:37 PM Jason Wang wrote:
> >
> > On Wed, Jan 31, 2024 at 11:55 AM Liang Chen
> > wrote:
> > >
> > > The RSS hash report is a feature that's part of the virtio specification.
> > > Currently, virtio backends like
On Thu, Feb 1, 2024 at 1:37 PM Jason Wang wrote:
>
> On Wed, Jan 31, 2024 at 11:55 AM Liang Chen wrote:
> >
> > The RSS hash report is a feature that's part of the virtio specification.
> > Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
> > (still a work in progress as
On Fri, 2024-02-02 at 10:10 +0800, Yunsheng Lin wrote:
> On 2024/2/1 21:16, Paolo Abeni wrote:
>
> > from the __page_frag_cache_refill() allocator - which never accesses
> > the memory reserves.
>
> I am not really sure I understand the above commemt.
> The semantic is the same as
Add sched_[start, finish]_task_selection trace events to measure the
latency of PE patches in task selection.
Moreover, introduce trace events for interesting events in PE:
1. sched_pe_enqueue_sleeping_task: a task gets enqueued on wait queue of
a sleeping task (mutex owner).
2.
65 matches
Mail list logo
