linux-kernel - Re: [PATCH 1/1] mm/khugepaged: bypassing unnecessary scans with MMF_DISABLE

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK1f24=WJa7qpwBW8J-eYBc2TGrViE_8vtCTESXxMDd=hhQdjw@mail.gmail.com>
Date: Tue, 30 Jan 2024 17:46:17 +0800
From: Lance Yang <ioworker0@...il.com>
To: Michal Hocko <mhocko@...e.com>
Cc: akpm@...ux-foundation.org, zokeefe@...gle.com, david@...hat.com, 
	songmuchun@...edance.com, shy828301@...il.com, peterx@...hat.com, 
	minchan@...nel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] mm/khugepaged: bypassing unnecessary scans with
 MMF_DISABLE_THP check

On Tue, Jan 30, 2024 at 5:35 PM Michal Hocko <mhocko@...e.com> wrote:
>
> On Tue 30-01-24 11:08:10, Lance Yang wrote:
> > On Tue, Jan 30, 2024 at 10:12 AM Lance Yang <ioworker0@...il.com> wrote:
> > >
> > > Hey Michal,
> > >
> > > Thanks for taking time to review!
> > >
> > > On some servers within our company, we deploy a
> > > daemon responsible for monitoring and updating
> > > local applications. Some applications prefer not to
> > > use THP, so the daemon calls prctl to disable THP
> > > before fork/exec. Conversely, for other applications,
> > > the daemon calls prctl to enable THP before fork/exec.
> > >
> > > Ideally, the daemon should invoke prctl after the fork,
> > > but its current implementation follows the described
> > > approach.
> >
> > In the Go standard library, there is no direct encapsulation
> > of the fork system call. Instead, fork and execve are
> > combined into one through syscall.ForkExec.
>
> OK, this is an important detail. Something that should be a part
> of the chnagelog. It is also important to note that this is not
> a correctness issue but rather an optimization to save expensive
> checks on each VMA when userspace cannot prctl itself before spawning
> into the new process.

Thanks for pointing that out!

I'll include it in the changelog. Good to know it's an optimization
rather than a correctness issue.

Thanks,
Lance

> --
> Michal Hocko
> SUSE Labs