On 06/11/2015 03:46 PM, Davidlohr Bueso wrote:
On Thu, 2015-06-11 at 14:01 -0700, Mike Kravetz wrote:/* Forward declaration */ static int hugetlb_acct_memory(struct hstate *h, long delta); @@ -3324,7 +3324,8 @@ static u32 fault_mutex_hash(struct hstate *h, struct mm_struct *mm, unsigned long key[2]; u32 hash; - if (vma->vm_flags & VM_SHARED) { + /* !vma implies this was called from hugetlbfs fallocate code */ + if (!vma || vma->vm_flags & VM_SHARED) {That !vma is icky, and really no need for it: hugetlbfs_fallocate(), for example, already passes [pseudo]vma->vm_flags with VM_SHARED, and you say it yourself in the comment. Do you see any reason why we cannot just keep the vma->vm_flags & VM_SHARED check?+/* + * Interface for use by hugetlbfs fallocate code. Faults must be + * synchronized with page adds or deletes by fallocate. fallocate + * only deals with shared mappings. See also hugetlb_fault_mutex_lock + * and hugetlb_fault_mutex_unlock. + */ +u32 hugetlb_fault_mutex_shared_hash(struct address_space *mapping, pgoff_t idx) +{ + return fault_mutex_hash(NULL, NULL, NULL, mapping, idx, 0); +}It strikes me that this too should be static inlined. But I really dislike the nil params thing, which should be addressed by my comment above.
In the previous RFC, I was trying not to make all the fault mutex data global (so it could be accessed outside hugetlb.c). That was the original reason for the wrapper interfaces. That may just be too ugly, and does not buy us much. Now that the mutex table is global for inlining, I might as well make fault_mutex_hash() global. I can then get rid of the wrappers. However, I'm guessing it would be a good idea to change the name(s) to something hugetlb specific since they will be global. -- Mike Kravetz
Thanks, Davidlohr
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>