linux-kernel - Re: [RFC PATCH] mm/mbind: Introduce process_mbind() syscall for external memory binding

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

Message-ID: <CACSyD1PCjPEwPCVXKVULjbNwxUG89DZUUfiDLg+wFyJRJXAPzA@mail.gmail.com>
Date:   Fri, 1 Dec 2023 21:53:23 +0800
From:   Zhongkun He <hezhongkun.hzk@...edance.com>
To:     Gregory Price <gregory.price@...verge.com>
Cc:     Vinicius Petrucci <vpetrucci@...il.com>, akpm@...ux-foundation.org,
        linux-mm@...r.kernel.org, linux-cxl@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-api@...r.kernel.org, minchan@...nel.org,
        dave.hansen@...ux.intel.com, x86@...nel.org,
        Jonathan.Cameron@...wei.com, aneesh.kumar@...ux.ibm.com,
        ying.huang@...el.com, dan.j.williams@...el.com, fvdl@...gle.com,
        surenb@...gle.com, rientjes@...gle.com, hannes@...xchg.org,
        mhocko@...e.com, Hasan.Maruf@....com, jgroves@...ron.com,
        ravis.opensrc@...ron.com, sthanneeru@...ron.com,
        emirakhur@...ron.com, vtavarespetr@...ron.com
Subject: Re: [RFC PATCH] mm/mbind: Introduce process_mbind() syscall for
 external memory binding

>
> Hi ZhongKun!
>
> I actually just sent out a more general RFC to mempolicy updates that
> discuss this more completely:
>
> https://lore.kernel.org/linux-mm/ZWezcQk+BYEq%2FWiI@memverge.com/
>

OK.

> and another post on even more issues with pidfd modifications to vma
> mempolicies:
>
> https://lore.kernel.org/linux-mm/ZWYsth2CtC4Ilvoz@memverge.com/
>
> We may have to slow-walk the changes to vma policies due to there being
> many more hidden accesses to (current) than expected. It's a rather
> nasty rats nest of mempolicy-vma-cpusets-shmem callbacks that obscure
> these current-task accesses, it will take time to work through.
>

Got it, thanks. It's more complicated than I thought.

> As for hot-path reference counting - we may need to change the way
> mempolicy is managed, possibly we could leverage RCU to manage mempolicy
> references in the hot path, rather than using locks.  In this scenario,
> we would likely need to change the way the default policy is applied
> (maybe not, I haven't fully explored it).
>

RCU may have a long time in the read-side critical section.

We should probably replace the atomic_t refcnt with percpu_ref in
mempolicy(also suggested by Michal), but refactoring work involves
a lot of code.

A simple way is to use task_work to release the mempolicy which may
be used by alloc_pages(). But it doesn't have a direct result.

> Do you have thoughts on this?  Would very much like additional comments
> before I go through the refactor work.
>
> Regards,
> Gregory