As for compatibility with VM_LOCKONFAULT, do we need a new
MADV_GUARD_INSTALL_LOCKED or can we say MADV_GUARD_INSTALL is new enough
that it can be just retrofitted (like you retrofit file backed mappings)?
AFAIU the only risk would be breaking somebody that already relies on a
failure for VM_LOCKO
On Tue, Feb 25, 2025 at 04:54:22PM +0100, Vlastimil Babka wrote:
> On 2/18/25 18:28, Lorenzo Stoakes wrote:
> > On Tue, Feb 18, 2025 at 06:25:35PM +0100, David Hildenbrand wrote:
> >>
> >> > > >
> >> > > > It fails because it tries to 'touch' the memory, but 'touching' guard
> >> > > > region memor
On 25.02.25 16:54, Vlastimil Babka wrote:
On 2/18/25 18:28, Lorenzo Stoakes wrote:
On Tue, Feb 18, 2025 at 06:25:35PM +0100, David Hildenbrand wrote:
It fails because it tries to 'touch' the memory, but 'touching' guard
region memory causes a segfault. This kind of breaks the idea of
mlock()
On 2/18/25 18:28, Lorenzo Stoakes wrote:
> On Tue, Feb 18, 2025 at 06:25:35PM +0100, David Hildenbrand wrote:
>>
>> > > >
>> > > > It fails because it tries to 'touch' the memory, but 'touching' guard
>> > > > region memory causes a segfault. This kind of breaks the idea of
>> > > > mlock()'ing gua
On Fri, Feb 21, 2025 at 3:04 AM Lorenzo Stoakes
wrote:
>
> On Thu, Feb 20, 2025 at 10:08:36AM -0800, Kalesh Singh wrote:
> > On Thu, Feb 20, 2025 at 8:22 AM Suren Baghdasaryan
> > wrote:
> > >
> > > On Thu, Feb 20, 2025 at 5:18 AM Lorenzo Stoakes
> > > wrote:
> > > >
> > > > On Thu, Feb 20, 202
On Thu, Feb 20, 2025 at 10:08:36AM -0800, Kalesh Singh wrote:
> On Thu, Feb 20, 2025 at 8:22 AM Suren Baghdasaryan wrote:
> >
> > On Thu, Feb 20, 2025 at 5:18 AM Lorenzo Stoakes
> > wrote:
> > >
> > > On Thu, Feb 20, 2025 at 01:44:20PM +0100, David Hildenbrand wrote:
> > > > On 20.02.25 11:15, Lo
On Thu, Feb 20, 2025 at 8:22 AM Suren Baghdasaryan wrote:
>
> On Thu, Feb 20, 2025 at 5:18 AM Lorenzo Stoakes
> wrote:
> >
> > On Thu, Feb 20, 2025 at 01:44:20PM +0100, David Hildenbrand wrote:
> > > On 20.02.25 11:15, Lorenzo Stoakes wrote:
> > > > On Thu, Feb 20, 2025 at 11:03:02AM +0100, David
On Thu, Feb 20, 2025 at 5:18 AM Lorenzo Stoakes
wrote:
>
> On Thu, Feb 20, 2025 at 01:44:20PM +0100, David Hildenbrand wrote:
> > On 20.02.25 11:15, Lorenzo Stoakes wrote:
> > > On Thu, Feb 20, 2025 at 11:03:02AM +0100, David Hildenbrand wrote:
> > > > > > Your conclusion is 'did not participate w
On Thu, Feb 20, 2025 at 01:44:20PM +0100, David Hildenbrand wrote:
> On 20.02.25 11:15, Lorenzo Stoakes wrote:
> > On Thu, Feb 20, 2025 at 11:03:02AM +0100, David Hildenbrand wrote:
> > > > > Your conclusion is 'did not participate with upstream'; I don't agree
> > > > > with
> > > > > that. But m
On 20.02.25 11:15, Lorenzo Stoakes wrote:
On Thu, Feb 20, 2025 at 11:03:02AM +0100, David Hildenbrand wrote:
Your conclusion is 'did not participate with upstream'; I don't agree with
that. But maybe you and Kalesh have a history on that that let's you react
on his questions IMHO more emotionall
On Thu, Feb 20, 2025 at 11:03:02AM +0100, David Hildenbrand wrote:
> > > Your conclusion is 'did not participate with upstream'; I don't agree with
> > > that. But maybe you and Kalesh have a history on that that let's you react
> > > on his questions IMHO more emotionally than it should have been.
Your conclusion is 'did not participate with upstream'; I don't agree with
that. But maybe you and Kalesh have a history on that that let's you react
on his questions IMHO more emotionally than it should have been.
This is wholly unfair, I have been very reasonable in response to this
thread. I
On Thu, Feb 20, 2025 at 10:22:29AM +0100, Vlastimil Babka wrote:
> On 2/20/25 09:51, Lorenzo Stoakes wrote:
> > On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
> >
> > As I said to you earlier, the _best_ we could do in smaps would be to add a
> > flag like 'Grd' or something to indic
On Thu, Feb 20, 2025 at 10:23:57AM +0100, David Hildenbrand wrote:
> On 20.02.25 10:04, Lorenzo Stoakes wrote:
> > On Thu, Feb 20, 2025 at 09:57:37AM +0100, David Hildenbrand wrote:
> > > On 20.02.25 09:51, Lorenzo Stoakes wrote:
> > > > On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
On 2/20/25 09:51, Lorenzo Stoakes wrote:
> On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
>
> As I said to you earlier, the _best_ we could do in smaps would be to add a
> flag like 'Grd' or something to indicate some part of the VMA is
In smaps we could say how many kB is covered
On 20.02.25 10:04, Lorenzo Stoakes wrote:
On Thu, Feb 20, 2025 at 09:57:37AM +0100, David Hildenbrand wrote:
On 20.02.25 09:51, Lorenzo Stoakes wrote:
On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
We also can't change smaps in the way you want, it _has_ to still give
output per
On Thu, Feb 20, 2025 at 09:57:37AM +0100, David Hildenbrand wrote:
> On 20.02.25 09:51, Lorenzo Stoakes wrote:
> > On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
> > > > We also can't change smaps in the way you want, it _has_ to still give
> > > > output per VMA information.
> > >
>
On 20.02.25 09:51, Lorenzo Stoakes wrote:
On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
We also can't change smaps in the way you want, it _has_ to still give
output per VMA information.
Sorry I wasn't suggesting to change the entries in smaps, rather
agreeing to your marker su
On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote:
> > We also can't change smaps in the way you want, it _has_ to still give
> > output per VMA information.
>
> Sorry I wasn't suggesting to change the entries in smaps, rather
> agreeing to your marker suggestion. Maybe a set of ranges f
On Wed, Feb 19, 2025 at 11:20 AM Lorenzo Stoakes
wrote:
>
> On Wed, Feb 19, 2025 at 10:52:04AM -0800, Kalesh Singh wrote:
> > On Wed, Feb 19, 2025 at 1:17 AM Lorenzo Stoakes
> > wrote:
> > >
> > > On Wed, Feb 19, 2025 at 10:15:47AM +0100, David Hildenbrand wrote:
> > > > On 19.02.25 10:03, Lorenz
On Wed, Feb 19, 2025 at 10:52:04AM -0800, Kalesh Singh wrote:
> On Wed, Feb 19, 2025 at 1:17 AM Lorenzo Stoakes
> wrote:
> >
> > On Wed, Feb 19, 2025 at 10:15:47AM +0100, David Hildenbrand wrote:
> > > On 19.02.25 10:03, Lorenzo Stoakes wrote:
> > > > On Wed, Feb 19, 2025 at 12:25:51AM -0800, Kale
On Wed, Feb 19, 2025 at 1:17 AM Lorenzo Stoakes
wrote:
>
> On Wed, Feb 19, 2025 at 10:15:47AM +0100, David Hildenbrand wrote:
> > On 19.02.25 10:03, Lorenzo Stoakes wrote:
> > > On Wed, Feb 19, 2025 at 12:25:51AM -0800, Kalesh Singh wrote:
> > > > On Thu, Feb 13, 2025 at 10:18 AM Lorenzo Stoakes
>
* Kalesh Singh [250219 03:35]:
> On Wed, Feb 19, 2025 at 12:25 AM Kalesh Singh wrote:
> >
> > On Thu, Feb 13, 2025 at 10:18 AM Lorenzo Stoakes
> > wrote:
> > >
> > > The guard regions feature was initially implemented to support anonymous
> > > mappings only, excluding shmem.
> > >
> > > This wa
On 19.02.25 10:03, Lorenzo Stoakes wrote:
On Wed, Feb 19, 2025 at 12:25:51AM -0800, Kalesh Singh wrote:
On Thu, Feb 13, 2025 at 10:18 AM Lorenzo Stoakes
wrote:
The guard regions feature was initially implemented to support anonymous
mappings only, excluding shmem.
This was done such as to in
On Wed, Feb 19, 2025 at 10:15:47AM +0100, David Hildenbrand wrote:
> On 19.02.25 10:03, Lorenzo Stoakes wrote:
> > On Wed, Feb 19, 2025 at 12:25:51AM -0800, Kalesh Singh wrote:
> > > On Thu, Feb 13, 2025 at 10:18 AM Lorenzo Stoakes
> > > wrote:
> > > >
> > > > The guard regions feature was initial
On Wed, Feb 19, 2025 at 12:35:12AM -0800, Kalesh Singh wrote:
> On Wed, Feb 19, 2025 at 12:25 AM Kalesh Singh wrote:
> >
> > On Thu, Feb 13, 2025 at 10:18 AM Lorenzo Stoakes
> > wrote:
> > >
> > > The guard regions feature was initially implemented to support anonymous
> > > mappings only, exclud
On Wed, Feb 19, 2025 at 12:25:51AM -0800, Kalesh Singh wrote:
> On Thu, Feb 13, 2025 at 10:18 AM Lorenzo Stoakes
> wrote:
> >
> > The guard regions feature was initially implemented to support anonymous
> > mappings only, excluding shmem.
> >
> > This was done such as to introduce the feature care
On Wed, Feb 19, 2025 at 12:25 AM Kalesh Singh wrote:
>
> On Thu, Feb 13, 2025 at 10:18 AM Lorenzo Stoakes
> wrote:
> >
> > The guard regions feature was initially implemented to support anonymous
> > mappings only, excluding shmem.
> >
> > This was done such as to introduce the feature carefully
On Thu, Feb 13, 2025 at 10:18 AM Lorenzo Stoakes
wrote:
>
> The guard regions feature was initially implemented to support anonymous
> mappings only, excluding shmem.
>
> This was done such as to introduce the feature carefully and incrementally
> and to be conservative when considering the variou
See mlock2();
SYSCALL_DEFINE3(mlock2, unsigned long, start, size_t, len, int, flags)
{
vm_flags_t vm_flags = VM_LOCKED;
if (flags & ~MLOCK_ONFAULT)
return -EINVAL;
if (flags & MLOCK_ONFAULT)
vm_flags |= VM_LOCKONFAULT;
return do_m
On Tue, Feb 18, 2025 at 06:25:35PM +0100, David Hildenbrand wrote:
> > >
> > > QEMU, for example, will issue an mlockall(MCL_CURRENT | MCL_FUTURE); when
> > > requested to then exit(); if it fails.
> >
> > Hm under what circumstances? I use qemu extensively to test this stuff with
> > no issues. Un
QEMU, for example, will issue an mlockall(MCL_CURRENT | MCL_FUTURE); when
requested to then exit(); if it fails.
Hm under what circumstances? I use qemu extensively to test this stuff with
no issues. Unless you mean it's using it in the 'host' code somehow.
-overcommit mem-lock=on
or (legac
On Tue, Feb 18, 2025 at 06:14:00PM +0100, David Hildenbrand wrote:
> On 18.02.25 17:43, Lorenzo Stoakes wrote:
> > On Tue, Feb 18, 2025 at 04:20:18PM +0100, David Hildenbrand wrote:
> > > > Right yeah that'd be super weird. And I don't want to add that logic.
> > > >
> > > > > Also not sure what ha
On 18.02.25 17:43, Lorenzo Stoakes wrote:
On Tue, Feb 18, 2025 at 04:20:18PM +0100, David Hildenbrand wrote:
Right yeah that'd be super weird. And I don't want to add that logic.
Also not sure what happens if one does an mlock()/mlockall() after
already installing PTE markers.
The existing l
On Tue, Feb 18, 2025 at 04:20:18PM +0100, David Hildenbrand wrote:
> > Right yeah that'd be super weird. And I don't want to add that logic.
> >
> > > Also not sure what happens if one does an mlock()/mlockall() after
> > > already installing PTE markers.
> >
> > The existing logic already handles
Right yeah that'd be super weird. And I don't want to add that logic.
Also not sure what happens if one does an mlock()/mlockall() after
already installing PTE markers.
The existing logic already handles non-present cases by skipping them, in
mlock_pte_range():
for (pte = start_pte; a
On Tue, Feb 18, 2025 at 03:35:19PM +0100, David Hildenbrand wrote:
> On 18.02.25 14:05, Lorenzo Stoakes wrote:
> > On Tue, Feb 18, 2025 at 01:12:05PM +0100, Vlastimil Babka wrote:
> > > On 2/13/25 19:16, Lorenzo Stoakes wrote:
> > > > The guard regions feature was initially implemented to support a
On 18.02.25 14:05, Lorenzo Stoakes wrote:
On Tue, Feb 18, 2025 at 01:12:05PM +0100, Vlastimil Babka wrote:
On 2/13/25 19:16, Lorenzo Stoakes wrote:
The guard regions feature was initially implemented to support anonymous
mappings only, excluding shmem.
This was done such as to introduce the fe
On Tue, Feb 18, 2025 at 01:12:05PM +0100, Vlastimil Babka wrote:
> On 2/13/25 19:16, Lorenzo Stoakes wrote:
> > The guard regions feature was initially implemented to support anonymous
> > mappings only, excluding shmem.
> >
> > This was done such as to introduce the feature carefully and increment
On 2/13/25 19:16, Lorenzo Stoakes wrote:
> The guard regions feature was initially implemented to support anonymous
> mappings only, excluding shmem.
>
> This was done such as to introduce the feature carefully and incrementally
> and to be conservative when considering the various caveats and cor
The guard regions feature was initially implemented to support anonymous
mappings only, excluding shmem.
This was done such as to introduce the feature carefully and incrementally
and to be conservative when considering the various caveats and corner
cases that are applicable to file-backed mappin
41 matches
Mail list logo
