linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: dave.hansen@linux.intel.com, kirill.shutemov@linux.intel.com
Cc: Shakeel Butt <shakeel.butt@linux.dev>,
	SeongJae Park <sj@kernel.org>,
	David Hildenbrand <david@redhat.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Pavel Begunkov <asml.silence@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Ryan Roberts <ryan.roberts@arm.com>
Subject: untagged_addr_remote() in do_madvise()
Date: Tue, 14 Jan 2025 14:43:17 -0500	[thread overview]
Message-ID: <p2agopwbhdt7nin7wdjjggz3o2wuh4gnqaspoxfemirrjoofls@cg4o4lalbpyw> (raw)

Hello,

I noticed that mm/madivse.c:do_madvise() calls untagged_addr_remote()
after validating start.

Looking through git blame shows that this line was moved in
428e106ae1ad4 ("mm: Introduce untagged_addr_remote()") [1], with the
reason being:

    The new helper untagged_addr_remote() has to be used when the address
    targets remote process. It requires the mmap lock for target mm to be
    taken.

Although this may be needed, we cannot move the untagging below
validating the start/end because we have not validated the start/end
that will be used for the operation, or at least, isn't clear why it's
okay?

Can anyone tell me why the code today is correct?  That is, how can we
trust the validation of start/end is still okay after we change the
start/end by untagging the start?

I think we have to move the locking and the untagging above the
validation for this to work as expected?

[1] https://lore.kernel.org/all/20230312112612.31869-6-kirill.shutemov@linux.intel.com/

Thanks,
Liam


             reply	other threads:[~2025-01-14 19:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-14 19:43 Liam R. Howlett [this message]
2025-01-14 20:15 ` Dave Hansen
2025-01-14 20:41 ` Lorenzo Stoakes
2025-01-14 21:13   ` Dave Hansen
2025-01-15 11:55     ` Lorenzo Stoakes

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=p2agopwbhdt7nin7wdjjggz3o2wuh4gnqaspoxfemirrjoofls@cg4o4lalbpyw \
    --to=liam.howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=ryan.roberts@arm.com \
    --cc=shakeel.butt@linux.dev \
    --cc=sj@kernel.org \
    --cc=vbabka@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox