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(). 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. -- Mike Kravetz
