Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753680AbdHUNC1 (ORCPT ); Mon, 21 Aug 2017 09:02:27 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:60888 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753445AbdHUNCZ (ORCPT ); Mon, 21 Aug 2017 09:02:25 -0400 Date: Mon, 21 Aug 2017 09:02:18 -0400 From: Johannes Weiner To: Michal Hocko Cc: Brad Bolen , Jaegeuk Kim , Andrew Morton , Vladimir Davydov , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: kernel panic on null pointer on page->mem_cgroup Message-ID: <20170821130218.GA1371@cmpxchg.org> References: <20170808010150.4155-1-bradleybolen@gmail.com> <20170808162122.GA14689@cmpxchg.org> <20170808165601.GA7693@jaegeuk-macbookpro.roam.corp.google.com> <20170808173704.GA22887@cmpxchg.org> <20170808200849.GA1104@cmpxchg.org> <20170809014459.GB7693@jaegeuk-macbookpro.roam.corp.google.com> <20170809183825.GA26387@cmpxchg.org> <20170810115605.GQ23863@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170810115605.GQ23863@dhcp22.suse.cz> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 881 Lines: 19 On Thu, Aug 10, 2017 at 01:56:05PM +0200, Michal Hocko wrote: > On Wed 09-08-17 14:38:25, Johannes Weiner wrote: > > The issue is that writeback doesn't hold a page reference and the page > > might get freed after PG_writeback is cleared (and the mapping is > > unlocked) in test_clear_page_writeback(). The stat functions looking > > up the page's node or zone are safe, as those attributes are static > > across allocation and free cycles. But page->mem_cgroup is not, and it > > will get cleared if we race with truncation or migration. > > Is there anything that prevents us from holding a reference on a page > under writeback? Hm, I'm hesitant to add redundant life-time management to the page there just for memcg, which is not always configured in. Pinning the memcg instead is slightly more complex, but IMO has the complexity in a preferrable place. Would you agree?