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 AC491C76188 for ; Wed, 5 Apr 2023 06:49:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E69356B0071; Wed, 5 Apr 2023 02:49:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF1B26B0072; Wed, 5 Apr 2023 02:49:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C920C6B0074; Wed, 5 Apr 2023 02:49:57 -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 B95746B0071 for ; Wed, 5 Apr 2023 02:49:57 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 75E5080EBC for ; Wed, 5 Apr 2023 06:49:57 +0000 (UTC) X-FDA: 80646412434.07.DBCA1C0 Received: from out30-97.freemail.mail.aliyun.com (out30-97.freemail.mail.aliyun.com [115.124.30.97]) by imf19.hostedemail.com (Postfix) with ESMTP id 6CD7B1A0005 for ; Wed, 5 Apr 2023 06:49:54 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of rongwei.wang@linux.alibaba.com designates 115.124.30.97 as permitted sender) smtp.mailfrom=rongwei.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680677395; 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=il0uAFHDKDYLRhMfO0R2H8qEnGZStihLGm/EoXqx4fI=; b=8m5viU4Hzr7sxufcNkDveN6miEkI83CtFjG6gT1EKkMY44sGpFcEuc4yHURX5O3PNJ5JDZ SuOo101pvnQ08XKrRjZ75Hv7xEVAp/IJYL+8UVUcwk1W1TVs72PhUSmIX8YPmTlRPP2wCx 22UZIauS/0Ed5NGEHExIlUdmpZpX8o8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of rongwei.wang@linux.alibaba.com designates 115.124.30.97 as permitted sender) smtp.mailfrom=rongwei.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680677395; a=rsa-sha256; cv=none; b=xlsqKll+f7zQS3YM79acg3RT1gmL7poBwVgotb+QiB/k7OfB9oE8AqDvJvPN3dIC77QWpe /P4pJNtS10yRFqxsPo5vDHoR1xhkNxjW0/mmDVapXPCFZaGEAdJSvUY9rVB2hfH4wrHE4b YJEmZreIpIXkj3lWgYZkOgBAyDJsQvY= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R211e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046049;MF=rongwei.wang@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0VfOIfDC_1680677388; Received: from 30.221.128.100(mailfrom:rongwei.wang@linux.alibaba.com fp:SMTPD_---0VfOIfDC_1680677388) by smtp.aliyun-inc.com; Wed, 05 Apr 2023 14:49:49 +0800 Message-ID: <527978d9-3f6f-b507-5f0f-b24311ff78e4@linux.alibaba.com> Date: Wed, 5 Apr 2023 14:49:48 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm/swap: fix swap_info_struct race between swapoff and get_swap_pages() To: Andrew Morton Cc: bagasdotme@gmail.com, willy@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Aaron Lu References: <20230401221920.57986-1-rongwei.wang@linux.alibaba.com> <20230404154716.23058-1-rongwei.wang@linux.alibaba.com> <20230404122600.88257a623c7f72e078dcf705@linux-foundation.org> Content-Language: en-US From: Rongwei Wang In-Reply-To: <20230404122600.88257a623c7f72e078dcf705@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: n43hu8bcp37jay7fnas8zni7zddzzae3 X-Rspam-User: X-Rspamd-Queue-Id: 6CD7B1A0005 X-Rspamd-Server: rspam06 X-HE-Tag: 1680677393-631210 X-HE-Meta: U2FsdGVkX19/yA1XWuP7RG7M/iXl+I/Xddx/cJvngsFXImHNmL2pMvM8Ja1cHQQbP95v+jayv50bwG1KWZRL2IwVNa7StLFhXj6byGI05gHo8RGoIq4bxdi8x6RDcXWrt8FfyhEVhUbxFj9pdsQJnu1v2CFuTow2rB4IMM+V/XjsGa76VQFLDdT6CpPI7GwZO08tpznNTQYRF6OZOiFIXwmOM1Sl46VbWIu/S/V1WM5uNM0OcbhSaCznF8ZVXckKc52dQOXbNQGDypAhV5bYJcaBVjgFpWYq1vZ0UA14ODTwYXUqvFWVnUeHrGBKiZuvnBGu6glcq5Y/mrLOqjRwZNlMIEGmmv5NgOOvgGAjn8lEacrSOPt/PPeiA5Lh5NpLNG/Ad14i7I9Gcjtv3VMr9ScVYF5fpCKVitGiIHMw3OK80LWRRi+HRxHh9a6+5GwwH8jYEr067DI52NNa8QrA2QmyuMfxEG0Ikp/gWJXBJUicfGhB3bGbKuOIm5ZTs72ILqQGx2ueC1j/L1MQAh0/VA3WJlejlF2PP9xuXRw/MsdShuc3v1ZrzzS+nfxLaUVIvtZS7AN+dgUH1+fZyhEXJHkbvmklpQ04Zz7o8g9Qru4FrfIEpOpe6ju88ntXjrEtXsmelN0ufVv7UodNK1eocepgIkLWlHLSsLdKGRsvNSG9Oj+blcrC7YR1h21pIzidTXgzkPM+n6Tj2PSqG/lAGc5btCmvkR/Y3FBZagR9A02yE970jKqGe0mA7AYRP2VQmKmoXZixzD6pHTnCv+5YtyWvGRmEEs8CjY4Gc0UAV/bhZvQN4a3h8viBCwuj31VMCHep7D3ap3VFY6Bguukpr7pFfa0HgwljQsBuyHlkWF+x4Z2lqT7y7J7zXdGZ8k5GIif3nt4LZKeW2c1YGLuvQrpryAj2Lga8dVjHNwjSYFhS0cFqdRlgnvJHlAcPuUztqDRC+1EZFzGf2qIJXkb Ka1lhjsw ZR++Qc9JYsZuYm+08NoQkz1omaBW/z8sdSqWnVXVPVDx6NdfsPkO9nn3RwlTeD4XruNoSFRE+px/VYOir3GmRUPyL5w/4dDeI3Tw3zllqQr/hPaD5k4+AadmrvtVFmYCqXiovrSolHw77VcvmbG09kD+3cq5GAWNgh8s9+O23MkjFlVLeQOgijm857XiFluMi8rlfqsR4FnMtSs+SXoQ1+OjPeA== 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: Hi Andrew On 4/5/23 3:26 AM, Andrew Morton wrote: > On Tue, 4 Apr 2023 23:47:16 +0800 Rongwei Wang wrote: > >> The si->lock must be held when deleting the si from >> the available list. >> >> ... >> >> --- a/mm/swapfile.c >> +++ b/mm/swapfile.c >> @@ -679,6 +679,7 @@ static void __del_from_avail_list(struct swap_info_struct *p) >> { >> int nid; >> >> + assert_spin_locked(&p->lock); >> for_each_node(nid) >> plist_del(&p->avail_lists[nid], &swap_avail_heads[nid]); >> } >> @@ -2434,8 +2435,8 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile) >> spin_unlock(&swap_lock); >> goto out_dput; >> } >> - del_from_avail_list(p); >> spin_lock(&p->lock); >> + del_from_avail_list(p); >> if (p->prio < 0) { >> struct swap_info_struct *si = p; >> int nid; > So we have > > swap_avail_lock > swap_info_struct.lock > swap_cluster_info.lock > > Is the ranking of these three clearly documented somewhere? It seems have swap_lock swap_info_struct.lock swap_avail_lock I just summary the ranking of these three locks by reading code, not find any documents (maybe have). > > > Did you test this with lockdep fully enabled? > > > I'm thinking that Aaron's a2468cc9bfdff ("swap: choose swap device > according to numa node") is the appropriate Fixes: target - do you > agree? Yes, I'm sure my latest test version has included Aaron's a2468cc9bfdff, and my test .config has enabled CONFIG as below: CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_PROVE_LOCKING=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_LOCKDEP=y CONFIG_DEBUG_LOCKDEP=y CONFIG_DEBUG_ATOMIC_SLEEP=y > > > These functions use identifier `p' for the swap_info_struct*, whereas > most other code uses the much more sensible `si'. That's just rude. > But we shouldn't change that within this fix. Indeed, It's confusing more or less to use both 'si' and 'p'. I can ready for another patch to replace 'p' with 'si'. Thanks.