All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>, Jann Horn <jannh@google.com>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>, Shuah Khan <shuah@kernel.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	Tal Zussman <tz2294@columbia.edu>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] mm/madvise: zap markers from guard regions
Date: Fri, 13 Nov 2026 22:39:30 +0100	[thread overview]
Message-ID: <a502f84a-b349-487d-94d9-aff7d9b95102@kernel.org> (raw)
In-Reply-To: <avd8-uVPf6BSqwEQ@gremlin>

>>>  mm/madvise.c | 28 +++++++++++++++++++---------
>>>  1 file changed, 19 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/mm/madvise.c b/mm/madvise.c
>>> index 0214efd2a014..4f7728583207 100644
>>> --- a/mm/madvise.c
>>> +++ b/mm/madvise.c
>>> @@ -850,6 +850,19 @@ static int madvise_free_single_vma(struct madvise_behavior *madv_behavior)
>>>  	return 0;
>>>  }
>>>
>>> +static void zap_range(struct madvise_behavior *madv_behavior,
>>> +		      zap_flags_t flags)
>>
>> Two ... ;) But maybe it's consistent like that in the file, didn't check.
> 
> I'm a bit exhausted, can you or Andrew just fix up whitespace like this on
> application?
> 
> It'll be easier when I have the VMA tree.

Yeah, absolutely. I'll let Andrew pick this one.

> 
>>
>>> +{
>>> +	const struct madvise_behavior_range *range = &madv_behavior->range;
>>> +	struct zap_details details = {
>>> +		.reclaim_pt = true,
>>> +		.zap_flags = flags,
>>> +	};
>>> +
>>> +	zap_vma_range_batched(madv_behavior->tlb, madv_behavior->vma,
>>> +			      range->start, range->end - range->start, &details);
>>> +}
>>> +
>>>  /*
>>>   * Application no longer needs these pages.  If the pages are dirty,
>>>   * it's OK to just throw them away.  The app will be more careful about
>>> @@ -872,13 +885,7 @@ static int madvise_free_single_vma(struct madvise_behavior *madv_behavior)
>>>  static long madvise_dontneed_single_vma(struct madvise_behavior *madv_behavior)
>>>
>>>  {
>>> -	struct madvise_behavior_range *range = &madv_behavior->range;
>>> -	struct zap_details details = {
>>> -		.reclaim_pt = true,
>>> -	};
>>> -
>>> -	zap_vma_range_batched(madv_behavior->tlb, madv_behavior->vma,
>>> -			      range->start, range->end - range->start, &details);
>>> +	zap_range(madv_behavior, 0);
>>>  	return 0;
>>>  }
>>>
>>> @@ -1217,9 +1224,11 @@ static long madvise_guard_install(struct madvise_behavior *madv_behavior)
>>>
>>>  		/*
>>>  		 * OK some of the range have non-guard pages mapped, zap
>>> -		 * them. This leaves existing guard pages in place.
>>> +		 * them. This also drops any PTE markers in the range,
>>> +		 * including existing guard markers, which we reinstall on
>>> +		 * the next attempt.
>>>  		 */
>>> -		zap_vma_range(vma, range->start, range->end - range->start);
>>> +		zap_range(madv_behavior, ZAP_FLAG_DROP_MARKER);
>>>  	}
>>>
>>>  	/*
>>> @@ -1845,6 +1854,7 @@ static bool madvise_batch_tlb_flush(int behavior)
>>>  	case MADV_DONTNEED:
>>>  	case MADV_DONTNEED_LOCKED:
>>>  	case MADV_FREE:
>>> +	case MADV_GUARD_INSTALL:
>>
>> Huh why that change? Not spelled out above.
> 
> It's just the established way madvise interacts with TLB maintenance.
> 
> Anything that uses madv_behaviour->tlb has to return true here so
> madvise_init_tlb() and madvise_finish_tlb() do the right thing.

Ohhh, I see now.

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David


  reply	other threads:[~2026-11-13 21:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 21:04 [PATCH v2] mm/madvise: zap markers from guard regions Lorenzo Stoakes (ARM)
2026-11-13 21:10 ` David Hildenbrand (Arm)
2026-11-13 21:18   ` Lorenzo Stoakes (ARM)
2026-11-13 21:39     ` David Hildenbrand (Arm) [this message]
2026-11-13 21:40       ` Lorenzo Stoakes (ARM)
2026-11-13 21:10 ` Lorenzo Stoakes (ARM)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a502f84a-b349-487d-94d9-aff7d9b95102@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=tz2294@columbia.edu \
    --cc=vbabka@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.