From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 5 Dec 2018 11:44:09 -0800 From: Matthew Wilcox To: Anthony Yznaga Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, adobriyan@gmail.com, akpm@linux-foundation.org, vbabka@suse.cz, sfr@canb.auug.org.au, kirill.shutemov@linux.intel.com, rppt@linux.vnet.ibm.com, mhocko@suse.com, alexander.h.duyck@linux.intel.com, hannes@cmpxchg.org, miles.chen@mediatek.com, n-horiguchi@ah.jp.nec.com Subject: Re: [PATCH] /proc/kpagecount: return 0 for special pages that are never mapped Message-ID: <20181205194409.GB11646@bombadil.infradead.org> References: <1543963526-27917-1-git-send-email-anthony.yznaga@oracle.com> <20181205004836.GU10377@bombadil.infradead.org> <20181205012534.GW10377@bombadil.infradead.org> <540f7690-5fcd-04d6-edb3-a44ebd09e70c@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <540f7690-5fcd-04d6-edb3-a44ebd09e70c@oracle.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: On Wed, Dec 05, 2018 at 11:40:51AM -0800, Anthony Yznaga wrote: > On 12/04/2018 05:25 PM, Matthew Wilcox wrote: > > On Tue, Dec 04, 2018 at 05:18:32PM -0800, anthony.yznaga@oracle.com wrote: > >> On 12/04/2018 04:48 PM, Matthew Wilcox wrote: > >>> On Tue, Dec 04, 2018 at 02:45:26PM -0800, Anthony Yznaga wrote: > >>>> +static inline int page_has_type(struct page *page) > >>>> +{ > >>>> + return (PageType(page, 0) && > >>>> + ((page->page_type & PAGE_TYPE_ALL) != PAGE_TYPE_ALL)); > >>>> +} > >>>> + > >>> I think this is a bit complex, and a bit of a pain to update as we add > >>> new page types. How about this? > >>> > >>> return (int)page_type < -128; > >>> > >>> (I'm open to appropriate #defines to make this more obvious that it's ~0x7F) > >> I thought about having this: > >> > >> #define PAGE_TYPE_END��� 0xffffff80 > >> > >> static int inline page_has_type(struct page *page) > >> { > >> ��� return page->page_type > PAGE_TYPE_BASE && > >> ��� ������ page->page_type < PAGE_TYPE_END; > >> } > >> > >> But I opted for the additional complexity to avoid more false-positives from > >> possibly corrupted values.� I'm certainly fine with a simple approach, though. > > The way I'm thinking about this field is that usually it's _mapcount > > which is 0xffffffff to represent 0. We allow a certain small amount > > of underflow and still treat it as a mapcount. We also allow for some > > amount of overflow. So to be utterly precise, what you had there would > > have been fine, but for simplicity, I'd rather just do a signed compare > > against -128. > The signed compare does not allow for mapcount overflow.� Is that acceptable? > False-positives would be benign for /proc/kpagecount though from a debug > perspective it could be helpful to see overflowed mapcounts.� Some future > caller would need separate consideration. Nobody seems terribly interested in mapcount overflows. I got no response to https://lkml.org/lkml/2018/3/2/991