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 A0A1BC3DA41 for ; Thu, 11 Jul 2024 07:07:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED8F26B0093; Thu, 11 Jul 2024 03:07:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E60896B0095; Thu, 11 Jul 2024 03:07:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D016B6B0096; Thu, 11 Jul 2024 03:07:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B0F5B6B0093 for ; Thu, 11 Jul 2024 03:07:43 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3035E40427 for ; Thu, 11 Jul 2024 07:07:43 +0000 (UTC) X-FDA: 82326591606.02.D8D8D28 Received: from h3cspam02-ex.h3c.com (smtp.h3c.com [60.191.123.50]) by imf24.hostedemail.com (Postfix) with ESMTP id 7A93818001F for ; Thu, 11 Jul 2024 07:07:39 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of zhang.chunA@h3c.com designates 60.191.123.50 as permitted sender) smtp.mailfrom=zhang.chunA@h3c.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720681643; a=rsa-sha256; cv=none; b=KTbUM/VS/hl5oTvqWoGj4FLPjbjGkVvgCW0aFyxCdjx405vy4oSvCvkERfOTFXiFPuJO9d 7b+V7l4EDHStamamZSEUP0rHwjKeKNQtTVaWOJsjZN6Vt0sKQKIGJqo1CetV44qtvMLlQi s5gRxOuvhUAi45HEGQBoZlxvQqDUdZU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of zhang.chunA@h3c.com designates 60.191.123.50 as permitted sender) smtp.mailfrom=zhang.chunA@h3c.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720681643; 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=4PWi7A69Zdi+e0UWnBCR2DAv/AzPC0vPxXlJiDJwlUU=; b=nBmh8mdlocUTXsKcHR/5AhYk6UwVBkWVxW0D6dI4dWblHKIelnYdp6vEMjisao4ogPyvLt Fvrfj8AH2NA47INKOXqg4x7hVQrxKKNf/SULvDg+KyDHMvzfPCsHw+hru0Bktld73VOfux HBSgTzoEZuNJcOMZTgKLDao25GWhoaY= Received: from mail.maildlp.com ([172.25.15.154]) by h3cspam02-ex.h3c.com with ESMTP id 46B76Vht095028; Thu, 11 Jul 2024 15:06:31 +0800 (GMT-8) (envelope-from zhang.chunA@h3c.com) Received: from DAG6EX09-BJD.srv.huawei-3com.com (unknown [10.153.34.11]) by mail.maildlp.com (Postfix) with ESMTP id 6F1402307389; Thu, 11 Jul 2024 15:10:48 +0800 (CST) Received: from localhost.localdomain.com (10.99.206.13) by DAG6EX09-BJD.srv.huawei-3com.com (10.153.34.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1258.27; Thu, 11 Jul 2024 15:06:33 +0800 From: zhangchun To: CC: , , , , , , Subject: [PATCH v2] =?UTF-8?q?mm:=20Give=20kmap=5Flock=20before=20call=20flus?= =?UTF-8?q?h=5Ftlb=5Fkernel=5Frang=EF=BC=8Cavoid=20kmap=5Fhigh=20deadlock.?= Date: Thu, 11 Jul 2024 15:07:56 +0800 Message-ID: <1720681676-53147-1-git-send-email-zhang.chuna@h3c.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <20240710103611.809895ff809df9ed411bfaa8@linux-foundation.org> References: <20240710103611.809895ff809df9ed411bfaa8@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.99.206.13] X-ClientProxiedBy: BJSMTP02-EX.srv.huawei-3com.com (10.63.20.133) To DAG6EX09-BJD.srv.huawei-3com.com (10.153.34.11) X-DNSRBL: X-MAIL:h3cspam02-ex.h3c.com 46B76Vht095028 X-Stat-Signature: hoj58xag6gjsa6dqpcn3gug7rmp4swxj X-Rspamd-Queue-Id: 7A93818001F X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1720681659-997846 X-HE-Meta: U2FsdGVkX18wvb4MmoddXxVFNo3rHxG11VouKfmtr5taZ0p1qA6AipynXceTvNO3P/ynmz9z0e/YgCzreR8wyLdr/6LYwwKVuoLFg8vwFi/Tjb8oMGJzmtN6nocR1WHIVwSwdD6t8JKcU+nWltfXMen2y45TRN+VMDMz0weuNMBO3Ia7QiB7BC5KiFfATlVU0qYelp8DgoJx7JZpVDydMOeH3ptc9jD4+AOAIhl5Hgflpac05ptoe7lTZ61I8coqmXnCPquF50aYR4ANrBkepJkHiU6IeKhuLmxGQnGlJ0vxy59qI6zkojoAim5lLvU7Pf8fkTjipmzsxAdf3difLVWYZGBvgk70xD3xG+v9clt/m4sfYt/zNyTQgO63MNE///jGjQ4Rly0iy9UsR6DevITNCotNATZYbQktGzT6wfgPNnlXzYVQ4svj0Qz7i5cpUnVYh0SvCmeOuxFqbMlrkmMHz3Qh5nxyzhAv8rZvoqzafC1Cme0ua+D2D1bxo4j1N1u1wr99wZY8dDu7vDkEVyxQ7o+u56y/xNxNdBcn13xPaWxCmlljWtptJqJzEGdZQ8JGwG3XXMCDljZQdnn/jY08so/SIbF6/eLH++cWbyijAIt8FFw50emwjYJ375TtyVCZwIVD8ZUTTSKf1ZB4+0/2e8dtyZkIL+BKGUwWkxik+IBoraZ9rg2xgzQ+05FC9KrjsKhQatW+X1ZBX67lrS4TNud8JKGpxtg8LstTXFP7pfsCbvnvEesS/e02U+mEvsqHKJer8Rv0Ks6P8WhCJ0HyKBE9+Xw+fehKBvIi2QXJNW2KkMqboKs6iDjtSSDHU/8LhEzV5uOarWuoW9p/P7jMsncmiPHbyaUdh6rBUHPuqC0nJN7gb7EDarnoc8AfskgBX842WWAKufRJAnNtYDhP16jVvEVdS2wh6J/zwF6d+uTtllGji8IQrcrTp8Znfhaf7lQhHz1RI4M/cIb UrLk2rk1 TtOKHGKCSRLC2XT5PPsMb2FrQz5rftFX/gte8IIJVNd3hVzIb6HZgUA8fQRlAwqNL7HBt8O5M9Jc3AfkMSRfzoenTYrj0/8ro7mAnMU8QBT7b5fjNA0Fu/EhtLGd+iGSnPAQQU6pjmSlsZoMe/KmEOF6AS9O58g//npCSwcALjy9Bwg0L5I56eS7fJ4eCc+UWpuE5 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001456, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: >> 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? kmap/kunmap. >> 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? Yeah, the device crashed due to this reason. >> --- 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? kmap_lock is used to protect pkmap_count, pkmap_page_table and last_pkmap_nr(static variable). When call flush_tlb_kernel_range(PKMAP_ADDR(0), PKMAP_ADDR(LAST_PKMAP)), flush_tlb_kernel_range will neither modify nor read these variables. Leave that data unprotected here is safe. -- 1.8.3.1