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 06648C4332F for ; Mon, 21 Nov 2022 18:11:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50C676B0072; Mon, 21 Nov 2022 13:11:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BB326B0073; Mon, 21 Nov 2022 13:11:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3AA656B0074; Mon, 21 Nov 2022 13:11:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2C8ED6B0072 for ; Mon, 21 Nov 2022 13:11:37 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EA6AF14043F for ; Mon, 21 Nov 2022 18:11:36 +0000 (UTC) X-FDA: 80158242192.04.568E369 Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf19.hostedemail.com (Postfix) with ESMTP id 907431A0012 for ; Mon, 21 Nov 2022 18:11:35 +0000 (UTC) Received: by mail-yb1-f171.google.com with SMTP id p81so6835385yba.4 for ; Mon, 21 Nov 2022 10:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=z2svw9m4hShuPYQWl2tT3FssDOjrSODKLzg/rFvOD00=; b=SIlkGVLLgwYG5rPEVqALwDpK5SHqK/y9LnUUK8sVNkLF7W6MirOINonE5mqsMMZQif g5SGQCRUK60Ighv3wVx2Kqdd2+0S3NyQvGxY6bqfeYPUW2BJH5WKhTLWYuZTpBiJ4jr0 lNdLVN7MSFkhOk6So8zvSzcbk8wFneJ/KR8D4VMWR3VWUge/E3YBKtWMWE5MmflHpyV3 aoCXeUdbOBxPu1+yON+q31shNMgTpakr2WN47D7nzc6lERREC08aW/g5R99banHTwu+Z Bs+2lv7CUsoIDxMKc4wnmDO0SWEG97ugzjjau8ws4Nyx+D2FsURDYQFgY+XY85ha2HEk kcvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=z2svw9m4hShuPYQWl2tT3FssDOjrSODKLzg/rFvOD00=; b=Y1HVfKwySaxeRhCZKLCiKiMNN+DsJDsxabTWAOfvRmP5UmHK/+oUq8JgJdriKSfRlv O1G3I8tZZTxop8sbi6t4NZLd0UqB9YPpzaKOuRmePlP/eL6sGbWOPK/lZSbKSap2+Ue/ R5AUIPRqm/E1PS+C9bMChXn24Ac3nnz4o8TsG1ilMhPYyiPJhvOrQO3PtgP/VTyQLLan WsXppF9knJDx6vliYrmvWEr35/8emEqG+yQXcNvlTVzN1ktuCBZaAMb8uE16cv9B92Vi EBeJkfnM7QQmFa3qCddVXqrTw3uSKzhfwN2/COPwdxyUWtKClwyIRFiJhyrju7S4JnNo iZxw== X-Gm-Message-State: ANoB5pnxsGzMQ9yrXMM+8Dq2EtUBe/CHptuch05VeVCbO4BSkqWcM9h3 IP5yo8t4neMYXlHVSyezIUIpIuJuSsmKqP3cDNh6Vw== X-Google-Smtp-Source: AA0mqf6jJTSFEBnWdyyc+zrbVA6aP5N4mXhWgR7xJU/W3GWjMUOKJWyofOBBOhyrTJaCSD7Cj4JLtGpi2ckHUaMkMME= X-Received: by 2002:a05:6902:118e:b0:6e7:f54:b3d6 with SMTP id m14-20020a056902118e00b006e70f54b3d6mr2633115ybu.577.1669054294659; Mon, 21 Nov 2022 10:11:34 -0800 (PST) MIME-Version: 1.0 References: <20221021163703.3218176-1-jthoughton@google.com> <20221021163703.3218176-6-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Mon, 21 Nov 2022 10:11:23 -0800 Message-ID: Subject: Re: [RFC PATCH v2 05/47] hugetlb: make hugetlb_vma_lock_alloc return its failure reason To: Peter Xu Cc: Mike Kravetz , Muchun Song , David Hildenbrand , David Rientjes , Axel Rasmussen , Mina Almasry , "Zach O'Keefe" , Manish Mishra , Naoya Horiguchi , "Dr . David Alan Gilbert" , "Matthew Wilcox (Oracle)" , Vlastimil Babka , Baolin Wang , Miaohe Lin , Yang Shi , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=SIlkGVLL; spf=pass (imf19.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669054295; a=rsa-sha256; cv=none; b=0iV3x5I1lJZ+UAb0mUoEZLLd/xN4qB2BNvTuqVyczN/jlFrd/O4+c/522yvwES+0cIqDIs U+xmjUXtmo269ywnto0mp5Iu2our7kaSXDMWPr9PUkKebmiOViUjEiWBNjb55RQ0+y4J9b fo4FRguqLYPpfL7WDFnHDdjbZpgl4yk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669054295; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=z2svw9m4hShuPYQWl2tT3FssDOjrSODKLzg/rFvOD00=; b=GtCAD2U72hGxoaqhLhdw4Ae8/mN7zCMiSnRzwYj2SuIxlrwcpwhQtmbhTa3T0Hw3pRq1fO OrAtDADh+o1caHIu0aYBzJjZljY54mTlnK7CpAmf4pv3Buc10p5cdJbCZY8hbCYIDQ1iP8 dWdov8OVI3nTR843HmHC0c3005DPjSk= X-Rspamd-Queue-Id: 907431A0012 X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=SIlkGVLL; spf=pass (imf19.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam06 X-Stat-Signature: xazawsojgxyeehbca7tt9suhbuu43631 X-HE-Tag: 1669054295-651968 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 Wed, Nov 16, 2022 at 9:08 AM Peter Xu wrote: > > No objection on the patch itself, but I am just wondering what guarantees > thread-safety for this function to not leak vm_private_data when two > threads try to allocate at the same time. > > I think it should be the write mmap lock. I saw that in your latest code > base there's: > > /* > * We must hold the mmap lock for writing so that callers can rely on > * hugetlb_hgm_enabled returning a consistent result while holding > * the mmap lock for reading. > */ > mmap_assert_write_locked(vma->vm_mm); > > /* HugeTLB HGM requires the VMA lock to synchronize collapsing. */ > ret = hugetlb_vma_data_alloc(vma); > if (ret) > return ret; > > So that's covered there. The rest places are hugetlb_vm_op_open() and > hugetlb_reserve_pages() and they all seem fine too: hugetlb_vm_op_open() is > during mmap(), the latter has vma==NULL so allocation will be skipped. > > I'm wondering whether it would make sense to move this assert to be inside > of hugetlb_vma_data_alloc() after the !vma check, or just add the same > assert too but for different reason. I think leaving the assert here and adding a new assert inside hugetlb_vma_data_alloc() makes sense. Thanks Peter. - James > > > > > vma_lock = kmalloc(sizeof(*vma_lock), GFP_KERNEL); > > if (!vma_lock) { > > @@ -7026,13 +7026,14 @@ static void hugetlb_vma_lock_alloc(struct vm_area_struct *vma) > > * allocation failure. > > */ > > pr_warn_once("HugeTLB: unable to allocate vma specific lock\n"); > > - return; > > + return -ENOMEM; > > } > > > > kref_init(&vma_lock->refs); > > init_rwsem(&vma_lock->rw_sema); > > vma_lock->vma = vma; > > vma->vm_private_data = vma_lock; > > + return 0; > > } > > > > /* > > @@ -7160,8 +7161,9 @@ static void hugetlb_vma_lock_free(struct vm_area_struct *vma) > > { > > } > > > > -static void hugetlb_vma_lock_alloc(struct vm_area_struct *vma) > > +static int hugetlb_vma_lock_alloc(struct vm_area_struct *vma) > > { > > + return 0; > > } > > > > pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, > > -- > > 2.38.0.135.g90850a2211-goog > > > > > > -- > Peter Xu >