linux-kernel - Re: [PATCH v4 2/4] mm/hugetlb: Refactor unmap_hugepage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20250527190811.08e3c035f30187ba852f1914@linux-foundation.org>
Date: Tue, 27 May 2025 19:08:11 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Vishal Moola (Oracle)" <vishal.moola@...il.com>
Cc: nifan.cxl@...il.com, muchun.song@...ux.dev, willy@...radead.org,
 osalvador@...e.de, mcgrof@...nel.org, a.manzanares@...sung.com,
 dave@...olabs.net, david@...hat.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, Fan Ni <fan.ni@...sung.com>, Sidhartha Kumar
 <sidhartha.kumar@...cle.com>
Subject: Re: [PATCH v4 2/4] mm/hugetlb: Refactor unmap_hugepage_range() to
 take folio instead of page

On Mon, 5 May 2025 12:59:20 -0700 "Vishal Moola (Oracle)" <vishal.moola@...il.com> wrote:

> On Mon, May 05, 2025 at 11:22:42AM -0700, nifan.cxl@...il.com wrote:
> > From: Fan Ni <fan.ni@...sung.com>
> > 
> > The function unmap_hugepage_range() has two kinds of users:
> > 1) unmap_ref_private(), which passes in the head page of a folio.  Since
> >    unmap_ref_private() already takes folio and there are no other uses
> >    of the folio struct in the function, it is natural for
> >    unmap_hugepage_range() to take folio also.
> > 2) All other uses, which pass in NULL pointer.
> > 
> > In both cases, we can pass in folio. Refactor unmap_hugepage_range() to
> > take folio.
> 
> It looks like unmap_ref_private() is the only caller that cares about
> passing a particular folio to unmap_hugepage_range(). Is there any
> reason we shouldn't drop the folio argument and call
> __unmap_hugepage_range() directly? 

afaict there was no response to this review comment.

I'll proceed with the patchset, but please let's not lose sight of this.