From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932262AbaEQCIj (ORCPT <rfc822;w@1wt.eu>);
	Fri, 16 May 2014 22:08:39 -0400
Received: from mail-pb0-f48.google.com ([209.85.160.48]:63545 "EHLO
	mail-pb0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755848AbaEQCIi (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 16 May 2014 22:08:38 -0400
Date: Fri, 16 May 2014 19:07:13 -0700 (PDT)
From: Hugh Dickins <hughd@google.com>
X-X-Sender: hugh@eggly.anvils
To: Oleg Nesterov <oleg@redhat.com>
cc: Johannes Weiner <hannes@cmpxchg.org>, Ingo Molnar <mingo@elte.hu>,
        Denys Vlasenko <dvlasenk@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
        linux-kernel@vger.kernel.org
Subject: Re: uprobes && shmem (Was: uprobes: Shift ->readpage check from
 __copy_insn() to uprobe_register())
In-Reply-To: <alpine.LSU.2.11.1405161120410.3604@eggly.anvils>
Message-ID: <alpine.LSU.2.11.1405161847040.5810@eggly.anvils>
References: <20140516152919.GA30659@redhat.com> <20140516153058.GA30667@redhat.com> <alpine.LSU.2.11.1405161120410.3604@eggly.anvils>
User-Agent: Alpine 2.11 (LSU 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 16 May 2014, Hugh Dickins wrote:
> On Fri, 16 May 2014, Oleg Nesterov wrote:
> > shmem_getpage_gfp(). But, is there any way to figure out that this
> > inode/mapping/aops/whatever is actually shmem?
> 
> On 3.15 and later, you're in luck: Hannes added bool shmem_mapping(mapping)
> in his 0cd6144aadd2 "mm + fs: prepare for non-page entries in page cache
> radix trees"; and I just checked, it builds for "tiny" !CONFIG_SHMEM too.
> 
> If you're backporting to an earlier kernel, it would probably be best
> to add in a very small patch, extracting just shmem_mapping() and its
> linux/mm.h declarations from 0cd6144aadd2.

Looking into something else, I've just been reminded of
mapping_cap_swap_backed(mapping): mm/madvise.c has been using that test
for a year.  It also returns true on swapper_space, the imaginary mapping
you get from a PageSwapCache page: so I suppose it would be wrong to make
Hannes's shmem_mapping() a wrapper to that.  But for any backport of your
change, it would better than extracting part of 0cd6144aadd2.

(Sorry for going on about backporting, when you may have no such intention.)

Hugh