> So basically you are worried about read-tearing?
>
> That wasn't mentioned in the change log.
Yes. Sorry for making this confused, I am not very familiar with this and
still learning.
> Funny part is, if the above timestamp read did a tear, then this would
> definitely not match, and would
Thanks for reviews.
Ack to all comments, I will address in next revision.
Tanmay
On 2/29/24 3:59 AM, Krzysztof Kozlowski wrote:
> On 19/02/2024 18:44, Tanmay Shah wrote:
> > From: Radhey Shyam Pandey
> >
> > Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> > UltraScale+
On Thu, Feb 29, 2024 at 02:34:35PM +0100, Linus Walleij wrote:
> On Wed, Jan 31, 2024 at 7:27 AM Yan Zhao wrote:
>
> > Apply the page shift to PFN to get physical address for final VA.
> > The macro __va should take physical address instead of PFN as input.
> >
> > Fixes: 2d78057f0dd4
On Thu, 29 Feb 2024 22:58:54 +0100
Jiri Olsa wrote:
> On Thu, Feb 29, 2024 at 08:22:47PM +0900, Masami Hiramatsu (Google) wrote:
> > From: Masami Hiramatsu (Google)
> >
> > Fix to allocate fprobe::entry_data_size buffer with rethook instances.
> > If fprobe doesn't allocate entry_data_size
On Wed, 31 Jan 2024 14:47:31 +
David Howells wrote:
> Hi Steven,
Hi David,
Sorry, I just noticed this email as it was buried in other unread emails :-p
>
> I have a tracepoint in AF_RXRPC that displays information about a timeout I'm
> going to set. I have the timeout in a ktime_t as an
On Thu, Feb 29, 2024 at 08:22:47PM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google)
>
> Fix to allocate fprobe::entry_data_size buffer with rethook instances.
> If fprobe doesn't allocate entry_data_size buffer for each rethook instance,
> fprobe entry handler can cause
From: Max Kellermann
[ Upstream commit 250f5402e636a5cec9e0e95df252c3d54307210f ]
Fixes a bug revealed by -Wmissing-prototypes when
CONFIG_FUNCTION_GRAPH_TRACER is enabled but not CONFIG_DYNAMIC_FTRACE:
arch/parisc/kernel/ftrace.c:82:5: error: no previous prototype for
From: Max Kellermann
[ Upstream commit 250f5402e636a5cec9e0e95df252c3d54307210f ]
Fixes a bug revealed by -Wmissing-prototypes when
CONFIG_FUNCTION_GRAPH_TRACER is enabled but not CONFIG_DYNAMIC_FTRACE:
arch/parisc/kernel/ftrace.c:82:5: error: no previous prototype for
From: Max Kellermann
[ Upstream commit 250f5402e636a5cec9e0e95df252c3d54307210f ]
Fixes a bug revealed by -Wmissing-prototypes when
CONFIG_FUNCTION_GRAPH_TRACER is enabled but not CONFIG_DYNAMIC_FTRACE:
arch/parisc/kernel/ftrace.c:82:5: error: no previous prototype for
From: Max Kellermann
[ Upstream commit 250f5402e636a5cec9e0e95df252c3d54307210f ]
Fixes a bug revealed by -Wmissing-prototypes when
CONFIG_FUNCTION_GRAPH_TRACER is enabled but not CONFIG_DYNAMIC_FTRACE:
arch/parisc/kernel/ftrace.c:82:5: error: no previous prototype for
From: Max Kellermann
[ Upstream commit 250f5402e636a5cec9e0e95df252c3d54307210f ]
Fixes a bug revealed by -Wmissing-prototypes when
CONFIG_FUNCTION_GRAPH_TRACER is enabled but not CONFIG_DYNAMIC_FTRACE:
arch/parisc/kernel/ftrace.c:82:5: error: no previous prototype for
From: Max Kellermann
[ Upstream commit 250f5402e636a5cec9e0e95df252c3d54307210f ]
Fixes a bug revealed by -Wmissing-prototypes when
CONFIG_FUNCTION_GRAPH_TRACER is enabled but not CONFIG_DYNAMIC_FTRACE:
arch/parisc/kernel/ftrace.c:82:5: error: no previous prototype for
Hello Mathieu,
On 2/29/24 17:19, Mathieu Poirier wrote:
> Good morning,
>
> On Wed, Feb 28, 2024 at 09:20:28AM +0100, Arnaud POULIQUEN wrote:
>> 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:
On 2/23/24 19:37, Mathieu Poirier wrote:
> On Fri, Feb 23, 2024 at 02:54:13PM +0100, Arnaud POULIQUEN wrote:
>> Hello Mathieu,
>>
>> On 2/22/24 20:02, Mathieu Poirier wrote:
>>> Hi,
>>>
>>> On Wed, Feb 14, 2024 at 06:21:27PM +0100, Arnaud Pouliquen wrote:
The new TEE remoteproc device is
From: Jason Xing
Prio to this patch, the trace function doesn't print addresses
which might be forgotten. As we can see, it already fetches
those, use it directly and it will print like below:
...tcp_retransmit_skb: skbaddr=XXX skaddr=XXX family=AF_INET...
Signed-off-by: Jason Xing
---
From: Jason Xing
Use the existing parameter and print it then. It will display
the address of skbaddr.
Signed-off-by: Jason Xing
---
include/trace/events/tcp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index
From: Jason Xing
When I reviewed other people's patch [1], I noticed that similar thing
also happens in tcp_event_skb class and tcp_event_sk_skb class. They
don't print those two addrs of skb/sk which already exist.
They are probably forgotten by the original authors, so this time I
finish the
Commit 92792ac752aa ("virtio-pci: Introduce admin command sending function")
added "__packed" structures to UAPI header linux/virtio_pci.h. This triggers
build failures in the consumer userspace applications without proper
"definition"
of __packed (e.g., kvmtool build fails).
Moreover, the
Good morning,
On Wed, Feb 28, 2024 at 09:20:28AM +0100, Arnaud POULIQUEN wrote:
> 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
://lore.kernel.org/r/1709118356-133960-1-git-send-email-wangyunjian%40huawei.com
patch subject: [PATCH net-next v2 3/3] tun: AF_XDP Tx zero-copy support
config: microblaze-randconfig-r131-20240229
(https://download.01.org/0day-ci/archive/20240229/202402292345.a49gfjlj-...@intel.com/config)
compiler
On Thu, 29 Feb 2024 20:32:26 +0800
linke wrote:
> Hi Steven, sorry for the late reply.
>
> >
> > Now the reason for the above READ_ONCE() is because the variables *are*
> > going to be used again. We do *not* want the compiler to play any games
> > with that.
> >
>
> I don't think it is
On Wed, Feb 28, 2024 at 10:41:24PM +0800, Hou Tao wrote:
> 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
>
nd-robin CPU selection forced, expect
performance impact
[9.277324][T1]
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240229/202402292204.c1f77860-oliver.s...@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Wed, Jan 31, 2024 at 7:27 AM Yan Zhao wrote:
> Apply the page shift to PFN to get physical address for final VA.
> The macro __va should take physical address instead of PFN as input.
>
> Fixes: 2d78057f0dd4 ("asm-generic/page.h: Make pfn accessors static inlines")
> Signed-off-by: Yan Zhao
> -Original Message-
> From: Paolo Abeni [mailto:pab...@redhat.com]
> Sent: Thursday, February 29, 2024 6:49 PM
> To: wangyunjian ; m...@redhat.com;
> willemdebruijn.ker...@gmail.com; jasow...@redhat.com; k...@kernel.org;
> bj...@kernel.org; magnus.karls...@intel.com;
> -Original Message-
> From: Paolo Abeni [mailto:pab...@redhat.com]
> Sent: Thursday, February 29, 2024 7:13 PM
> To: wangyunjian ; m...@redhat.com;
> willemdebruijn.ker...@gmail.com; jasow...@redhat.com; k...@kernel.org;
> bj...@kernel.org; magnus.karls...@intel.com;
> -Original Message-
> From: Paolo Abeni [mailto:pab...@redhat.com]
> Sent: Thursday, February 29, 2024 6:43 PM
> To: wangyunjian ; m...@redhat.com;
> willemdebruijn.ker...@gmail.com; jasow...@redhat.com; k...@kernel.org;
> bj...@kernel.org; magnus.karls...@intel.com;
Hi Steven, sorry for the late reply.
>
> Now the reason for the above READ_ONCE() is because the variables *are*
> going to be used again. We do *not* want the compiler to play any games
> with that.
>
I don't think it is because the variables are going to be used again.
Compiler
Hi Steven, sorry for the late reply.
>
> Now the reason for the above READ_ONCE() is because the variables *are*
> going to be used again. We do *not* want the compiler to play any games
> with that.
>
I don't think it is because the variables are going to be used again.
Compiler
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
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
---
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
patch 1 removes a useless memory barrier and patch 2 actually fixes the
issue with IPI in the patching code.
Changes in v3:
- Remove wrong cleanup as noted by Samuel
- Enhance comment about usage of release semantics as suggested by
Andrea
- Add RBs from Andrea
Changes in v2:
- Add patch 1 and
On Thu, 29 Feb 2024 20:22:47 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Fix to allocate fprobe::entry_data_size buffer with rethook instances.
> If fprobe doesn't allocate entry_data_size buffer for each rethook instance,
> fprobe entry handler can cause a
From: Masami Hiramatsu (Google)
Fix to allocate fprobe::entry_data_size buffer with rethook instances.
If fprobe doesn't allocate entry_data_size buffer for each rethook instance,
fprobe entry handler can cause a buffer overrun when storing entry data in
entry handler.
Reported-by: Jiri Olsa
On Wed, 2024-02-28 at 19:05 +0800, Yunjian Wang wrote:
> @@ -2661,6 +2776,54 @@ static int tun_ptr_peek_len(void *ptr)
> }
> }
>
> +static void tun_peek_xsk(struct tun_file *tfile)
> +{
> + struct xsk_buff_pool *pool;
> + u32 i, batch, budget;
> + void *frame;
> +
> + if
On Wed, 2024-02-28 at 19:05 +0800, Yunjian Wang wrote:
> 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.
>
>
On Wed, 2024-02-28 at 19:05 +0800, Yunjian Wang wrote:
> 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
://lore.kernel.org/r/1709118356-133960-1-git-send-email-wangyunjian%40huawei.com
patch subject: [PATCH net-next v2 3/3] tun: AF_XDP Tx zero-copy support
config: i386-randconfig-012-20240229
(https://download.01.org/0day-ci/archive/20240229/202402291828.g9c5tw50-...@intel.com/config)
compiler: gcc-7 (Ubuntu
Hello Michael,
On 2/1/24 09:40, Michael S. Tsirkin wrote:
On Thu, Feb 01, 2024 at 09:34:11AM +0100, Maxime Coquelin wrote:
Hi Jason,
It looks like all patches got acked by you.
Any blocker to queue the series for next release?
Thanks,
Maxime
I think it's good enough at this point. Will put
-- Forwarded message -
发件人： yuanli fu
Date: 2024年2月29日周四 16:27
Subject: Re: [PATCH] tcp: Add skb addr and sock addr to arguments of
tracepoint tcp_probe.
To: Jason Xing
Jason Xing 于2024年2月29日周四 15:30写道：
>
> On Thu, Feb 29, 2024 at 1:33 PM fuyuanli wrote:
> >
> > It is useful
On 19/02/2024 18:44, Tanmay Shah wrote:
> From: Radhey Shyam Pandey
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled
On Tue, Feb 27, 2024 at 4:42 AM John Fastabend wrote:
>
> Jason Wang wrote:
> > On Fri, Feb 23, 2024 at 9:42 AM Xuan Zhuo
> > wrote:
> > >
> > > On Fri, 09 Feb 2024 13:57:25 +0100, Paolo Abeni wrote:
> > > > On Fri, 2024-02-09 at 18:39 +0800, Liang Chen wrote:
> > > > > On Wed, Feb 7, 2024 at
42 matches
Mail list logo
