Hello.
On Mon, Feb 26, 2024 at 03:48:18PM -0600, Haitao Huang
wrote:
> In case of overcomitting, i.e., sum of limits greater than the EPC capacity,
> if one group has a fault, and its usage is not above its own limit
> (try_charge() passes), yet total usage of the system has exceeded the
>
On Tue, 2024-02-27 at 15:09 +0800, maobibo wrote:
> It is difficult to find an area unused by HW for CSR method since the
> small CSR ID range.
We may use IOCSR instead. In kernel/cpu-probe.c there are already some
IOCSR reads.
> It is difficult to find an area unused by HW for CSR method
Hello trace maintainers/developers,
This is a 31-day syzbot report for the trace subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/trace
During the period, 0 new issues were detected and 0 were fixed.
In total, 8 issues are still open and 29
On 2/27/24 11:14, maobibo wrote:
On 2024/2/27 上午4:02, Jiaxun Yang wrote:
在2024年2月26日二月 上午8:04，maobibo写道：
On 2024/2/26 下午2:12, Huacai Chen wrote:
On Mon, Feb 26, 2024 at 10:04 AM maobibo wrote:
On 2024/2/24 下午5:13, Huacai Chen wrote:
Hi, Bibo,
On Thu, Feb 22, 2024 at 11:28 AM Bibo
On 2024/2/27 下午5:05, Xi Ruoyao wrote:
On Tue, 2024-02-27 at 15:09 +0800, maobibo wrote:
It is difficult to find an area unused by HW for CSR method since the
small CSR ID range.
We may use IOCSR instead. In kernel/cpu-probe.c there are already some
IOCSR reads.
yes, IOCSR can be used
On 2024/2/27 下午5:10, WANG Xuerui wrote:
On 2/27/24 11:14, maobibo wrote:
On 2024/2/27 上午4:02, Jiaxun Yang wrote:
在2024年2月26日二月 上午8:04，maobibo写道：
On 2024/2/26 下午2:12, Huacai Chen wrote:
On Mon, Feb 26, 2024 at 10:04 AM maobibo wrote:
On 2024/2/24 下午5:13, Huacai Chen wrote:
Hi,
On 2/27/24 18:12, maobibo wrote:
On 2024/2/27 下午5:10, WANG Xuerui wrote:
On 2/27/24 11:14, maobibo wrote:
On 2024/2/27 上午4:02, Jiaxun Yang wrote:
在2024年2月26日二月 上午8:04，maobibo写道：
On 2024/2/26 下午2:12, Huacai Chen wrote:
On Mon, Feb 26, 2024 at 10:04 AM maobibo wrote:
On 2024/2/24
On Mon, Feb 19, 2024 at 2:09 AM Lei Yang wrote:
>
> QE tested this patch's V2, qemu no longer print error messages
> "qemu-system-x86_64: Insufficient written data (0)" after
> enable/disable multi queues multi times inside guest. Both "x-svq=on
> '' and without it are all test pass.
>
>
Hi Hans
On Tue, 27 Feb 2024 at 12:17, Hans Verkuil wrote:
>
> Ricardo,
>
> First of all, note the typo in theo subject line: vcodedc -> vcodec.
>
> There is also a similar (but not identical!) patch from Arnd:
>
>
Dear RT Folks,
This is the RT stable review cycle of patch 4.19.307-rt133-rc1.
Please scream at me if I messed something up. Please test the patches
too.
The -rc release is also available on kernel.org
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
on the
v4.19.307-rt133-rc1 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index ecff281e807f..c2c7e0fb6685 100644
Ricardo,
First of all, note the typo in theo subject line: vcodedc -> vcodec.
There is also a similar (but not identical!) patch from Arnd:
https://patchwork.linuxtv.org/project/linux-media/patch/20240224121059.1806691-1-a...@kernel.org/
That patch and yours share the change to
On Tue, Feb 27, 2024, at 12:35, Ricardo Ribalda wrote:
> On Tue, 27 Feb 2024 at 12:17, Hans Verkuil wrote:
>>
>> Ricardo,
>>
>> First of all, note the typo in theo subject line: vcodedc -> vcodec.
>>
>> There is also a similar (but not identical!) patch from Arnd:
>>
>>
On Tue, 27 Feb 2024 10:50:36 +0800 (CST)
wrote:
> include/trace/events/icmp.h | 57
> +
> net/ipv4/icmp.c | 4
> 2 files changed, 61 insertions(+)
> create mode 100644 include/trace/events/icmp.h
>
> diff --git
On Tue, Feb 27, 2024 at 06:21:46PM +0300, Dan Carpenter wrote:
> The dev->vqs[] array has "dev->vq_num" elements. It's allocated in
> vduse_dev_init_vqs(). Thus, this > comparison needs to be >= to avoid
> reading one element beyond the end of the array.
>
> Fixes: 316ecd1346b0 ("vduse: Add
Hi, Paolo,
I'm very sorry to bother you, now we have a controversy about how to
query hypervisor features (PV IPI, PV timer and maybe PV spinlock) on
LoongArch, and we have two choices:
1, Get from CPUCFG registers;
2, Get from a hypercall.
CPUCFG are unprivileged registers which can be read
The dev->vqs[] array has "dev->vq_num" elements. It's allocated in
vduse_dev_init_vqs(). Thus, this > comparison needs to be >= to avoid
reading one element beyond the end of the array.
Fixes: 316ecd1346b0 ("vduse: Add file operation for mmap")
Signed-off-by: Dan Carpenter
---
On Mon, 26 Feb 2024 12:25:58 -0600, Michal Koutný wrote:
On Mon, Feb 05, 2024 at 01:06:27PM -0800, Haitao Huang
wrote:
+static int sgx_epc_cgroup_alloc(struct misc_cg *cg);
+
+const struct misc_res_ops sgx_epc_cgroup_ops = {
+ .alloc = sgx_epc_cgroup_alloc,
+ .free =
On Mon Feb 26, 2024 at 11:56 PM EET, Dave Hansen wrote:
> On 2/26/24 13:48, Haitao Huang wrote:
> > In case of overcomitting, i.e., sum of limits greater than the EPC
> > capacity, if one group has a fault, and its usage is not above its own
> > limit (try_charge() passes), yet total usage of the
Good day,
On Fri, Feb 16, 2024 at 03:29:56PM -0800, noman pouigt wrote:
> mailbox to dsp_1 is currently modeling platform pcm driver.
> mailbox to dsp_2 is also doing the same.
>
> Platform driver callbacks cause IPC to be sent to dsp's.
> Lifecycle of two dsp's are managed by separate
From: "Steven Rostedt (Google)"
The trace_marker write goes into the ring buffer. A test was added to
write a string as big as the sub-buffer of the ring buffer to see if it
would work. A sub-buffer is typically PAGE_SIZE in length.
On PowerPC architecture, the ftrace selftest for trace_marker
On Tue, 27 Feb 2024 12:57:06 -0500
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The trace_marker write goes into the ring buffer. A test was added to
> write a string as big as the sub-buffer of the ring buffer to see if it
> would work. A sub-buffer is typically PAGE_SIZE in
On 2024/2/28 00:29, Dave Jiang wrote:
>
>
> On 2/24/24 6:47 AM, chengming.z...@linux.dev wrote:
>> From: Chengming Zhou
>>
>> The SLAB_MEM_SPREAD flag is already a no-op as of 6.8-rc1, remove
>> its usage so we can delete it from slab. No functional change.
>
> Can you please provide a Link
On Wed, 2024-02-28 at 11:16 +0800, Chengming Zhou wrote:
> On 2024/2/28 00:29, Dave Jiang wrote:
> >
> >
> > On 2/24/24 6:47 AM, chengming.z...@linux.dev wrote:
> > > From: Chengming Zhou
> > >
> > > The SLAB_MEM_SPREAD flag is already a no-op as of 6.8-rc1, remove
> > > its usage so we can
On 26/02/2024 18:32, Ricardo Ribalda wrote:
> Building with LLVM=1 throws the following warning:
> drivers/media/pci/sta2x11/sta2x11_vip.c:1057:6: warning: cast from
> 'irqreturn_t (*)(int, struct sta2x11_vip *)' (aka 'enum irqreturn (*)(int,
> struct sta2x11_vip *)') to 'irq_handler_t' (aka
alloc_contig_migrate_range has every information to be able to
understand big contiguous allocation latency. For example, how many
pages are migrated, how many times they were needed to unmap from
page tables.
This patch adds the trace event to collect the allocation statistics.
In the field, it
On Mon, 26 Feb 2024 13:56:09 +0100
Jiri Olsa wrote:
> On Mon, Feb 26, 2024 at 12:20:43AM +0900, Masami Hiramatsu (Google) wrote:
> > From: Masami Hiramatsu (Google)
> >
> > Rewrite fprobe implementation on function-graph tracer.
> > Major API changes are:
> > - 'nr_maxactive' field is
On Mon, 26 Feb 2024 23:05:46 +0900 Honggyu Kim wrote:
> There was an RFC IDEA "DAMOS-based Tiered-Memory Management" previously
> posted at [1].
>
> It says there is no implementation of the demote/promote DAMOS action
> are made. This RFC is about its implementation for physical address
>
On 2/24/24 6:47 AM, chengming.z...@linux.dev wrote:
> From: Chengming Zhou
>
> The SLAB_MEM_SPREAD flag is already a no-op as of 6.8-rc1, remove
> its usage so we can delete it from slab. No functional change.
Can you please provide a Link tag to the lore post that indicates
SLAB_MEM_SPREAD
On Tue, Feb 27, 2024 at 10:35:46AM +0800, Changbin Du wrote:
> The synchronization here is to ensure the ordering of freeing of a module
> init so that it happens before W+X checking. It is worth noting it is not
> that the freeing was not happening, it is just that our sanity checkers
> raced
30 matches
Mail list logo
