Hi Vlastimil
On Tue, Oct 22, 2024 at 8:55 AM Vlastimil Babka wrote:
>
> On 10/17/24 22:57, Jeff Xu wrote:
> > On Thu, Oct 17, 2024 at 1:49 PM Pedro Falcato
> > wrote:
> >> >
> >> > > > For file-backed, private, read-only memory mappings, we previously
> >> > > > did
> >> > > > not block the ma
Vlastimil Babka wrote:
> On 10/17/24 22:57, Jeff Xu wrote:
> > On Thu, Oct 17, 2024 at 1:49 PM Pedro Falcato
> > wrote:
> >> >
> >> > > > For file-backed, private, read-only memory mappings, we previously
> >> > > > did
> >> > > > not block the madvise(MADV_DONTNEED). This was based on
> >> >
On 10/17/24 22:57, Jeff Xu wrote:
> On Thu, Oct 17, 2024 at 1:49 PM Pedro Falcato wrote:
>> >
>> > > > For file-backed, private, read-only memory mappings, we previously did
>> > > > not block the madvise(MADV_DONTNEED). This was based on
>> > > > the assumption that the memory's content, being fi
d/20241017-085203
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
mm-everything
patch link:
https://lore.kernel.org/r/20241017005105.3047458-2-jeffxu%40chromium.org
patch subject: [PATCH v1 1/2] mseal: Two fixes for madvise(MADV_DONTNEED) when
sealed
config: i386-defconf
d/20241017-085203
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
mm-everything
patch link:
https://lore.kernel.org/r/20241017005105.3047458-2-jeffxu%40chromium.org
patch subject: [PATCH v1 1/2] mseal: Two fixes for madvise(MADV_DONTNEED) when
sealed
config: i386-allnoconf
On Thu, Oct 17, 2024 at 1:49 PM Pedro Falcato wrote:
>
> On Thu, Oct 17, 2024 at 01:34:53PM -0700, Jeff Xu wrote:
> > Hi Pedro
> >
> > On Thu, Oct 17, 2024 at 12:37 PM Pedro Falcato
> > wrote:
> > >
> > > > For PROT_NONE mappings, the previous blocking of
> > > > madvise(MADV_DONTNEED) is unnece
On Thu, Oct 17, 2024 at 01:34:53PM -0700, Jeff Xu wrote:
> Hi Pedro
>
> On Thu, Oct 17, 2024 at 12:37 PM Pedro Falcato
> wrote:
> >
> > > For PROT_NONE mappings, the previous blocking of
> > > madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
> > > memory access, madvise(MADV
Hi Pedro
On Thu, Oct 17, 2024 at 12:37 PM Pedro Falcato wrote:
>
> > For PROT_NONE mappings, the previous blocking of
> > madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
> > memory access, madvise(MADV_DONTNEED) should be allowed to proceed in
> > order to free the page.
>
>
On Thu, Oct 17, 2024 at 12:51:04AM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Two fixes for madvise(MADV_DONTNEED) when sealed.
>
Please separate these fixes into two separate patches.
> For PROT_NONE mappings, the previous blocking of
> madvise(MADV_DONTNEED) is unnecessary. As PROT
On Thu, Oct 17, 2024 at 12:51:04AM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Two fixes for madvise(MADV_DONTNEED) when sealed.
>
> For PROT_NONE mappings, the previous blocking of
> madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
> memory access, madvise(MADV_DONT
From: Jeff Xu
Two fixes for madvise(MADV_DONTNEED) when sealed.
For PROT_NONE mappings, the previous blocking of
madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
memory access, madvise(MADV_DONTNEED) should be allowed to proceed in
order to free the page.
For file-backed, p
11 matches
Mail list logo
