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 2D34BE92FDB for ; Fri, 6 Oct 2023 03:29:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9579940011; Thu, 5 Oct 2023 23:29:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A45F594000B; Thu, 5 Oct 2023 23:29:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 934AD940011; Thu, 5 Oct 2023 23:29:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 82F5294000B for ; Thu, 5 Oct 2023 23:29:33 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7922C12010E for ; Fri, 6 Oct 2023 03:29:32 +0000 (UTC) X-FDA: 81313606584.24.B9F65A4 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf05.hostedemail.com (Postfix) with ESMTP id D111B100002 for ; Fri, 6 Oct 2023 03:29:29 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; spf=none (imf05.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696562970; h=from:from:sender: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=HP5e8CNLHjOZRuPn39metmzbdMRQc/B6iWr5Q9S1lwY=; b=t5LASKYjwBqraEdeYA+4P648BQQU/T51uzDlMXWYEMeU95C1nuTf1KtAUwOahsRlqtSlod DjupqprCy+SjJuiDzqSuffxX+Rd6SYBnKaAG/rMeuCFctPK/cqYOa9EHp19hDP4cwKN/Pg CGOmVtM1vsa1lB7SjZtXK4Nupj+VmJc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696562970; a=rsa-sha256; cv=none; b=2G5s1rXcqvafGdYJkpxPrBpsNGtpXdZcsyZVUfk958XxFP3386MngCIaeXOd6D/f/AIm/u 9g0ROa6afIYiRDNEUwTIod740aUVrIbeT8C/sbwQTIrBfSxeflXD48NOOv/MknV4oNpZkY /snwfw2+SmmmxGSy2+q6F6IcI0mjxxI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; spf=none (imf05.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none Received: from imladris.home.surriel.com ([10.0.13.28] helo=imladris.surriel.com) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qobWM-0001qH-1a; Thu, 05 Oct 2023 23:28:58 -0400 Message-ID: Subject: Re: [PATCH 3/3] hugetlbfs: replace hugetlb_vma_lock with invalidate_lock From: Rik van Riel To: Mike Kravetz Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com, linux-mm@kvack.org, akpm@linux-foundation.org, muchun.song@linux.dev, leit@meta.com, willy@infradead.org Date: Thu, 05 Oct 2023 23:28:58 -0400 In-Reply-To: <20231006001912.GB86415@monkey> References: <20231004032814.3108383-1-riel@surriel.com> <20231004032814.3108383-4-riel@surriel.com> <20231006001912.GB86415@monkey> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 X-Stat-Signature: jrzu3mcwgnobn9ti5rkitj6fuid58u9d X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D111B100002 X-Rspam-User: X-HE-Tag: 1696562969-266655 X-HE-Meta: U2FsdGVkX18zFI5Q50DK9chShaPv45HhEQCqF7Eo19BpmTQs52tvGKxLcTrzlH+15E6sg4ZtX338bZ9GRODGzHQQF3cVBU9coLdOQRYvjnLoRtggW6IY640TfessFrFJykoBXtPwK1q7yGO/JX+gVYVFr3yFqn1OJLfkbit8FtMlNedatTuQqOJqCmY+Gbjtes1gyrP7z2GS1pjP9ZjXHD+SgpD3IhWfabczU1+m5r0ViZKi2aF23dPLk7vkkjCHXEje2wTXlZHkhg5F47fxYFVmRe6X0BbDxvAyGQL3z7tZ4vbk6jGGXfDS+bxRpMrCzyeh4shqaPAuLg05HbR7nwsunUCYo7pAlmSJVMza+0aH37UKt6NjXj354sdhtxQuJqKVFy3sx6suoItBBJVOf5xbJlPCwSKsHuui9wq/R0O7clF+cRn6Mjz1l9qs4BJnE9NCDFsW/KG9KVlxesnRsJUsRakq92GAvRn4IRak3ZEIXcXVcIXA+i4wKmN2pFm7qziDKqxNi8e4DoCEV5oMR3XoevPMRiyDgjeFg0dJYNG8afDZg81vRxQGROo6MFhoH8B9cBuzcIPMK7DNhlb7Dctzchi6UTcG7UW1CLqjK3RATAHRyOeco9Kroc9duRIUcLX+RMAD+Bskix/8OiFjd8XJ6iD6rq3ORU/EiUBcyPhbd80WNrZIjfVLzXnHBFa/ppd2AFzP1YDSaDcNQdVgw/4E429V9dHQ1VCdjclA567E/gJOcVPAoyKMKFwaHd6V7UcA+8M9CphYx7pTWNaYKagMQ43EWZE7Ejq296atmMjOFzthaSB1P7FcsNojqZfIwiNyjfDTJvPi23SGH74HRiCOcO3cmMsoC9gALB9+t7Yz82YjimmD71Om8ORGOyVYh6C5YmD9H5MafeckaIwVqaYjyx29YFeMlbwwjJhNRP6PDNTEXFf9ANuvIjSDCW0UXaasnNEqTk1+vk4A33x ivAwI1mZ mhGgJZh48UmSQXFHO0LG9xk8DhHzJ0Uc6noBC3VwCbe6gk9LbxcKSGYySazFeNVRaqhQ+VkOavpc2LNR93nsZ2LEPAD1387UghYvNmF1ZwPNeuJfpLrYg+EPyQXpYI0ZB1nyy1wmETOBl/IJ614AtoL/+xMpodowg2WbSlP3P9E2gOFURym1oki3PQKeAsJUDFrWMQgSTAjs4ayWE6HXJoBJoxfw76smnGdBV+M3nkC5+I9JZcF/gtcjgeWULifBMreU7JwIi2+RfqR2gxADFMlHhBHEMkq82jCHX 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 Thu, 2023-10-05 at 17:19 -0700, Mike Kravetz wrote: >=20 > I have not gone through the patch, but it does produce the following: >=20 > [=C2=A0=C2=A0 49.783584] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > [=C2=A0=C2=A0 49.784570] WARNING: bad unlock balance detected! > [=C2=A0=C2=A0 49.785589] 6.6.0-rc3-next-20230925+ #35 Not tainted > [=C2=A0=C2=A0 49.786644] ------------------------------------- > [=C2=A0=C2=A0 49.787768] hfill2/938 is trying to release lock > (mapping.invalidate_lock) at: > [=C2=A0=C2=A0 49.789387] [] > remove_inode_hugepages+0x405/0x4b0 > [=C2=A0=C2=A0 49.790723] but there are no more locks to release! > [=C2=A0=C2=A0 49.791808]=20 > [=C2=A0=C2=A0 49.791808] other info that might help us debug this: > [=C2=A0=C2=A0 49.793274] 4 locks held by hfill2/938: > [=C2=A0=C2=A0 49.794190]=C2=A0 #0: ffff8881ff3213e8 (sb_writers#11){.+.+}= -{0:0}, at: > do_syscall_64+0x37/0x90 > [=C2=A0=C2=A0 49.796165]=C2=A0 #1: ffff888181c99640 (&sb->s_type- > >i_mutex_key#16){+.+.}-{3:3}, at: do_truncate+0x6f/0xd0 > [=C2=A0=C2=A0 49.798188]=C2=A0 #2: ffff888301592f98 > (&hugetlb_fault_mutex_table[i]){+.+.}-{3:3}, at: > remove_inode_hugepages+0x144/0x4b0 > [=C2=A0=C2=A0 49.800494]=C2=A0 #3: ffff888181c998b0 > (&hugetlbfs_i_mmap_rwsem_key){++++}-{3:3}, at: > remove_inode_hugepages+0x239/0x4b0 Well that's a fun one. The remove_inode_hugepages function does not take the mapping.invalidate_lock, but it calls hugetlb_unmap_file_folio which does. The vma_interval_tree_foreach loop has a stray hugetlb_vma_unlock_write() left, which I should have removed when lifting the lock outside of the loop. Nice catch! --=20 All Rights Reversed.