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 C9B31C3DA42 for ; Wed, 10 Jul 2024 17:36:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C4926B00A1; Wed, 10 Jul 2024 13:36:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3722E6B00A2; Wed, 10 Jul 2024 13:36:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2609C6B00A3; Wed, 10 Jul 2024 13:36:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 07DC06B00A1 for ; Wed, 10 Jul 2024 13:36:16 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 87DD3801BB for ; Wed, 10 Jul 2024 17:36:15 +0000 (UTC) X-FDA: 82324546710.23.B9776BD Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id B15EC10000E for ; Wed, 10 Jul 2024 17:36:13 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=qpZQ71Rc; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720632942; 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:dkim-signature; bh=rZx6MhihM4aO85AYZex5b8JZ/fHEQfUDSYmMXaH9rFQ=; b=JaJCETFPCzXznlq8X64PGTj/LVa/8emnQZhtZEM6dNGmWK4X5jZM38rAshslGQJK3K0td9 I0d/FX3gu3A5Mxu2e3MOGlIWiYSZAZfDXAb1f0AnVQRKYNtttMoBSAEtrB907s35QMQMwV vn1M54Yp5BGMUJ162A5ZySETblppF3M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720632942; a=rsa-sha256; cv=none; b=jkQEc2Rp+KEA5WfyAAYj0RbRdz1z1mM9hOYJqd1LHILE/jQJKdlTHrgrmEa4880GYP0ZLE jsmzrXsApnXdXI2OkypG9X64g5GjsykfPM/TgAWX7nPzP5rPVJ8ZKii9Ja+5Fx4PncUU30 QrGIfKXSHFWMzAgMF425zX+VBQAdgi8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=qpZQ71Rc; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D64A361B20; Wed, 10 Jul 2024 17:36:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A5C1C32781; Wed, 10 Jul 2024 17:36:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1720632972; bh=qxj7/GfbAzJhv+yT4uusdh/k5PHvVnAEDliZ3yufpvQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qpZQ71Rc19JiZFDIK4eX07L9kOWG8E7UYV9NpPhQ/gfpFcrhbhDEwjmKIrZHo37EP wDLFZfVc3hWOPavhTEPRKBn+zNspNaxcM9z8qISWLefw+Dbrvdh2QlGrGgjOH1h/gm SLRTlvEORAzzJwM2nGdI/AgXRfVz8C8bSsqgaRFg= Date: Wed, 10 Jul 2024 10:36:11 -0700 From: Andrew Morton To: zhangchun Cc: , , , , , Subject: Re: [PATCH v2] mm: Give kmap_lock before call =?UTF-8?B?Zmx1c2hf?= =?UTF-8?B?dGxiX2tlcm5lbF9yYW5n77yMYXZvaWQ=?= kmap_high deadlock. Message-Id: <20240710103611.809895ff809df9ed411bfaa8@linux-foundation.org> In-Reply-To: <1720614028-2260-1-git-send-email-zhang.chuna@h3c.com> References: <1720614028-2260-1-git-send-email-zhang.chuna@h3c.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: B15EC10000E X-Stat-Signature: i7p61gfmt5hemymns11s56zppuqieyu3 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1720632973-851700 X-HE-Meta: U2FsdGVkX1+525Nw6uKkXJN2DsX8HdLPuo55Qp+BmBcWt8mugTOBph6ihDFHrcUqFW+GFhAIS2QjjgCVdT5XHjNQSGmf+WxFanz9+Tx8OEWMCtnzIPJS27MRM7nI4bNVVEIWKrSWQ6sDeclc2DeAZ9qm5n01M2wALRViaCzFvx77tgKaHPuYY566jcx79U0uvX0dFkrBQPo/QUM7XWswsV7x1aYHYFObv2HscnzCHad+oDvc85uA5ZoLw4pbsI8wwWw/4fZt472fLxXnwMX6Ql/TTeuwPsdR3/zTGnqLfJ7pdTnJ4XbXlJDXaPNbjSNIp8yrudpAGlNVfhz/5T2mnwqZvilT5Pc3DN++6LPEkhsjPkwUJtV+uUIci9xvAFrIkkPHeOL/gmceonfcVYNhu9eMkgF7UlhbbCqoznNaExWfouOWQmyKX+ne1QHLX3xPBZQBhg63g00FRbFxTXA2a2OGfikny+QDojIkwdy/nFg1VYW4QBoZ6ZD7rWeua/KFJ987H45CvHXc1aed2fI7a4qxjPOapuMrTj6GFer5i5GlhSkwCK9+f0TGlm718ivXBAWg6/M8iMTTpfdTrVvB+NaIgLkvUjuGRw+LZmpiGxC/krmpy6CSL2Yyp4px6TnSni+66KBMcN7w4QExPJj0xioQjmY8XUVPUsS/uosb4C+Ia/XdLRYzZwlg56MBDWNsqmy71Hot7Boltgfz06l3ZliBn0SI/OwVjFGWrvvsKj0TntWkWsSS6PQl2hkvnoIJCKJkieuOt/jtqga7fmzxKqPmv9HAIQjfFNTQIxL+MAVJB4I6B+tG9rpPTnsFICx4z4Ag4bUOLqB3mdlJ1eGRahGmqCP+d6HoYhChBI/z/RFnxQlx77CgwiKA9UrFSDCeeoWK4NpAAcQ7FSdFD58TLXuQKjN9aZ295BQIQbu9GrLBBTgqSGTDkTLhP8UbKKYq7cq97w28Uqa5EKqNMf2 B7f656fX oYErmTVb4GtS3938SKaqJfjBCkdLEUHK8OfAhjLdWWPadFHUK12YdJzvzSwBcTWHXKAc64s4JcgORF2L4CtfTUALNh6Qdq3/dEPLXpnm+wTPnxW7yjVzcayiZYBazkYwXlx1oVCzFL+7RJGwz0yT/Jk9ZK0QKzjF1dYmhZxGmOdY4HEd+U89GoseZC73pHSSCxiHRIyXKU+AVPB3gCOVhRGfMqW2IW1yTX4AJj7uy3lDl2dHg04quBJl6ljSEi5pftnrwrnldgcEQOvSXyx5OKSH3rt3c3PkVibfeF3mLfOt4BIf7e4BJc0h5rHL0alC0UkduWdkZyJaZ+GCCYJef2rSoTExo1/xGhtVhGWSDnISCy8Qd2kvlpBIngmGeE1QBeERY X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, 10 Jul 2024 20:20:28 +0800 zhangchun wrote: > Use kmap_high and kmap_XXX or kumap_xxx among differt cores at the same > time may cause deadlock. The issue is like this： What is kmap_XXX? > CPU 0: CPU 1: > kmap_high(){ kmap_xxx() { > ... irq_disable(); > spin_lock(&kmap_lock) > ... > map_new_virtual ... > flush_all_zero_pkmaps > flush_tlb_kernel_range /* CPU0 holds the kmap_lock */ > smp_call_function_many spin_lock(&kmap_lock) > ... .... > spin_unlock(&kmap_lock) > ... > > CPU 0 holds the kmap_lock, waiting for CPU 1 respond to IPI. But CPU 1 > has disabled irqs, waiting for kmap_lock, cannot answer the IPI. Fix > this by releasing kmap_lock before call flush_tlb_kernel_range, > avoid kmap_lock deadlock. > > Fixes: 3297e760776a ("highmem: atomic highmem kmap page pinning") Wow, that's 15 years old. Has the deadlock been observed? > --- a/mm/highmem.c > +++ b/mm/highmem.c > @@ -220,8 +220,11 @@ static void flush_all_zero_pkmaps(void) > set_page_address(page, NULL); > need_flush = 1; > } > - if (need_flush) > + if (need_flush) { > + unlock_kmap(); > flush_tlb_kernel_range(PKMAP_ADDR(0), PKMAP_ADDR(LAST_PKMAP)); > + lock_kmap(); > + } > } Why is dropping the lock like this safe? What data is it protecting and why is it OK to leave that data unprotected here?