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=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 24FA9C433E0 for ; Fri, 12 Jun 2020 10:30:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BC0C220792 for ; Fri, 12 Jun 2020 10:30:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC0C220792 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 416AF8D00BC; Fri, 12 Jun 2020 06:30:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C59B8D00A0; Fri, 12 Jun 2020 06:30:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DA718D00BC; Fri, 12 Jun 2020 06:30:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 13F778D00A0 for ; Fri, 12 Jun 2020 06:30:58 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C481A181AC9BF for ; Fri, 12 Jun 2020 10:30:57 +0000 (UTC) X-FDA: 76920191754.27.paste01_4510cec26ddb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 852C93D668 for ; Fri, 12 Jun 2020 10:30:57 +0000 (UTC) X-HE-Tag: paste01_4510cec26ddb X-Filterd-Recvd-Size: 3510 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Fri, 12 Jun 2020 10:30:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 27B6CAEFA; Fri, 12 Jun 2020 10:30:59 +0000 (UTC) Subject: Re: [PATCH] mm, page_alloc: capture page in task context only To: Hugh Dickins , Mel Gorman Cc: Andrew Morton , Li Wang , Alex Shi , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: From: Vlastimil Babka Message-ID: <01287865-153d-42e7-afd8-1178ec6bc5b9@suse.cz> Date: Fri, 12 Jun 2020 12:30:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 852C93D668 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 6/10/20 10:48 PM, Hugh Dickins wrote: > While stressing compaction, one run oopsed on NULL capc->cc in > __free_one_page()'s task_capc(zone): compact_zone_order() had been > interrupted, and a page was being freed in the return from interrupt. > > Though you would not expect it from the source, both gccs I was using > (a 4.8.1 and a 7.5.0) had chosen to compile compact_zone_order() with > the ".cc = &cc" implemented by mov %rbx,-0xb0(%rbp) immediately before > callq compact_zone - long after the "current->capture_control = &capc". > An interrupt in between those finds capc->cc NULL (zeroed by an earlier > rep stos). Ugh, nasty. Same here with gcc 10. > This could presumably be fixed by a barrier() before setting > current->capture_control in compact_zone_order(); but would also need > more care on return from compact_zone(), in order not to risk leaking > a page captured by interrupt just before capture_control is reset. I was hoping a WRITE_ONCE(current->capture_control) would be enough, but apparently it's not (I tried). > Maybe that is the preferable fix, but I felt safer for task_capc() to > exclude the rather surprising possibility of capture at interrupt time. > Fixes: 5e1f0f098b46 ("mm, compaction: capture a page under direct compaction") > Cc: stable@vger.kernel.org # 5.1+ > Signed-off-by: Hugh Dickins Acked-by: Vlastimil Babka But perhaps I would also make sure that we don't expose the half initialized capture_control and run into this problem again later. It's not like this is a fast path where barriers hurt. Something like this then? (with added comments) diff --git a/mm/compaction.c b/mm/compaction.c index fd988b7e5f2b..c89e26817278 100644 --- a/mm/compaction.c +++ b/mm/compaction.c @@ -2316,15 +2316,17 @@ static enum compact_result compact_zone_order(struct zone *zone, int order, .page = NULL, }; - current->capture_control = &capc; + barrier(); + + WRITE_ONCE(current->capture_control, &capc); ret = compact_zone(&cc, &capc); VM_BUG_ON(!list_empty(&cc.freepages)); VM_BUG_ON(!list_empty(&cc.migratepages)); - *capture = capc.page; - current->capture_control = NULL; + WRITE_ONCE(current->capture_control, NULL); + *capture = READ_ONCE(capc.page); return ret; }