From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753853AbbGOVTv (ORCPT ); Wed, 15 Jul 2015 17:19:51 -0400 Received: from mta-out1.inet.fi ([62.71.2.230]:37065 "EHLO johanna1.inet.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753280AbbGOVTu (ORCPT ); Wed, 15 Jul 2015 17:19:50 -0400 RazorGate-KAS: Rate: 5 RazorGate-KAS: {RECEIVED: dynamic ip detected} RazorGate-KAS: Envelope from: RazorGate-KAS: Version: 5.5.3 RazorGate-KAS: LuaCore: 80 2014-11-10_18-01-23 260f8afb9361da3c7edfd3a8e3a4ca908191ad29 RazorGate-KAS: Method: none RazorGate-KAS: Lua profiles 69136 [Nov 12 2014] RazorGate-KAS: Status: not_detected Date: Thu, 16 Jul 2015 00:18:53 +0300 From: "Kirill A. Shutemov" To: Christoph Lameter Cc: "Kirill A. Shutemov" , Andrew Morton , Andrea Arcangeli , Hugh Dickins , Dave Hansen , Mel Gorman , Rik van Riel , Vlastimil Babka , Naoya Horiguchi , Steve Capper , "Aneesh Kumar K.V" , Johannes Weiner , Michal Hocko , Jerome Marchand , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 00/16] Sanitize usage of ->flags and ->mapping for tail pages Message-ID: <20150715211853.GA25181@node.dhcp.inet.fi> References: <1426784902-125149-1-git-send-email-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 15, 2015 at 03:20:01PM -0500, Christoph Lameter wrote: > On Thu, 19 Mar 2015, Kirill A. Shutemov wrote: > > > Currently we take naive approach to page flags on compound -- we set the > > flag on the page without consideration if the flag makes sense for tail > > page or for compound page in general. This patchset try to sort this out > > by defining per-flag policy on what need to be done if page-flag helper > > operate on compound page. > > Well we hand pointers to head pages around if handling compound pages. > References to tail pages are dicey and should only be used in a limited > way. At least that is true in the slab allocators and that was my > understanding in earlier years. Therefore it does not make sense > then check for tail pages. This is preparation patchset for THP refcounting rework. With new refcounting sub-pages for THP can be mapped with PTEs, therefore we will see tail pages returned from pte_page(). I've tried ad-hoc approach to page flags wrt tail pages on earlier (pre LFS/MM) revisions of THP refcounting patchset. And IIRC, *you* pointed that it would be nice to have more systematic approach. And here's my attempt. > > For now I catched one case of illigal usage of page flags or ->mapping: > > sound subsystem allocates pages with __GFP_COMP and maps them with PTEs. > > It leads to setting dirty bit on tail pages and access to tail_page's > > ->mapping. I don't see any bad behaviour caused by this, but worth fixing > > anyway. > > Does this catch any errors? It helped to catch BUG fixed by c761471b58e6 (mm: avoid tail page refcounting on non-THP compound pages) and helped with work on refcounting patchset. > > This patchset makes more sense if you take my THP refcounting into > > account: we will see more compound pages mapped with PTEs and we need to > > define behaviour of flags on compound pages to avoid bugs. > > Ok that introduces the risk of pointers to tail pages becoming more of an > issue. But that does not affect non pagecache pages. We don't have huge pages in pagecache yet. Refcounting patchset only affects anon-THP. And makes compound pages suitable for pagecache. We also have PTE-mapped compound pages -- in sound subsystem and some drivers (framebuffer, etc.) -- Kirill A. Shutemov