From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 657BFC0502C for ; Sat, 27 Aug 2022 09:30:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABDF9940007; Sat, 27 Aug 2022 05:30:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A6F886B0074; Sat, 27 Aug 2022 05:30:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93716940007; Sat, 27 Aug 2022 05:30:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 838186B0073 for ; Sat, 27 Aug 2022 05:30:48 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 531A580EFF for ; Sat, 27 Aug 2022 09:30:48 +0000 (UTC) X-FDA: 79844852976.09.4A8990C Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf03.hostedemail.com (Postfix) with ESMTP id A70FA20019 for ; Sat, 27 Aug 2022 09:30:36 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4MFBDZ5Tz8zlVyt; Sat, 27 Aug 2022 17:27:10 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 27 Aug 2022 17:30:28 +0800 Subject: Re: [PATCH 6/8] hugetlb: add vma based lock for pmd sharing To: Mike Kravetz CC: Muchun Song , David Hildenbrand , Michal Hocko , Peter Xu , Naoya Horiguchi , "Aneesh Kumar K . V" , Andrea Arcangeli , "Kirill A . Shutemov" , Davidlohr Bueso , Prakash Sangappa , James Houghton , Mina Almasry , Pasha Tatashin , Axel Rasmussen , Ray Fucillo , Andrew Morton , , References: <20220824175757.20590-1-mike.kravetz@oracle.com> <20220824175757.20590-7-mike.kravetz@oracle.com> From: Miaohe Lin Message-ID: <47cc90bf-d616-5004-555d-b3d7e9b09bd1@huawei.com> Date: Sat, 27 Aug 2022 17:30:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20220824175757.20590-7-mike.kravetz@oracle.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661592647; a=rsa-sha256; cv=none; b=8D9uWJjexz8+LXkiHBW4ORv1YXZ7FIkVRUY890R3o0ZNqtZ2XtDYw3jw3WLoKM0pPlBnx0 xIYX+1iUyC4Op3+nmklus9jDWmuvcWxSTEyfeu2D4hPyEmF0uhenqAZHIDIxtLHr7f9KP4 4u8sacsLX2wWQXUjnvOvhcLtbk1R0Zk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf03.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661592647; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U84Z+WCgygKbflsS8otq6oIcCoEwOxa2YiPM9NC/7es=; b=E3I6FAuZNixzfFXRMA7yYm0zMJkXS3OK/G8o+1ftuFASWzMQiBqzMGkBnVlD7VJ9T/mCco +UIrlMn6Q8l6I1PXA3wsAHDVtIL6MF8r8QQ8dFLS/Zi8ZWn5sg4Oiel7g3vk27D8y63Fgh mWEH0uSH4iQlNppOs2AmPKjkuE4jLJQ= X-Stat-Signature: 3rkdu443arwa3jrdgse39ydqjrmd5w7x X-Rspamd-Queue-Id: A70FA20019 X-Rspam-User: X-Rspamd-Server: rspam06 Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf03.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com X-HE-Tag: 1661592636-869274 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2022/8/25 1:57, Mike Kravetz wrote: > Allocate a rw semaphore and hang off vm_private_data for > synchronization use by vmas that could be involved in pmd sharing. Only > add infrastructure for the new lock here. Actual use will be added in > subsequent patch. > > Signed-off-by: Mike Kravetz > +static void hugetlb_vma_lock_free(struct vm_area_struct *vma) > +{ > + /* > + * Only present in sharable vmas. See comment in > + * __unmap_hugepage_range_final about the neeed to check both s/neeed/need/ > + * VM_SHARED and VM_MAYSHARE in free path I think there might be some wrong checks around this patch. As above comment said, we need to check both flags, so we should do something like below instead? if (!(vma->vm_flags & (VM_MAYSHARE | VM_SHARED) == (VM_MAYSHARE | VM_SHARED))) > + */ > + if (!vma || !(vma->vm_flags & (VM_MAYSHARE | VM_SHARED))) > + return; > + > + if (vma->vm_private_data) { > + kfree(vma->vm_private_data); > + vma->vm_private_data = NULL; > + } > +} > + > +static void hugetlb_vma_lock_alloc(struct vm_area_struct *vma) > +{ > + struct rw_semaphore *vma_sema; > + > + /* Only establish in (flags) sharable vmas */ > + if (!vma || !(vma->vm_flags & VM_MAYSHARE)) > + return; > + > + /* Should never get here with non-NULL vm_private_data */ We can get here with non-NULL vm_private_data when called from hugetlb_vm_op_open during fork? Also there's one missing change on comment: diff --git a/mm/hugetlb.c b/mm/hugetlb.c index d0617d64d718..4bc844a1d312 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -863,7 +863,7 @@ __weak unsigned long vma_mmu_pagesize(struct vm_area_struct *vma) * faults in a MAP_PRIVATE mapping. Only the process that called mmap() * is guaranteed to have their future faults succeed. * - * With the exception of reset_vma_resv_huge_pages() which is called at fork(), + * With the exception of hugetlb_dup_vma_private() which is called at fork(), * the reserve counters are updated with the hugetlb_lock held. It is safe * to reset the VMA at fork() time as it is not in use yet and there is no * chance of the global counters getting corrupted as a result of the values. Otherwise this patch looks good to me. Thanks. Thanks, Miaohe Lin