linux-kernel - Re: [PATCH mm-unstable] mm/demotion: Assign correct memory type for multiple dax devices with the same node affinity

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:   Thu, 1 Sep 2022 11:54:42 +0530
From:   Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com>
To:     "Huang, Ying" <ying.huang@...el.com>
Cc:     linux-mm@...ck.org, akpm@...ux-foundation.org,
        Wei Xu <weixugc@...gle.com>, Yang Shi <shy828301@...il.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Tim C Chen <tim.c.chen@...el.com>,
        Michal Hocko <mhocko@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Hesham Almatary <hesham.almatary@...wei.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Alistair Popple <apopple@...dia.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Johannes Weiner <hannes@...xchg.org>, jvgediya.oss@...il.com,
        Bharata B Rao <bharata@....com>
Subject: Re: [PATCH mm-unstable] mm/demotion: Assign correct memory type for
 multiple dax devices with the same node affinity

On 9/1/22 11:45 AM, Huang, Ying wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com> writes:
> 
>> With multiple dax devices having the same node affinity, the kernel wrongly assigned
>> default_dram memory type to some devices after the memory hotplug operation. Fix this by
>> not clearing node_memory_types on the dax device remove.
> 
> Sorry for late reply.
> 
> Just for confirmation.  There are multiple dax devices in one NUMA node?
> 
> If you can show the bug reproducing steps, that will make it even easier
> to understand.
> 

NUMA nodes are assigned per region and you can have multiple devdax namespace with same NUMA node affinity. 

dax0.1 and dax0.2 are examples. To recreate you can follow the below steps


root@...ntu-guest:/sys/devices/system/node/node3# ls
compact  cpumap    meminfo   memory34  memory36  memory38  memory41  memory43  memory45  memory47  memory50  memory52  memory54  numastat   uevent
cpulist  distance  memory33  memory35  memory37  memory39  memory42  memory44  memory46  memory49  memory51  memory53  memory55  subsystem  vmstat
root@...ntu-guest:/sys/devices/system/node/node3#
root@...ntu-guest:/sys/devices/system/node/node3# for mem in memory*; do echo 0 > $mem/online; done
root@...ntu-guest:/sys/devices/system/node/node3# cd /sys/bus/dax/drivers
root@...ntu-guest:/sys/bus/dax/drivers# echo dax0.0  > kmem/unbind
root@...ntu-guest:/sys/bus/dax/drivers# cd /sys/devices/system/node/node3/
root@...ntu-guest:/sys/devices/system/node/node3# ls
compact  cpumap    meminfo   memory42  memory44  memory46  memory49  memory51  memory53  memory55  subsystem  vmstat
cpulist  distance  memory41  memory43  memory45  memory47  memory50  memory52  memory54  numastat  uevent
root@...ntu-guest:/sys/devices/system/node/node3# for mem in memory*; do echo 1 > $mem/online; done


-aneesh