On Thu, Feb 29, 2024 at 1:33 PM fuyuanli wrote:
>
> It is useful to expose skb addr and sock addr to user in tracepoint
> tcp_probe, so that we can get more information while monitoring
> receiving of tcp data, by ebpf or other ways.
>
> For example, we need to identify a packet by seq and
On Thu, Feb 29, 2024 at 3:19 AM Stefan Hajnoczi wrote:
>
> On Wed, 28 Feb 2024 at 13:24, 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
* Stephen Boyd [240228 22:59]:
> +Tony
>
> Quoting Krzysztof Kozlowski (2024-02-24 01:12:35)
> > Several TI SoC clock bindings were marked as work-in-progress / unstable
> > between 2013-2016, for example in commit f60b1ea5ea7a ("CLK: TI: add
> > support for gate clock"). It was enough of time
It is useful to expose skb addr and sock addr to user in tracepoint
tcp_probe, so that we can get more information while monitoring
receiving of tcp data, by ebpf or other ways.
For example, we need to identify a packet by seq and end_seq when
calculate transmit latency between lay 2 and lay 4 by
On Wed, Feb 28, 2024 at 06:51:49PM +0100, Alexandre Ghiti wrote:
> For now, we use stop_machine() to patch the text and when we use IPIs for
> remote icache flushes (which is emitted in patch_text_nosync()), the system
> hangs.
>
> So instead, make sure every cpu executes the stop_machine()
On Wed, Feb 28, 2024 at 06:51:48PM +0100, Alexandre Ghiti wrote:
> This memory barrier is not needed and not documented so simply remove
> it.
>
> Suggested-by: Andrea Parri
> Signed-off-by: Alexandre Ghiti
Reviewed-by: Andrea Parri
Andrea
Quoting Krzysztof Kozlowski (2024-02-24 01:12:34)
> Keystone clock controller bindings were marked as work-in-progress /
> unstable in 2013 in commit b9e0d40c0d83 ("clk: keystone: add Keystone
> PLL clock driver") and commit 7affe5685c96 ("clk: keystone: Add gate
> control clock driver") Almost
+Tony
Quoting Krzysztof Kozlowski (2024-02-24 01:12:35)
> Several TI SoC clock bindings were marked as work-in-progress / unstable
> between 2013-2016, for example in commit f60b1ea5ea7a ("CLK: TI: add
> support for gate clock"). It was enough of time to consider them stable
> and expect usual
On Wed, 28 Feb 2024 at 16:47, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Calling an __exit function from an __init function is not allowed
> and will result in undefined behavior when the code is built-in:
>
> WARNING: modpost: vmlinux: section mismatch in reference: virtio_fs_init+0x50
>
From: Arnd Bergmann
Calling an __exit function from an __init function is not allowed
and will result in undefined behavior when the code is built-in:
WARNING: modpost: vmlinux: section mismatch in reference: virtio_fs_init+0x50
(section: .init.text) -> virtio_fs_sysfs_exit (section:
On Wed, Feb 28, 2024 at 03:22:36PM -0500, Steven Rostedt wrote:
> On Wed, 28 Feb 2024 11:38:29 -0800
> "Paul E. McKenney" wrote:
>
> > The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
> > even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
> > might see
On Wed, 28 Feb 2024 11:38:29 -0800
"Paul E. McKenney" wrote:
> The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
> even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
> might see the occasional preemption, and that this preemption just might
> happen
On Wed, 28 Feb 2024 at 12:24, Tanmay Shah wrote:
>
>
> On 2/28/24 11:08 AM, Mathieu Poirier wrote:
> > On Mon, Feb 19, 2024 at 09:44:34AM -0800, Tanmay Shah wrote:
> > > In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
> > > mode memory region as per hardware reference
The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
might see the occasional preemption, and that this preemption just might
happen within a trampoline.
Therefore, update ftrace_shutdown() to invoke
On 2/28/24 11:08 AM, Mathieu Poirier wrote:
> On Mon, Feb 19, 2024 at 09:44:34AM -0800, Tanmay Shah wrote:
> > In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
> > mode memory region as per hardware reference manual.
> >
> > | *TCM* | *R5 View* | *Linux
Hi Krzysztof,
Ping for reviews. Also have question.
I am referring this patch from patchwork link:
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240219174437.3722620-8-tanmay.s...@amd.com/
Patchwork shows that dtbs-check was failed, but I am sending dts changes in
next
On Wed, 28 Feb 2024 at 13:24, 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.
>
> Add an array_index_nospec() as well to prevent
On Wed, Feb 28, 2024 at 7:21 PM Samuel Holland
wrote:
>
> Hi Alex,
>
> On 2024-02-28 11:51 AM, Alexandre Ghiti wrote:
> > For now, we use stop_machine() to patch the text and when we use IPIs for
> > remote icache flushes (which is emitted in patch_text_nosync()), the system
> > hangs.
> >
> > So
On Wed, Feb 28, 2024 at 01:31:12PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> There are two WARN_ON*() warnings in tracepoint.h that deal with RCU
> usage. But when they trigger, especially from using a TRACE_EVENT()
> macro, the information is not very helpful and is
On Wed, Feb 28, 2024 at 01:31:12PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> There are two WARN_ON*() warnings in tracepoint.h that deal with RCU
> usage. But when they trigger, especially from using a TRACE_EVENT()
> macro, the information is not very helpful and is
On Wed, Feb 28, 2024 at 07:04:41PM +0800, Yunjian Wang wrote:
> Hi all:
>
> Now, some drivers support the zero-copy feature of AF_XDP sockets,
> which can significantly reduce CPU utilization for XDP programs.
>
> This patch set allows TUN to also support the AF_XDP Tx zero-copy
> feature. It is
From: "Steven Rostedt (Google)"
There are two WARN_ON*() warnings in tracepoint.h that deal with RCU
usage. But when they trigger, especially from using a TRACE_EVENT()
macro, the information is not very helpful and is confusing:
[ cut here ]
WARNING: CPU: 0 PID: 0 at
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.
Add an array_index_nospec() as well to prevent speculation issues.
Fixes: 316ecd1346b0 ("vduse: Add file
Hi Alex,
On 2024-02-28 11:51 AM, Alexandre Ghiti wrote:
> For now, we use stop_machine() to patch the text and when we use IPIs for
> remote icache flushes (which is emitted in patch_text_nosync()), the system
> hangs.
>
> So instead, make sure every cpu executes the stop_machine() patching
>
On Wed, Feb 28, 2024 at 12:53:28PM -0500, Stefan Hajnoczi wrote:
> On Wed, 28 Feb 2024 at 12:44, 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
On Wed, Feb 28, 2024 at 05:11:17AM +, Richard Chang wrote:
> 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
For now, we use stop_machine() to patch the text and when we use IPIs for
remote icache flushes (which is emitted in patch_text_nosync()), the system
hangs.
So instead, make sure every cpu executes the stop_machine() patching
function and emit a local icache flush there.
Co-developed-by: Björn
On Wed, 28 Feb 2024 at 12:44, 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.
>
> Add an array_index_nospec() as well to prevent
This memory barrier is not needed and not documented so simply remove
it.
Suggested-by: Andrea Parri
Signed-off-by: Alexandre Ghiti
---
arch/riscv/kernel/patch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
index
patch 1 removes a useless memory barrier and patch 2 actually fixes the
issue with IPI in the patching code.
Changes in v2:
- Add patch 1 and then remove the memory barrier from patch 2 as
suggested by Andrea
- Convert atomic_inc into an atomic_inc with release semantics as
suggested by
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.
Add an array_index_nospec() as well to prevent speculation issues.
Fixes: 316ecd1346b0 ("vduse: Add file
On Tue, Feb 27, 2024 at 10:48:49AM -0500, Michael S. Tsirkin wrote:
> 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
On 2/28/24 11:06 AM, Mathieu Poirier wrote:
> On Mon, Feb 19, 2024 at 09:44:37AM -0800, Tanmay Shah wrote:
> > ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> > is available in device-tree. Parse TCM information in driver
> > as per new bindings.
> >
> > Signed-off-by:
On Mon, Feb 19, 2024 at 09:44:34AM -0800, Tanmay Shah wrote:
> In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
> mode memory region as per hardware reference manual.
>
> | *TCM* | *R5 View* | *Linux view* |
> | R5_0 ATCM (128 KB) | 0x_ |
On Mon, Feb 19, 2024 at 09:44:37AM -0800, Tanmay Shah wrote:
> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> is available in device-tree. Parse TCM information in driver
> as per new bindings.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v11:
> - Remove
On Wed, 28 Feb 2024 10:52:52 -0500
Steven Rostedt wrote:
> The prototype of fchownat() is:
>
> int fchmodat(int dirfd, const char *pathname, mode_t mode, int flags);
>
> Where pathname is the third parameter, not the first, and mode is the third.
I meant pathname is the second parameter.
On Wed, 28 Feb 2024 17:25:40 +0300
Максим Морсков wrote:
> Dear colleagues,
> One last question — is it bug or feature that trobe event tracing can not
> correctly dereference string pointers from pt_regs?
> For example:
> echo 't:tmy_chmod sys_enter id=$arg2 filename=+8($arg1):string
>
On Wed, 28 Feb 2024 05:11:17 +
Richard Chang wrote:
> 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
From: Hou Tao
To prevent unnecessary request for large contiguous physical memory
chunk, use bounce buffer backed by scattered pages for ITER_KVEC
direct-io read/write when the total size of its args is greater than
PAGE_SIZE.
Signed-off-by: Hou Tao
---
fs/fuse/virtio_fs.c | 78
From: Hou Tao
When invoking virtio_fs_enqueue_req() through kworker, both the
allocation of the sg array and the bounce buffer still use GFP_ATOMIC.
Considering the size of the sg array may be greater than PAGE_SIZE, use
GFP_NOFS instead of GFP_ATOMIC to lower the possibility of memory
From: Hou Tao
When reading a file kept in virtiofs from kernel (e.g., insmod a kernel
module), if the cache of virtiofs is disabled, the read buffer will be
passed to virtiofs through out_args[0].value instead of pages. Because
virtiofs can't get the pages for the read buffer,
From: Hou Tao
Factor out more common methods for bounce buffer of fuse args:
1) virtio_fs_argbuf_setup_sg: set-up sgs for bounce buffer
2) virtio_fs_argbuf_copy_from_in_arg: copy each in-arg to bounce buffer
3) virtio_fs_argbuf_out_args_offset: calc the start offset of out-arg
4)
From: Hou Tao
The bounce buffer for fuse args in virtiofs will be extended to support
scatterd pages later. Therefore, move the allocation and the free of
argbuf out of the copy procedures and factor them into
virtio_fs_argbuf_{new|free}() helpers.
Signed-off-by: Hou Tao
---
From: Hou Tao
Hi,
The patch set aims to fix the warning related to an abnormal size
parameter of kmalloc() in virtiofs. The warning occurred when attempting
to insert a 10MB sized kernel module kept in a virtiofs with cache
disabled. As analyzed in patch #1, the root cause is that the length of
From: Hou Tao
When trying to insert a 10MB kernel module kept in a virtio-fs with cache
disabled, the following warning was reported:
[ cut here ]
WARNING: CPU: 2 PID: 439 at mm/page_alloc.c:4544 ..
Modules linked in:
CPU: 2 PID: 439 Comm: insmod Not tainted
Wed, Feb 28, 2024 at 12:04:41PM CET, wangyunj...@huawei.com wrote:
>Hi all:
>
>Now, some drivers support the zero-copy feature of AF_XDP sockets,
>which can significantly reduce CPU utilization for XDP programs.
>
>This patch set allows TUN to also support the AF_XDP Tx zero-copy
>feature. It is
This patch set allows TUN to support the AF_XDP Tx zero-copy feature,
which can significantly reduce CPU utilization for XDP programs.
Since commit fc72d1d54dd9 ("tuntap: XDP transmission"), the pointer
ring has been utilized to queue different types of pointers by encoding
the type into the
If TUN supports AF_XDP TX zero-copy, the XDP program will enqueue
packets to the XDP ring and wake up the vhost worker. This requires
the vhost worker to call peek_len(), which can be used to consume
XDP descriptors.
Signed-off-by: Yunjian Wang
---
drivers/vhost/net.c | 17 -
1
Now dma mappings are used by the physical NICs. However the vNIC
maybe do not need them. So remove non-zero 'dma_page' check in
xp_assign_dev.
Signed-off-by: Yunjian Wang
---
net/xdp/xsk_buff_pool.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/net/xdp/xsk_buff_pool.c
Hi all:
Now, some drivers support the zero-copy feature of AF_XDP sockets,
which can significantly reduce CPU utilization for XDP programs.
This patch set allows TUN to also support the AF_XDP Tx zero-copy
feature. It is based on Linux 6.8.0+(openEuler 23.09) and has
successfully passed Netperf
The page frag in vhost_net_page_frag_refill() uses the
'struct page_frag' from skb_page_frag_refill(), but it's
implementation is similar to page_frag_alloc_align() now.
This patch removes vhost_net_page_frag_refill() by using
'struct page_frag_cache' instead of 'struct page_frag',
and allocating
introduce vhost_net_test for both vhost_net tx and rx basing
on virtio_test to test vhost_net changing in the kernel.
Steps for vhost_net tx testing:
1. Prepare a out buf.
2. Kick the vhost_net to do tx processing.
3. Do the receiving in the tun side.
4. verify the data received by tun is
Currently there seems to be three page frag implementations
which all try to allocate order 3 page, if that fails, it
then fail back to allocate order 0 page, and each of them
all allow order 3 page allocation to fail under certain
condition by using specific gfp bits.
The gfp bits for order 3
Hello Mathieu,
On 2/23/24 19:27, Mathieu Poirier wrote:
> On Wed, Feb 14, 2024 at 06:21:21PM +0100, Arnaud Pouliquen wrote:
>> From: Arnaud Pouliquen
>>
>> Add a remoteproc TEE (Trusted Execution Environment) driver
>> that will be probed by the TEE bus. If the associated Trusted
>> application
On 26/02/2024 18:32, Ricardo Ribalda wrote:
> Building with LLVM=1 throws the following warning:
> drivers/media/usb/pvrusb2/pvrusb2-context.c:110:6: warning: cast from 'void
> (*)(struct pvr2_context *)' to 'void (*)(void *)' converts to incompatible
> function type
55 matches
Mail list logo
