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=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable 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 3BD41C32771 for ; Tue, 7 Jan 2020 01:26:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B16720715 for ; Tue, 7 Jan 2020 01:26:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B16720715 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8F2F78E000C; Mon, 6 Jan 2020 20:26:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A3128E0001; Mon, 6 Jan 2020 20:26:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 791E98E000C; Mon, 6 Jan 2020 20:26:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id 6115D8E0001 for ; Mon, 6 Jan 2020 20:26:24 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id CF2ED8249980 for ; Tue, 7 Jan 2020 01:26:23 +0000 (UTC) X-FDA: 76349097846.14.word24_37c6c50ed6e23 X-HE-Tag: word24_37c6c50ed6e23 X-Filterd-Recvd-Size: 4202 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Jan 2020 01:26:23 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2020 17:26:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,404,1571727600"; d="scan'208";a="422314711" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by fmsmga006.fm.intel.com with ESMTP; 06 Jan 2020 17:26:19 -0800 Date: Tue, 7 Jan 2020 09:26:24 +0800 From: Wei Yang To: Alexander Duyck Cc: Wei Yang , Johannes Weiner , Michal Hocko , vdavydov.dev@gmail.com, Andrew Morton , "Kirill A. Shutemov" , cgroups@vger.kernel.org, linux-mm , LKML , Yang Shi Subject: Re: [RFC PATCH] mm: thp: grab the lock before manipulation defer list Message-ID: <20200107012624.GB15341@richard> Reply-To: Wei Yang References: <20200103143407.1089-1-richardw.yang@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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 Mon, Jan 06, 2020 at 08:18:34AM -0800, Alexander Duyck wrote: >On Fri, Jan 3, 2020 at 6:34 AM Wei Yang wrote: >> >> As all the other places, we grab the lock before manipulate the defer list. >> Current implementation may face a race condition. >> >> Fixes: 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware") >> >> Signed-off-by: Wei Yang >> >> --- >> I notice the difference during code reading and just confused about the >> difference. No specific test is done since limited knowledge about cgroup. >> >> Maybe I miss something important? >> --- >> mm/memcontrol.c | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index bc01423277c5..62b7ec34ef1a 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -5368,12 +5368,12 @@ static int mem_cgroup_move_account(struct page *page, >> } >> >> #ifdef CONFIG_TRANSPARENT_HUGEPAGE >> + spin_lock(&from->deferred_split_queue.split_queue_lock); >> if (compound && !list_empty(page_deferred_list(page))) { >> - spin_lock(&from->deferred_split_queue.split_queue_lock); >> list_del_init(page_deferred_list(page)); >> from->deferred_split_queue.split_queue_len--; >> - spin_unlock(&from->deferred_split_queue.split_queue_lock); >> } >> + spin_unlock(&from->deferred_split_queue.split_queue_lock); >> #endif >> /* >> * It is safe to change page->mem_cgroup here because the page > >So I suspect the lock placement has to do with the compound boolean >value passed to the function. > Hey, Alexander Thanks for your comment. >One thing you might want to do is pull the "if (compound)" check out >and place it outside of the spinlock check. It would then simplify >this signficantly so it is something like >if (compound) { > spin_lock(); > list = page_deferred_list(page); > if (!list_empty(list)) { > list_del_init(list); > from->..split_queue_len--; > } > spin_unlock(); >} > >Same for the block below. I would pull the check for compound outside >of the spinlock call since it is a value that shouldn't change and >would eliminate an unnecessary lock in the non-compound case. This is reasonable, if no objection from others, I would change this in v2. -- Wei Yang Help you, Help me