[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <914d2224-d659-4ee6-989b-b6917fc97298@lucifer.local>
Date: Wed, 5 Mar 2025 11:23:22 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Harry Yoo <harry.yoo@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] mm/mremap: refactor mremap() system call
implementation
On Wed, Mar 05, 2025 at 10:47:58AM +0900, Harry Yoo wrote:
> On Mon, Mar 03, 2025 at 11:08:32AM +0000, Lorenzo Stoakes wrote:
> > Place checks into a separate function so the mremap() system call is less
> > egregiously long, remove unnecessary mremap_to() offset_in_page() check and
> > just check that earlier so we keep all such basic checks together.
> >
> > Separate out the VMA in-place expansion, hugetlb and expand/move logic into
> > separate, readable functions.
> >
> > De-duplicate code where possible, add comments and ensure that all error
> > handling explicitly specifies the error at the point of it occurring rather
> > than setting a prefixed error value and implicitly setting (which is bug
> > prone).
> >
> > This lays the groundwork for subsequent patches further simplifying and
> > extending the mremap() implementation.
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> > ---
>
> Nice refactoring—reviewing it was a nice learning experience.
>
> Looks good to me,
> Reviewed-by: Harry Yoo <harry.yoo@...cle.com>
Thanks!
>
> --
> Cheers,
> Harry
>
> > mm/mremap.c | 405 ++++++++++++++++++++++++++++++++--------------------
> > 1 file changed, 251 insertions(+), 154 deletions(-)
Powered by blists - more mailing lists