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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42EE2C433E0 for ; Wed, 20 Jan 2021 07:54:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CC64523131 for ; Wed, 20 Jan 2021 07:54:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC64523131 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1DAFA6B0007; Wed, 20 Jan 2021 02:54:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 18A1F6B0008; Wed, 20 Jan 2021 02:54:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A18C6B000A; Wed, 20 Jan 2021 02:54:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E7DB46B0007 for ; Wed, 20 Jan 2021 02:54:10 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B69FE364B for ; Wed, 20 Jan 2021 07:54:10 +0000 (UTC) X-FDA: 77725390260.03.son14_161350d27558 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 9173628A4E8 for ; Wed, 20 Jan 2021 07:54:10 +0000 (UTC) X-HE-Tag: son14_161350d27558 X-Filterd-Recvd-Size: 3843 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Wed, 20 Jan 2021 07:54:09 +0000 (UTC) IronPort-SDR: s56Dbjix1FAxvSJvtfL1+nURxrbvd9XX6F07zNEh9yFuRFKvgEG2NtPnU0w6H7EepMoqIrwOgh j+KmWGAV5QSw== X-IronPort-AV: E=McAfee;i="6000,8403,9869"; a="175558078" X-IronPort-AV: E=Sophos;i="5.79,360,1602572400"; d="scan'208";a="175558078" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2021 23:54:07 -0800 IronPort-SDR: TToS1xbmD5KXL6u7aIH++681gRiINd4wSqoCGaIChWKbqYfrMcC0DuWnfRuxuBZ+2wJ5mQc7Hp d0OCr7xmDUuA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,360,1602572400"; d="scan'208";a="466995394" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.145]) by fmsmga001.fm.intel.com with ESMTP; 19 Jan 2021 23:54:04 -0800 From: "Huang\, Ying" To: Michal Hocko Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Joonsoo Kim , Johannes Weiner , Vlastimil Babka , Mel Gorman , Dan Williams , Christoph Hellwig Subject: Re: [PATCH] swap: Check nrexceptional of swap cache before being freed References: <20210120072711.209099-1-ying.huang@intel.com> <20210120074652.GA9371@dhcp22.suse.cz> Date: Wed, 20 Jan 2021 15:54:04 +0800 In-Reply-To: <20210120074652.GA9371@dhcp22.suse.cz> (Michal Hocko's message of "Wed, 20 Jan 2021 08:46:52 +0100") Message-ID: <87v9bst55v.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii 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: Michal Hocko writes: > On Wed 20-01-21 15:27:11, Huang Ying wrote: >> To catch the error in updating the swap cache shadow entries or their count. > > What is the error? There's no error in the current code. But we will change the related code in the future. So this checking will help us to prevent error in the future. I will change the patch description to make it more clear. > Can it happens in the real life? Why do we need this > patch? Is crashing the kernel the right way to handle the situation? Emm... The mistake to update swap shadow entries will hurt performance, but will not trigger functionality bug. So it may be better to use VM_WARN_ON_ONCE(). Best Regards, Huang, Ying >> Signed-off-by: "Huang, Ying" >> Cc: Minchan Kim >> Cc: Joonsoo Kim , >> Cc: Johannes Weiner , >> Cc: Vlastimil Babka , Hugh Dickins , >> Cc: Mel Gorman , >> Cc: Michal Hocko , >> Cc: Dan Williams , >> Cc: Christoph Hellwig , Ilya Dryomov , >> --- >> mm/swap_state.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/mm/swap_state.c b/mm/swap_state.c >> index d0d417efeecc..240a4f97594a 100644 >> --- a/mm/swap_state.c >> +++ b/mm/swap_state.c >> @@ -703,7 +703,12 @@ int init_swap_address_space(unsigned int type, unsigned long nr_pages) >> >> void exit_swap_address_space(unsigned int type) >> { >> - kvfree(swapper_spaces[type]); >> + int i; >> + struct address_space *spaces = swapper_spaces[type]; >> + >> + for (i = 0; i < nr_swapper_spaces[type]; i++) >> + VM_BUG_ON(spaces[i].nrexceptional); >> + kvfree(spaces); >> nr_swapper_spaces[type] = 0; >> swapper_spaces[type] = NULL; >> } >> -- >> 2.29.2