Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3427754pxk; Mon, 28 Sep 2020 18:05:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxbqH8zurAlW0RGDVeyUm6G62LtIzwK/tiz0lRRBwAmubQT5MP1umhIw9NvWXlnKq7NUTBQ X-Received: by 2002:a17:906:bc98:: with SMTP id lv24mr1434431ejb.411.1601341522554; Mon, 28 Sep 2020 18:05:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601341522; cv=none; d=google.com; s=arc-20160816; b=o8FLi5ca8f4epxUEzLwJ1IAmsSJba3HYE1GcVKhGPaQ1tnSNjDOVwTiNQqRRJCr9gQ GNHJc3BHixEVGO1yPdH0bfyTE9D/cbdvdHQDD1PeQFHWku0rhSd9uVOGBz0+/eu18XOn AZHm0jkw7AfufUOUdCCsszsV01aZC3bsMw+6SuHqGyyAdFOP6IwHNVT6WWQkiXOylwhW xJEMPdMjB6uREh+WtM0ULxnb+i18T1iwdB94sxutHmB2zzuuxBbpgY3Cpof0E/qmMC1c evn11EStp+JjlbnZuXVRfRnbOzSeAWRjYoAX7EfZOJNcnvxSqXw0CGX6z8rtXpuJBg/9 3cSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=cmYcb8S3o6OTI+JMztHcBgwtBnNMr3AaKOPTFCLByMY=; b=BTzn6Q9iEOkW4cuGMm2/He0vQhPVoBuGa1q9nOInySoqZK3ghpq4tqBKZbm0mhM+3z Ja4zS2u66+OYQZvcqxU/xa08mxXYTJIYPz47tDrENSaqIk2JmCxtE9uVglAjqgcUn0Rn 52v4wn4IgduboWLLuWuoC/BWhNmWHWkXtfZpqxi4Po27X245x+a4mrf7ALGmTTNilGd/ AZx/ZFbRyGKrZjR/tzMFnO9MCRbVC1ci9xByPy2q6usQKNZYbb1H1Ttfw9UhcbpnM4T6 GBmdkJ3VG1B7/TqyIHI1ygYsgKd2HvBFZD9pMzHaIm8hmo+J2GREn7hfd5Bddxxn6ZHQ ZK/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="obogJ7/b"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mb24si1635173ejb.583.2020.09.28.18.04.53; Mon, 28 Sep 2020 18:05:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="obogJ7/b"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727161AbgI2BDJ (ORCPT + 99 others); Mon, 28 Sep 2020 21:03:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:33092 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726698AbgI2BDJ (ORCPT ); Mon, 28 Sep 2020 21:03:09 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 91BDA207C4; Tue, 29 Sep 2020 01:03:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601341388; bh=qUqNMPceAYwULHvwzL9M1XQiqeX3zMRo9KGrVYcVkjE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=obogJ7/blmlFwHh/iTIA/RUNLMj7jn6jcs7QiXkMIruzgBluF9VFsVfT3i15rgo7O XbQJ1BDtk1Q6M+lMrbdoR5ZTN5JZ/xgxWJvJeVPWtXFrEkS91d7lN8T3IAVHH8UvKa gt7PQeeXFm+elZPC6zZ3J2gzctGqE/Ey1Q5hOAW8= Date: Mon, 28 Sep 2020 18:03:07 -0700 From: Andrew Morton To: "Matthew Wilcox (Oracle)" Cc: Nick Piggin , Hugh Dickins , Peter Zijlstra , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] page_alloc: Fix freeing non-compound pages Message-Id: <20200928180307.7573f3b6128b5e3007dfc9f0@linux-foundation.org> In-Reply-To: <20200926213919.26642-1-willy@infradead.org> References: <20200926213919.26642-1-willy@infradead.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 26 Sep 2020 22:39:19 +0100 "Matthew Wilcox (Oracle)" wrote: > Here is a very rare race which leaks memory: Not worth a cc:stable? > Page P0 is allocated to the page cache. Page P1 is free. > > Thread A Thread B Thread C > find_get_entry(): > xas_load() returns P0 > Removes P0 from page cache > P0 finds its buddy P1 > alloc_pages(GFP_KERNEL, 1) returns P0 > P0 has refcount 1 > page_cache_get_speculative(P0) > P0 has refcount 2 > __free_pages(P0) __free_pages(P0, 1), I assume. > P0 has refcount 1 > put_page(P0) but this is implicitly order 0 > P1 is not freed huh. > Fix this by freeing all the pages in __free_pages() that won't be freed > by the call to put_page(). It's usually not a good idea to split a page, > but this is a very unlikely scenario. > > ... > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4947,6 +4947,9 @@ void __free_pages(struct page *page, unsigned int order) > { > if (put_page_testzero(page)) > free_the_page(page, order); > + else if (!PageHead(page)) > + while (order-- > 0) > + free_the_page(page + (1 << order), order); Well that's weird and scary looking. `page' has non-zero refcount yet we go and free random followon pages. Methinks it merits an explanatory comment?