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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox