On Thu, 11 Jan 2024, Karel Balej wrote:
> On Thu Jan 11, 2024 at 4:25 PM CET, Lee Jones wrote:
>
> [...]
>
> > > > > diff --git a/include/linux/mfd/88pm88x.h b/include/linux/mfd/88pm88x.h
> > > > > index a34c57447827..9a335f6b9c07 100644
> > > > > --- a/include/linux/mfd/88pm88x.h
> > > > > +++
On Fri, Jan 12, 2024 at 12:18 AM Mike Christie
wrote:
>
> On 1/10/24 9:09 PM, Jason Wang wrote:
> > On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
> > wrote:
> >>
> >> To pass ownership of a live vdpa device to a new process, the user
> >> suspends the device, calls VHOST_NEW_OWNER to change the
On Thu, 11 Jan 2024 11:34:58 -0500
Mathieu Desnoyers wrote:
> The LTTng kernel tracer has supported mmap'd buffers for nearly 15 years [1],
> and has a lot of similarities with this patch series.
>
> LTTng has the notion of "subbuffer id" to allow atomically exchanging a
> "reader" extra subbuf
On Thu, 11 Jan 2024 22:01:32 +0100
Christian Brauner wrote:
> What I'm pointing out in the current logic is that the caller is
> taxed twice:
>
> (1) Once when the VFS has done inode_permission(MAY_EXEC, "xfs")
> (2) And again when you call lookup_one_len() in eventfs_start_creating()
> _bec
-Galo/mm-Update-mark_victim-tracepoints-fields/20240111-081635
> base: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
> patch link:
> https://lore.kernel.org/r/20240111001155.746-1-carlosgalo%40google.com
> patch subject: [PATCH] mm: Update mark_victim tracepoints fields
> config: x8
The current implementation of the mark_victim tracepoint provides only
the process ID (pid) of the victim process. This limitation poses
challenges for userspace tools that need additional information
about the OOM victim. The association between pid and the additional
data may be lost after the ki
On Wed, Jan 10, 2024 at 08:07:46AM -0500, Steven Rostedt wrote:
> On Wed, 10 Jan 2024 12:45:36 +0100
> Christian Brauner wrote:
>
> > So say you do:
> >
> > mkdir /sys/kernel/tracing/instances/foo
> >
> > After this has returned we know everything we need to know about the new
> > tracefs insta
Hi Carlos,
kernel test robot noticed the following build errors:
[auto build test ERROR on 0dd3ee31125508cd67f7e7172247f05b7fd1753a]
url:
https://github.com/intel-lab-lkp/linux/commits/Carlos-Galo/mm-Update-mark_victim-tracepoints-fields/20240111-081635
base
On 2024-01-11 11:17, Vincent Donnefort wrote:
In preparation for allowing the user-space to map a ring-buffer, add
a set of mapping functions:
ring_buffer_{map,unmap}()
ring_buffer_map_fault()
And controls on the ring-buffer:
ring_buffer_map_get_reader() /* swap reader and head */
M
On 1/10/24 9:09 PM, Jason Wang wrote:
> On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
> wrote:
>>
>> To pass ownership of a live vdpa device to a new process, the user
>> suspends the device, calls VHOST_NEW_OWNER to change the mm, and calls
>> VHOST_IOTLB_REMAP to change the user virtual address
It is now possible to mmap() a ring-buffer to stream its content. Add
some documentation and a code example.
Signed-off-by: Vincent Donnefort
diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
index 5092d6c13af5..0b300901fd75 100644
--- a/Documentation/trace/index.rst
+++
Currently, user-space extracts data from the ring-buffer via splice,
which is handy for storage or network sharing. However, due to splice
limitations, it is imposible to do real-time analysis without a copy.
A solution for that problem is to let the user-space map the ring-buffer
directly.
The m
In preparation for allowing the user-space to map a ring-buffer, add
a set of mapping functions:
ring_buffer_{map,unmap}()
ring_buffer_map_fault()
And controls on the ring-buffer:
ring_buffer_map_get_reader() /* swap reader and head */
Mapping the ring-buffer also involves:
A unique I
In preparation for the ring-buffer memory mapping where each subbuf will
be accessible to user-space, zero all the page allocations.
Signed-off-by: Vincent Donnefort
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 173d2595ce2d..db73e326fa04 100644
--- a/kernel/trace/ri
The tracing ring-buffers can be stored on disk or sent to network
without any copy via splice. However the later doesn't allow real time
processing of the traces. A solution is to give userspace direct access
to the ring-buffer pages via a mapping. An application can now become a
consumer of the ri
On Thu Jan 11, 2024 at 4:25 PM CET, Lee Jones wrote:
[...]
> > > > diff --git a/include/linux/mfd/88pm88x.h b/include/linux/mfd/88pm88x.h
> > > > index a34c57447827..9a335f6b9c07 100644
> > > > --- a/include/linux/mfd/88pm88x.h
> > > > +++ b/include/linux/mfd/88pm88x.h
> > > > @@ -49,6 +49,8 @@ s
On Thu, 11 Jan 2024, Karel Balej wrote:
> Lee,
>
> On Thu Jan 11, 2024 at 11:54 AM CET, Lee Jones wrote:
> > The subject needs work. Please tell us what the patches is doing.
> >
> > On Thu, 28 Dec 2023, Karel Balej wrote:
> >
> > > From: Karel Balej
> >
> > A full an complete commit message is
Lee,
On Thu Jan 11, 2024 at 11:54 AM CET, Lee Jones wrote:
> The subject needs work. Please tell us what the patches is doing.
>
> On Thu, 28 Dec 2023, Karel Balej wrote:
>
> > From: Karel Balej
>
> A full an complete commit message is a must.
I have not provided a detailed description here bec
On Mon, 8 Jan 2024 15:03:21 +
Mark Rutland wrote:
> On Mon, Jan 08, 2024 at 02:21:03PM +, Mark Rutland wrote:
> > On Mon, Jan 08, 2024 at 12:25:55PM +, Mark Rutland wrote:
> > > We also have HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, but since the return
> > > address is
> > > not on the stac
Hi Mark,
On Thu, 11 Jan 2024 11:01:56 +
Mark Rutland wrote:
> On Thu, Jan 11, 2024 at 11:15:33AM +0900, Masami Hiramatsu wrote:
> > Hi Mark,
> >
> > Thanks for the investigation.
>
> Hi!
>
> As a heads-up, I already figured out the problem and sent a fixup at:
>
> https://lore.kernel.o
Hi Aiswarya,
I was looking into VirtIO audio controls support in Linux and came across this
patch series, which seems to be marked "archived" on patchwork [0]. I would
love to be able to use this with mainline Linux. I'm wondering about the status
of this series - is the feature still under dev
Hi Carlos,
kernel test robot noticed the following build errors:
[auto build test ERROR on 0dd3ee31125508cd67f7e7172247f05b7fd1753a]
url:
https://github.com/intel-lab-lkp/linux/commits/Carlos-Galo/mm-Update-mark_victim-tracepoints-fields/20240111-081635
base
IPQ6018 has 32 tcsr_mutex hwlock registers with stride 0x1000.
The compatible string qcom,ipq6018-tcsr-mutex is mapped to
of_msm8226_tcsr_mutex which has 32 locks configured with stride of 0x80
and doesn't match the HW present in IPQ6018.
Remove IPQ6018 specific compatible string so that it fallsb
Il 10/01/24 20:16, Konrad Dybcio ha scritto:
On 1/9/24 12:24, Luca Weiss wrote:
On Tue Jan 9, 2024 at 11:09 AM CET, Konrad Dybcio wrote:
On 1/5/24 15:54, Luca Weiss wrote:
Configure the thermals for the PA_THERM1, MSM_THERM, PA_THERM0,
RFC_CAM_THERM, CAM_FLASH_THERM and QUIET_THERM thermis
On Thu, Jan 11, 2024 at 11:15:33AM +0900, Masami Hiramatsu wrote:
> Hi Mark,
>
> Thanks for the investigation.
Hi!
As a heads-up, I already figured out the problem and sent a fixup at:
https://lore.kernel.org/lkml/ZZwEz8HsTa2IZE3L@FVFF77S0Q05N/
... and a more refined fix at:
https://lore.
The subject needs work. Please tell us what the patches is doing.
On Thu, 28 Dec 2023, Karel Balej wrote:
> From: Karel Balej
A full an complete commit message is a must.
> Signed-off-by: Karel Balej
> ---
> drivers/mfd/88pm88x.c | 14 --
> include/linux/mfd/88pm88x.h | 2
[...]
> > > + */
> > > + smp_wmb();
> > > + WRITE_ONCE(cpu_buffer->mapped, 1);
> > > +
> > > + /* Init meta_page values unless the writer did it already */
> > > + cmpxchg(&cpu_buffer->meta_page->entries, 0,
> > > + local_read(&cpu_buffer->entries));
> > > + cmpxchg(&cpu_buffer->meta_page
On Tue, Jan 09, 2024 at 06:58:13PM -0500, Steven Rostedt wrote:
> On Wed, 10 Jan 2024 08:42:05 +0900
> Masami Hiramatsu (Google) wrote:
>
> > On Tue, 9 Jan 2024 15:13:51 +
> > Vincent Donnefort wrote:
> >
> > > > > @@ -388,6 +389,7 @@ struct rb_irq_work {
> > > > > bool
On Thu, Jan 11, 2024 at 6:25 AM Michael S. Tsirkin wrote:
>
> On Sat, Nov 04, 2023 at 01:16:33AM +0800, Cindy Lu wrote:
> >
> > Hi All
> > This code provides the iommufd support for vdpa device
> > This code fixes the bugs from the last version and also add the asid
> > support. rebase on kernel
On Wed Jan 10, 2024 at 8:16 PM CET, Konrad Dybcio wrote:
>
>
> On 1/9/24 12:24, Luca Weiss wrote:
> > On Tue Jan 9, 2024 at 11:09 AM CET, Konrad Dybcio wrote:
> >>
> >>
> >> On 1/5/24 15:54, Luca Weiss wrote:
> >>> Configure the thermals for the PA_THERM1, MSM_THERM, PA_THERM0,
> >>> RFC_CAM_THERM,
On 10.01.24 07:22, Zheyun Shen wrote:
For now, SEV pins guest's memory to avoid swapping or
moving ciphertext, but leading to the inhibition of
Memory Ballooning.
In Memory Ballooning, only guest's free pages will be relocated
in balloon inflation and deflation, so the difference of plaintext
do
For now, SEV pins guest's memory to avoid swapping or
moving ciphertext, but leading to the inhibition of
Memory Ballooning.
In Memory Ballooning, only guest's free pages will be relocated
in balloon inflation and deflation, so the difference of plaintext
doesn't matter to guest.
This seems on
32 matches
Mail list logo
