From: Oleg Nesterov <oleg@redhat.com>
To: Hugh Dickins <hughd@google.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())
Date: Fri, 16 May 2014 21:29:49 +0200 [thread overview]
Message-ID: <20140516192949.GA16446@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1405161120410.3604@eggly.anvils>
On 05/16, Hugh Dickins wrote:
>
> On Fri, 16 May 2014, Oleg Nesterov wrote:
> > On 05/16, Oleg Nesterov wrote:
> > >
> > > copy_insn() fails with -EIO if ->readpage == NULL
> >
> > In particular, this means that we can not probe the binaries on tmpfs.
> > This is pity.
>
> Yes, that is a pity: thanks for noticing.
Thanks to Denys ;)
> > It seems that the potential fix is trivial, copy_insn() could use
> > shmem_getpage_gfp(). But, is there any way to figure out that this
>
> shmem_getpage_gfp() itself is static: please use
> shmem_read_mapping_page(mapping, pgoff): inline in linux/shmem_fs.h,
> calls shmem_read_mapping_page_gfp() in mm/shmem.c (a very few places
> need to override gfp_mask too: you do not), calls shmem_getpage_gfp().
Even better, thanks,
> > inode/mapping/aops/whatever is actually shmem?
> >
> > I am looking at shmem_get_inode() and I see nothing which could help,
> > and shmem_aops/etc are all static.
>
> 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.
Heh. I need to do git pull more often, I guess. Great.
> 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.
>
> I notice shmem_mapping() checks backing_dev_info,
> whereas shmem_get_mapping_page_gfp() checks a_ops: no problem in that.
> But it reminds me that you should test uprobe on SysV SHM when you're
> done: again I think no problem, but there's an incestuous relationship
> between shm and shmem that can catch us out when adding such checks.
Hugh, thanks a lot!
Oleg.
next prev parent reply other threads:[~2014-05-16 19:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140516152919.GA30659@redhat.com>
2014-05-16 15:30 ` uprobes && shmem (Was: uprobes: Shift ->readpage check from __copy_insn() to uprobe_register()) Oleg Nesterov
2014-05-16 18:49 ` Hugh Dickins
2014-05-16 19:29 ` Oleg Nesterov [this message]
2014-05-17 2:07 ` Hugh Dickins
2014-05-17 16:58 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140516192949.GA16446@redhat.com \
--to=oleg@redhat.com \
--cc=dvlasenk@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=srikar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.