linux-kernel - Re: [PATCH v2 4/8] powerpc/mm: protect linear mapping modifications by a mutex

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: <274264b2-9ec8-bde0-5725-184c8fd5f05e@redhat.com>
Date:   Tue, 17 Nov 2020 16:46:40 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Oscar Salvador <osalvador@...e.de>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linuxppc-dev@...ts.ozlabs.org,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Rashmica Gupta <rashmica.g@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Rapoport <rppt@...nel.org>,
        Michal Hocko <mhocko@...e.com>,
        Wei Yang <richard.weiyang@...ux.alibaba.com>
Subject: Re: [PATCH v2 4/8] powerpc/mm: protect linear mapping modifications
 by a mutex

On 17.11.20 16:37, Oscar Salvador wrote:
> On Wed, Nov 11, 2020 at 03:53:18PM +0100, David Hildenbrand wrote:
>> @@ -144,7 +147,9 @@ void __ref arch_remove_linear_mapping(u64 start, u64 size)
>>   	start = (unsigned long)__va(start);
>>   	flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE);
>>   
>> +	mutex_lock(&linear_mapping_mutex);
>>   	ret = remove_section_mapping(start, start + size);
>> +	mutex_unlock(&linear_mapping_mutex);
>>   	WARN_ON_ONCE(ret);
> 
> My expertise in this area is low, so bear with me.
> 
> Why we do not need to protect flush_dcache_range_chunked and
> vm_unmap_aliases?
> 

vm_unmap_aliases does own locking and can handle concurrent calls.


flush_dcache_range_chunked()->flush_dcache_range() ends up as a sequence 
of memory barriers paired with dcbf instructions.

dcbf: Copies modified cache blocks to main storage and invalidates the 
copy in the data cache.

It's called from various places and no global variables seem to be 
involved, so it looks like it doesn't need any kind of locking.

-- 
Thanks,

David / dhildenb