Re: Splitting the mmap_sem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/5/19 6:21 PM, Jerome Glisse wrote:
>> 
>> So calling mmap() looks like this:
>> 
>>       1 allocate a new VMA
>>       2 update pointer(s) in maple tree
>>       3 sleep until old VMAs have a zero refcount
>>       4 synchronize_rcu()
>>       5 free old VMAs
>>       6 flush caches for affected range
>>       7 return to userspace
>> 
>> While one thread is calling mmap(MAP_FIXED), two other threads which are
>> accessing the same address may see different data from each other and
>> have different page translations in their respective CPU caches until
>> the thread calling mmap() returns.  I believe this is OK, but would
>> greatly appreciate hearing from people who know better.
> 
> I do not believe this is OK, i believe this is wrong (not even considering
> possible hardware issues that can arise from such aliasing).

But is it true that the races can happen in the above such that multiple CPU's
have different translations? I think it's impossible to tell from above - there
are no details about when and which pte modifications happen, where ptl lock is
taken... perhaps after filling those details, we could be able to see that
there's no race.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux