[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <p2agopwbhdt7nin7wdjjggz3o2wuh4gnqaspoxfemirrjoofls@cg4o4lalbpyw>
Date: Tue, 14 Jan 2025 14:43:17 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: dave.hansen@...ux.intel.com, kirill.shutemov@...ux.intel.com
Cc: Shakeel Butt <shakeel.butt@...ux.dev>, SeongJae Park <sj@...nel.org>,
David Hildenbrand <david@...hat.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>, Pavel Begunkov <asml.silence@...il.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Ryan Roberts <ryan.roberts@....com>
Subject: untagged_addr_remote() in do_madvise()
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
Powered by blists - more mailing lists