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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 2 Oct 2023 14:11:17 +0100
From:   Conor Dooley <conor@...nel.org>
To:     Alexandre Ghiti <alex@...ti.fr>
Cc:     Alexandre Ghiti <alexghiti@...osinc.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Andrew Jones <ajones@...tanamicro.com>,
        Qinglin Pan <panqinglin2020@...as.ac.cn>,
        Ryan Roberts <ryan.roberts@....com>,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -fixes 2/2] riscv: Fix set_huge_pte_at() for NAPOT
 mappings when a swap entry is set

On Mon, Oct 02, 2023 at 09:18:52AM +0200, Alexandre Ghiti wrote:
> Hi Conor,
> 
> On 30/09/2023 11:14, Conor Dooley wrote:
> > On Thu, Sep 28, 2023 at 05:18:46PM +0200, Alexandre Ghiti wrote:
> > > We used to determine the number of page table entries to set for a NAPOT
> > > hugepage by using the pte value which actually fails when the pte to set is
> > > a swap entry.
> > > 
> > > So take advantage of a recent fix for arm64 reported in [1] which
> > > introduces the size of the mapping as an argument of set_huge_pte_at(): we
> > > can then use this size to compute the number of page table entries to set
> > > for a NAPOT region.
> > > 
> > > Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page")
> > > Reported-by: Ryan Roberts <ryan.roberts@....com>
> > > Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1]
> > > Signed-off-by: Alexandre Ghiti <alexghiti@...osinc.com>

> > Breaks the build. Your $subject marks this for -fixes, but this will not
> > build there, as it relies on content that's not yet in that branch.
> > AFAICT, you're going to have to resend this with akpm on CC, as the
> > dependency is in his tree...
> 
> 
> I see, but I still don't understand why -fixes does not point to the latest
> rcX instead of staying on rc1?

It's up to Palmer what he does with his fixes branch, but two thoughts.
Doing what you suggest would require rebasing things not yet sent to Linus
every week and fast-forwarding when PRs are actually merged.
IIRC, Palmer used to do something like the latter, but IIRC he got some
complaints about that and switched to the current method.
At the very least, you should point out dependencies like this, as I
figure an individual patch could be applied on top of -rc4 and merged
in. Both Palmer and I have submitted things for b4 to improve support for
doing things exactly like this ;)

> The patch which this series depends on just made it to rc4.

However, if you do not mention what the deps for your patches are
explicitly, how are people supposed to know? The reference to the
dependency makes it look like a report for a similar problem that also
applies to riscv, not a pre-requisite for the patch.

Thanks,
Conor.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ