linux-kernel - Re: [PATCH v4 11/23] device-dax: Kill dax_kmem

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: <25856e56-6afd-6efe-a396-f5a50b77f1f6@redhat.com>
Date:   Tue, 8 Sep 2020 20:03:31 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Joao Martins <joao.m.martins@...cle.com>,
        Dan Williams <dan.j.williams@...el.com>
Cc:     akpm@...ux-foundation.org, Vishal Verma <vishal.l.verma@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Pavel Tatashin <pasha.tatashin@...een.com>,
        peterz@...radead.org, ard.biesheuvel@...aro.org,
        linux-mm@...ck.org, linux-nvdimm@...ts.01.org,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v4 11/23] device-dax: Kill dax_kmem_res

>>> +		release_mem_region(range.start, range_len(&range));
>>
>> remove_memory() does a release_mem_region_adjustable(). Don't you
>> actually want to release the *unaligned* region you requested?
>>
> Isn't it what we're doing here?
> (The release_mem_region_adjustable() is using the same
> dax_kmem-aligned range and there's no split/adjust)

Oh, I think I was messing up things (there is just too much going on in
this patch).

Right, request_mem_region() and add_memory_driver_managed() are - and
were - called with the exact same range. That would have been clearer if
the patch would simply use range.start and range_len(&range) for both
calls (similar in the original code).

So, also the release calls have to use the same range. Agreed.

> 
> Meaning right now (+ parent marked as !BUSY), and if I am understanding
> this correctly:
> 
> request_mem_region(range.start, range_len)
>    __request_region(iomem_res, range.start, range_len) -> alloc @parent
> add_memory_driver_managed(parent.start, resource_size(parent))
>    __request_region(parent.start, resource_size(parent)) -> alloc @child
> 
> [...]
> 
> remove_memory(range.start, range_len)
>  request_mem_region_adjustable(range.start, range_len)
>   __release_region(range.start, range_len) -> remove @child
> 
> release_mem_region(range.start, range_len)
>   __release_region(range.start, range_len) -> doesn't remove @parent because !BUSY?
> 
> The add/removal of this relies on !BUSY. But now I am wondering if the parent remaining
> unreleased is deliberate even on CONFIG_MEMORY_HOTREMOVE=y.

Interesting, I can only tell that virtio-mem expects that
remove_memory() won't remove the parent resource (which is !BUSY). So it
relies on the existing functionality.

I do wonder how walk_system_ram_range() behaves if both the parent and
the child are BUSY. Looking at it, I think it will detect the parent and
skip to the next range (without visiting the child) - which is not what
we want.

We could set the parent to BUSY just before doing the
release_mem_region() call, but that feels like a hack.

Maybe it's just easier to keep dax_kmem_res around ...

-- 
Thanks,

David / dhildenb