linux-kernel - Re: [PATCH mmotm] mempolicy: mbind_range() set_policy() after vma

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]

Date:   Fri, 11 Mar 2022 01:33:05 -0800 (PST)
From:   Hugh Dickins <hughd@...gle.com>
To:     Liam Howlett <liam.howlett@...cle.com>
cc:     Vlastimil Babka <vbabka@...e.cz>, Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH mmotm] mempolicy: mbind_range() set_policy() after
 vma_merge()

On Wed, 9 Mar 2022, Liam Howlett wrote:
> * Vlastimil Babka <vbabka@...e.cz> [220309 07:41]:
> > On 3/8/22 22:32, Hugh Dickins wrote:
> > 
> > > Does that help?
> 
> I think so.  You want to set the mpol the same across the vma because we
> are specifically calling mbind, but it isn't necessary because the mpol
> is equivalent but not the same mpol?

I did not understand that logic, so cannot confirm it.

The crucial point, as I see it, is that a call to shmem_set_policy() was
needed in many cases, but had been "optimized away" by the mpol_equal test.

> I guess I have the same question
> as Vlastimil brought up - why does tmpfs need this?

One way of answering would be: because tmpfs is used to back SysV SHM,
and "man 2 mbind" has a paragraph on the subject of mbind on a shared
memory region created using the shmget(2) system call.

Or you could look in Documentation/admin-guide/mm/numa_memory_policy.rst,
section on "Shared Policy".  (But it's a surprise to me to see how that
makes no mention of tmpfs itself: it's as if it's just an accident that
this is how NUMA mempolicy is applied to mappings of tmpfs files.)

An important comment from ChangeLog-2.6.7 when mm/mempolicy.c came in:
For shmfs/tmpfs/hugetlbfs shared memory the policy is shared between
all users and remembered even when nobody has memory mapped.

(But although hugetlbfs support was intended in the original RFC to lkml,
it was never implemented in the tree, despite appearances: a patch I did
not send this time, but eventually will, removes the appearance of shared
mempolicy on hugetlbfs.)

Hugh