On 11/7/19 1:49 PM, Mike Kravetz wrote: > On 11/7/19 11:54 AM, Matthew Wilcox wrote: >> Are there other current users of the write lock that could use a read lock? >> At first blush, it would seem that unmap_ref_private() also only needs >> a read lock on the i_mmap tree. I don't think hugetlb_change_protection() >> needs the write lock either. Nor retract_page_tables(). Sorry, I missed retract_page_tables which is not part of hugetlb code. The comments below do not apply to retract_page_tables. Someone would need to take a closer look to see if that really needs write mode. -- Mike Kravetz > > I believe that the semaphore still needs to be held in write mode while > calling huge_pmd_unshare (as is done in the call sites above). Why? > There is this check for sharing in huge_pmd_unshare, > > if (page_count(virt_to_page(ptep)) == 1) > return 0; // implies no sharing > > Note that huge_pmd_share now increments the page count with the semaphore > held just in read mode. It is OK to do increments in parallel without > synchronization. However, we don't want anyone else changing the count > while that check in huge_pmd_unshare is happening. Hence, the need for > taking the semaphore in write mode. >
