Hi,
On 3/1/2024 10:24 PM, Miklos Szeredi wrote:
> On Wed, 28 Feb 2024 at 15:41, Hou Tao wrote:
>> 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
Hi,
On 3/1/2024 9:42 PM, Miklos Szeredi wrote:
> On Wed, 28 Feb 2024 at 15:40, Hou Tao wrote:
>
>> So instead of limiting both the values of max_read and max_write in
>> kernel, capping the maximal length of kvec iter IO by using max_pages in
>> fuse_direct_io() just like it does for ubuf/iovec
Hi,
On 2/29/2024 11:01 PM, Brian Foster wrote:
> 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
On Fri, Feb 09, 2024 at 04:29:30PM -0800, Oreoluwa Babatunde wrote:
> The unflatten_and_copy_device_tree() function contains a call to
> memblock_alloc(). This means that memblock is allocating memory before
> any of the reserved memory regions are set aside in the setup_memory()
> function which
On Tue, Mar 05, 2024 at 10:59:20AM -0800, Oreoluwa Babatunde wrote:
>
> On 2/9/2024 4:29 PM, Oreoluwa Babatunde wrote:
> > The loongarch, openric, and sh architectures allocate memory from
> > memblock before it gets the chance to set aside reserved memory regions.
> > This means that there is a
On 19.02.2024 22:43, Bryant Mairs wrote:
> Add support for this tablet based on the MSM8226 SoC, codenamed
> "milletwifi".
>
> Acked-by: Linus Walleij
> Reviewed-by: Luca Weiss
> Signed-off-by: Bryant Mairs
> ---
Reviewed-by: Konrad Dybcio
Konrad
On Fri, 8 Mar 2024 at 13:39, Linus Torvalds
wrote:
>
> So the above "complexity" is *literally* just changing the
>
> (new = atomic_read_acquire(>seq)) != old
>
> condition to
>
> should_exit ||
> (new = atomic_read_acquire(>seq)) != old
..
On Fri, 8 Mar 2024 at 13:33, Steven Rostedt wrote:
>
> There's two layers:
>
> 1) the ring buffer has the above simple producer / consumer.
>Where the wake ups can happen at the point of where the buffer has
>the amount filled that the consumer wants to start consuming with.
>
> 2) The
On Fri, 8 Mar 2024 12:39:10 -0800
Linus Torvalds wrote:
> On Fri, 8 Mar 2024 at 10:38, Steven Rostedt wrote:
> >
> > A patch was sent to "fix" the wait_index variable that is used to help with
> > waking of waiters on the ring buffer. The patch was rejected, but I started
> > looking at
On Thursday 03/07 at 22:09 +, Christophe Leroy wrote:
>
>
> Le 06/03/2024 à 21:05, Calvin Owens a écrit :
> > [Vous ne recevez pas souvent de courriers de jcalvinow...@gmail.com.
> > Découvrez pourquoi ceci est important à
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > No BPF
On Thursday 03/07 at 22:16 +, Christophe Leroy wrote:
>
>
> Le 06/03/2024 à 21:05, Calvin Owens a écrit :
> > [Vous ne recevez pas souvent de courriers de jcalvinow...@gmail.com.
> > Découvrez pourquoi ceci est important à
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > If
On Friday 03/08 at 11:46 +0900, Masami Hiramatsu wrote:
> On Wed, 6 Mar 2024 12:05:10 -0800
> Calvin Owens wrote:
>
> > If something like this is merged down the road, it can go in at leisure
> > once the module_alloc change is in: it's a one-way dependency.
> >
> > Signed-off-by: Calvin Owens
On Thursday 03/07 at 14:43 +, Christophe Leroy wrote:
> Hi Calvin,
>
> Le 06/03/2024 à 21:05, Calvin Owens a écrit :
> > [Vous ne recevez pas souvent de courriers de jcalvinow...@gmail.com.
> > Découvrez pourquoi ceci est important à
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
On Friday 03/08 at 11:16 +0900, Masami Hiramatsu wrote:
> Hi Calvin,
>
> On Wed, 6 Mar 2024 12:05:08 -0800
> Calvin Owens wrote:
>
> > Both BPF_JIT and KPROBES depend on CONFIG_MODULES, but only require
> > module_alloc() itself, which can be easily separated into a standalone
> > allocator
On Fri, 8 Mar 2024 at 10:38, Steven Rostedt wrote:
>
> A patch was sent to "fix" the wait_index variable that is used to help with
> waking of waiters on the ring buffer. The patch was rejected, but I started
> looking at associated code. Discussing it on IRC with Mathieu Desnoyers
> we
On Thursday 03/07 at 09:22 +0200, Mike Rapoport wrote:
> On Wed, Mar 06, 2024 at 12:05:10PM -0800, Calvin Owens wrote:
> > If something like this is merged down the road, it can go in at leisure
> > once the module_alloc change is in: it's a one-way dependency.
> >
> > Signed-off-by: Calvin Owens
On Thursday 03/07 at 18:55 -0800, Luis Chamberlain wrote:
> On Thu, Mar 7, 2024 at 6:50 PM Masami Hiramatsu wrote:
> >
> > On Wed, 6 Mar 2024 17:58:14 -0800
> > Song Liu wrote:
> >
> > > Hi Calvin,
> > >
> > > It is great to hear from you! :)
> > >
> > > On Wed, Mar 6, 2024 at 3:23 PM Calvin
From: "Steven Rostedt (Google)"
When the trace_pipe_raw file is closed, there should be no new readers on
the file descriptor. This is mostly handled with the waking and wait_index
fields of the iterator. But there's still a slight race.
CPU 0 CPU 1
-
From: "Steven Rostedt (Google)"
The ring_buffer_wait() needs to be broken into three functions for proper
synchronization from the context of the callers:
ring_buffer_prepare_to_wait()
ring_buffer_wait()
ring_buffer_finish_wait()
To simplify the process, pull out the logic for getting
From: "Steven Rostedt (Google)"
When the tracing_pipe_raw file is closed, if there are readers still
blocked on it, they need to be woken up. Currently a wait_index is used.
When the readers need to be woken, the index is updated and they are all
woken up.
But there is a race where a new reader
From: "Steven Rostedt (Google)"
The .release() function does not get called until all readers of a file
descriptor are finished.
If a thread is blocked on reading a file descriptor in ring_buffer_wait(),
and another thread closes the file descriptor, it will not wake up the
other thread as
From: "Steven Rostedt (Google)"
The "shortest_full" variable is used to keep track of the waiter that is
waiting for the smallest amount on the ring buffer before being woken up.
When a tasks waits on the ring buffer, it passes in a "full" value that is
a percentage. 0 means wake up on any data.
From: "Steven Rostedt (Google)"
A task can wait on a ring buffer for when it fills up to a specific
watermark. The writer will check the minimum watermark that waiters are
waiting for and if the ring buffer is past that, it will wake up all the
waiters.
The waiters are in a wait loop, and will
A patch was sent to "fix" the wait_index variable that is used to help with
waking of waiters on the ring buffer. The patch was rejected, but I started
looking at associated code. Discussing it on IRC with Mathieu Desnoyers
we discovered a design flaw.
The waiter reads "wait_index" then enters
On Fri, 08 Mar 2024 13:38:20 -0500
Steven Rostedt wrote:
> +static DEFINE_MUTEX(wait_mutex);
> +
> +static bool wait_woken_prepare(struct trace_iterator *iter, int *wait_index)
> +{
> + bool woken = false;
> +
> + mutex_lock(_mutex);
> + if (iter->waking)
> + woken =
From: "Steven Rostedt (Google)"
The ring_buffer_wait() needs to be broken into three functions for proper
synchronization from the context of the callers:
ring_buffer_prepare_to_wait()
ring_buffer_wait()
ring_buffer_finish_wait()
To simplify the process, pull out the logic for getting
From: "Steven Rostedt (Google)"
When the trace_pipe_raw file is closed, there should be no new readers on
the file descriptor. This is mostly handled with the waking and wait_index
fields of the iterator. But there's still a slight race.
CPU 0 CPU 1
-
From: "Steven Rostedt (Google)"
The .release() function does not get called until all readers of a file
descriptor are finished.
If a thread is blocked on reading a file descriptor in ring_buffer_wait(),
and another thread closes the file descriptor, it will not wake up the
other thread as
From: "Steven Rostedt (Google)"
The "shortest_full" variable is used to keep track of the waiter that is
waiting for the smallest amount on the ring buffer before being woken up.
When a tasks waits on the ring buffer, it passes in a "full" value that is
a percentage. 0 means wake up on any data.
From: "Steven Rostedt (Google)"
When the tracing_pipe_raw file is closed, if there are readers still
blocked on it, they need to be woken up. Currently a wait_index is used.
When the readers need to be woken, the index is updated and they are all
woken up.
But there is a race where a new reader
From: "Steven Rostedt (Google)"
A task can wait on a ring buffer for when it fills up to a specific
watermark. The writer will check the minimum watermark that waiters are
waiting for and if the ring buffer is past that, it will wake up all the
waiters.
The waiters are in a wait loop, and will
A patch was sent to "fix" the wait_index variable that is used to help with
waking of waiters on the ring buffer. The patch was rejected, but I started
looking at associated code. Discussing it on IRC with Mathieu Desnoyers
we discovered a design flaw.
The waiter reads "wait_index" then enters
Use tools/build/ makefiles to build rtla, inheriting the benefits of
it. For example, having a proper way to handle dependencies.
rtla is built using perf infra-structure when building inside the
kernel tree.
At this point, rtla diverges from perf in two points: Documentation
and tarball
Use tools/build/ makefiles to build rv, inheriting the benefits of
it. For example, having a proper way to handle dependencies.
Suggested-by: Linus Torvalds
Signed-off-by: Daniel Bristot de Oliveira
---
tools/verification/rv/.gitignore | 2 +
tools/verification/rv/Build | 1
Use tools/build/ makefiles to build latency-collector, inheriting
the benefits of it. For example, having a proper way to
handle dependencies.
Inspired on perf and objtool.
Suggested-by: Linus Torvalds
Signed-off-by: Daniel Bristot de Oliveira
---
tools/tracing/latency/.gitignore | 1 +
tools/tracing and tools/verification/rv are using standalone Makefiles.
However, This approach has some drawbacks. For example, code
duplication and lack of proper dependency handling, making things
harder for users.
Linus suggested using perf's build system, and it is indeed the best way to go.
Hello,
I'll start by saying that I'm sorry, I have a very very high level
knowledge about what virtio is.
On 18/12/2023 08:38:45+0100, Peter Hilber wrote:
> Expose the virtio-rtc UTC clock as an RTC clock to userspace, if it is
> present. Support RTC alarm if the virtio-rtc alarm feature is
On Thu, 7 Mar 2024 at 12:40, Abdellatif El Khlifi
wrote:
>
> Hi Mathieu,
>
> > > + do {
> > > + state_reg = readl(priv->reset_cfg.state_reg);
> > > + *rst_ack = EXTSYS_RST_ST_RST_ACK(state_reg);
> > > +
> > > + if (*rst_ack == EXTSYS_RST_ACK_RESERVED) {
> > > +
:https://lore.kernel.org/r/20240306020006.586558735%40goodmis.org
patch subject: [PATCH 8/8] ring-buffer: Validate boot range memory events
config: microblaze-allmodconfig
(https://download.01.org/0day-ci/archive/20240308/202403082327.siourqxy-...@intel.com/config)
compiler: microblaze-linux-gcc
Puranjay Mohan writes:
>> Now, I think a better approach for RISC-V would be implementing what x86
>> has (arch_ftrace_update_trampoline()), rather than CALL_OPS for RISC-V.
>>
>> Thoughts?
>
> I am going to spin some patches for implementing
> arch_ftrace_update_trampoline() for
> RISC-V, then
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this device offers a client
interface to load a firmware in the secure part.
This firmware could be authenticated by the secure trusted
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE
device-tree:
- In OP-TEE, a node is defined in the device tree with the
The new TEE remoteproc device is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without TEE support.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 84 +++-
1 file changed, 51 insertions(+), 33 deletions(-)
diff
Main updates from the previous version [1]:
- Remove the alternate boot sequence: rproc_alt_fw_boot()
- Introduce tee_rproc_parse_fw function
- create a cached table as done inrproc_elf_load_rsc_table[2],
- PR sent to OP-TEE to allow TA_RPROC_FW_CMD_LOAD_FW service
Hi Sudeep,
> > + extsys0: remoteproc@1a010310 {
> > + compatible = "arm,corstone1000-extsys";
> > + reg = <0x1a010310 0x4>,
> > + <0x1a010314 0X4>;
>
>
> As per [1], this is just a few registers within the 64kB block.
> Not
Hi Björn,
On Fri, Mar 8, 2024 at 11:16 AM Björn Töpel wrote:
> >
> > If I remember from Steven's talk, x86 uses dynamically allocated trampolines
> > for per callsite tracers, would CALL_OPS provide better performance than
> > that?
>
> Probably not, and it was really a tongue-in-cheek comment
Hi Andy,
> >
> > I don't think implementing direct calls over call ops is fruitful for
> > RISC-V because once
> > the auipc/jalr can be patched atomically, the direct call trampoline
> > is always reachable.
>
> Yes, the auipc/jalr instruction pair can be patched atomically just as
> long as
Hi Krzysztof, Sudeep,
> > > diff --git a/Documentation/devicetree/bindings/remoteproc/arm,rproc.yaml
> > > b/Documentation/devicetree/bindings/remoteproc/arm,rproc.yaml
> > > new file mode 100644
> > > index ..322197158059
> > > --- /dev/null
> > > +++
On Fri, 2024-03-08 at 11:32 +0100, Peter Hilber wrote:
> On 07.03.24 15:02, David Woodhouse wrote:
> > On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
> > > RFC v3 updates
> > > --
> > >
> > > This series implements a driver for a virtio-rtc device conforming to spec
> > > RFC
On Fri, Mar 01, 2024 at 08:30:43PM +0100, Krzysztof Kozlowski wrote:
> On 01/03/2024 17:42, abdellatif.elkhl...@arm.com wrote:
> > From: Abdellatif El Khlifi
> >
> > introduce the bindings for Arm remoteproc support.
> >
> > Signed-off-by: Abdellatif El Khlifi
> > ---
> >
On Fri, Mar 01, 2024 at 04:42:26PM +, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> add device tree node for the external system core in Corstone-1000
>
> Signed-off-by: Abdellatif El Khlifi
> ---
> arch/arm64/boot/dts/arm/corstone1000.dtsi | 10 +-
> 1 file
On 3/8/24 08:55, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 7 Mar 2024, Michael Weiß wrote:
>
>> Configuring ipvs in a non-initial user namespace using the genl
>> netlink interface, e.g., by 'ipvsadm' is currently resulting in an
>> '-EPERM'. This is due to the use of GENL_ADMIN_PERM
:https://lore.kernel.org/r/20240306020006.100449500%40goodmis.org
patch subject: [PATCH 5/8] ring-buffer: Add ring_buffer_meta data
config: s390-defconfig
(https://download.01.org/0day-ci/archive/20240308/202403081843.qykjkyk4-...@intel.com/config)
compiler: clang version 19.0.0git (https
link:https://lore.kernel.org/r/20240306020006.100449500%40goodmis.org
patch subject: [PATCH 5/8] ring-buffer: Add ring_buffer_meta data
config: sh-defconfig
(https://download.01.org/0day-ci/archive/20240308/202403081831.ewsqpo2a-...@intel.com/config)
compiler: sh4-linux-gcc (GCC) 13.2.0
On 07.03.24 15:02, David Woodhouse wrote:
> On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
>> RFC v3 updates
>> --
>>
>> This series implements a driver for a virtio-rtc device conforming to spec
>> RFC v3 [1]. It now includes an RTC class driver with alarm, in addition to
>>
Hello:
This patch was applied to netdev/net-next.git (main)
by David S. Miller :
On Mon, 4 Mar 2024 06:08:47 -0800 you wrote:
> From: Jakub Kicinski
>
> softnet_data->time_squeeze is sometimes used as a proxy for
> host overload or indication of scheduling problems. In practice
> this
Hello:
This patch was applied to netdev/net-next.git (main)
by David S. Miller :
On Tue, 5 Mar 2024 11:04:17 +0800 you 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
Puranjay Mohan writes:
> Hi Björn,
>
> On Thu, Mar 7, 2024 at 8:27 PM Björn Töpel wrote:
>>
>> Puranjay!
>>
>> Puranjay Mohan writes:
>>
>> > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
>> > This allows each ftrace callsite to provide an ftrace_ops to the common
>> >
Hi Puranjay,
On Fri, Mar 8, 2024 at 3:53 AM Puranjay Mohan wrote:
>
> Hi Björn,
>
> On Thu, Mar 7, 2024 at 8:27 PM Björn Töpel wrote:
> >
> > Puranjay!
> >
> > Puranjay Mohan writes:
> >
> > > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
> > > This allows each ftrace
On Thu, Mar 7, 2024 at 8:19 AM Puranjay Mohan wrote:
>
> Hi Alex,
>
> On Wed, Mar 6, 2024 at 9:35 PM Alexandre Ghiti wrote:
> >
> > Hi Puranjay,
> >
> > On 06/03/2024 17:59, Puranjay Mohan wrote:
> > > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
> > > This allows each
在 2024/3/7 17:26, Michal Hocko 写道:
The main reasons for adding static tracepoints are:
1. To subdivide the time spent in the shrinker->count_objects() and
shrinker->scan_objects() functions within the do_shrink_slab function. Using
BPF kprobe, we can only track the time spent in the
Hi SeongJae,
I couldn't send email to LKML properly due to internal system issues,
but it's better now so I will be able to communicate better.
On Wed, 6 Mar 2024 19:05:50 -0800 SeongJae Park wrote:
>
> Hello,
>
> On Tue, 27 Feb 2024 15:51:20 -0800 SeongJae Park wrote:
>
> > On Mon, 26 Feb
Hello,
On Thu, 7 Mar 2024, Michael Weiß wrote:
> Configuring ipvs in a non-initial user namespace using the genl
> netlink interface, e.g., by 'ipvsadm' is currently resulting in an
> '-EPERM'. This is due to the use of GENL_ADMIN_PERM flag in
> 'ip_vs_ctl.c'.
>
> Similarly to other
64 matches
Mail list logo
