lkml.org 
[lkml]   [2020]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 4/8] powerpc/mm: protect linear mapping modifications by a mutex
From
Date
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

\
 
 \ /
  Last update: 2020-11-17 16:48    [W:0.054 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site