On Tue, 2 Jul 2024 15:33:54 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> To prevent conflicts with other ioctl numbers to allow strace to have an
> idea of what is happening, add the rang of ioctls for the trace buffer
> mapping from _IO("T", 0x1) to the range of "R" 0x20 -
On Wed, 19 Jun 2024 14:24:05 -0400
Konstantin Ryabitsev wrote:
> - drops the recommendation to use /r/ subpaths in lore.kernel.org links
> (it has been unnecessary for a number of years)
> - adds some detail on how to reference specific Link trailers from
> inside the commit message
>
> Some of
On Tue, 2 Jul 2024 15:38:10 -0400
Mathieu Desnoyers wrote:
> On 2024-07-02 15:33, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > To prevent conflicts with other ioctl numbers to allow strace to have an
> > idea of what is happening, add the rang of ioctls for the trace buffer
On 2024-07-02 15:33, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
To prevent conflicts with other ioctl numbers to allow strace to have an
idea of what is happening, add the rang of ioctls for the trace buffer
mapping from _IO("T", 0x1) to the range of "R" 0x20 - 0x2F.
Link:
https://
From: "Steven Rostedt (Google)"
To prevent conflicts with other ioctl numbers to allow strace to have an
idea of what is happening, add the rang of ioctls for the trace buffer
mapping from _IO("T", 0x1) to the range of "R" 0x20 - 0x2F.
Link:
https://lore.kernel.org/linux-trace-kernel/2024063010
On 02.07.24 13:30, Alistair Popple wrote:
David Hildenbrand writes:
On 02.07.24 12:19, Alistair Popple wrote:
David Hildenbrand writes:
On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be manage
On 02.07.24 13:46, Christoph Hellwig wrote:
On Tue, Jul 02, 2024 at 09:18:31AM +0200, David Hildenbrand wrote:
We have this comparably nasty vmf_insert_mixed() that FS dax abused to
insert into !VM_MIXED VMAs. Is that abuse now stopping and are there maybe
ways to get rid of vmf_insert_mixed()?
On Tue, Jul 02, 2024 at 08:19:01PM +1000, Alistair Popple wrote:
> > (B) As long as we have subpage mapcounts, this prevents vmemmap
> > optimizations [1]. Is that only used for device-dax for now and are
> > there no plans to make use of that for fs-dax?
>
> I don't have any plans to. Thi
David Hildenbrand writes:
> On 02.07.24 12:19, Alistair Popple wrote:
>> David Hildenbrand writes:
>>
>>> On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal page
On Tue, Jul 02, 2024 at 09:18:31AM +0200, David Hildenbrand wrote:
> We have this comparably nasty vmf_insert_mixed() that FS dax abused to
> insert into !VM_MIXED VMAs. Is that abuse now stopping and are there maybe
> ways to get rid of vmf_insert_mixed()?
Unfortunately it is also used by a few
On 02.07.24 12:19, Alistair Popple wrote:
David Hildenbrand writes:
On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce dax_insert_pfn_pud. This will map t
David Hildenbrand writes:
> On 27.06.24 02:54, Alistair Popple wrote:
>> Currently to map a DAX page the DAX driver calls vmf_insert_pfn. This
>> creates a special devmap PTE entry for the pfn but does not take a
>> reference on the underlying struct page for the mapping. This is
>> because DAX
On 02.07.24 01:47, Alistair Popple wrote:
David Hildenbrand writes:
On 27.06.24 02:54, Alistair Popple wrote:
Longterm pinning of FS DAX pages should already be disallowed by
various pXX_devmap checks. However a future change will cause these
checks to be invalid for FS DAX pages so make
fol
David Hildenbrand writes:
> On 27.06.24 02:54, Alistair Popple wrote:
>> Currently DAX folio/page reference counts are managed differently to
>> normal pages. To allow these to be managed the same as normal pages
>> introduce dax_insert_pfn_pud. This will map the entire PUD-sized folio
>> and t
On 27.06.24 02:54, Alistair Popple wrote:
Currently to map a DAX page the DAX driver calls vmf_insert_pfn. This
creates a special devmap PTE entry for the pfn but does not take a
reference on the underlying struct page for the mapping. This is
because DAX page refcounts are treated specially, as
On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce dax_insert_pfn_pud. This will map the entire PUD-sized folio
and take references as it would for a normally
16 matches
Mail list logo
