* uprobes && shmem (Was: uprobes: Shift ->readpage check from __copy_insn() to uprobe_register()) [not found] <20140516152919.GA30659@redhat.com> @ 2014-05-16 15:30 ` Oleg Nesterov 2014-05-16 18:49 ` Hugh Dickins 0 siblings, 1 reply; 5+ messages in thread From: Oleg Nesterov @ 2014-05-16 15:30 UTC (permalink / raw) To: Hugh Dickins, Ingo Molnar Cc: Denys Vlasenko, Peter Zijlstra, Srikar Dronamraju, linux-kernel Hi Hugh, 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. 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 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. Oleg. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: uprobes && shmem (Was: uprobes: Shift ->readpage check from __copy_insn() to uprobe_register()) 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 2014-05-17 2:07 ` Hugh Dickins 0 siblings, 2 replies; 5+ messages in thread From: Hugh Dickins @ 2014-05-16 18:49 UTC (permalink / raw) To: Oleg Nesterov Cc: Johannes Weiner, Ingo Molnar, Denys Vlasenko, Peter Zijlstra, Srikar Dronamraju, linux-kernel 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. > > 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(). > 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. 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: uprobes && shmem (Was: uprobes: Shift ->readpage check from __copy_insn() to uprobe_register()) 2014-05-16 18:49 ` Hugh Dickins @ 2014-05-16 19:29 ` Oleg Nesterov 2014-05-17 2:07 ` Hugh Dickins 1 sibling, 0 replies; 5+ messages in thread From: Oleg Nesterov @ 2014-05-16 19:29 UTC (permalink / raw) To: Hugh Dickins Cc: Johannes Weiner, Ingo Molnar, Denys Vlasenko, Peter Zijlstra, Srikar Dronamraju, linux-kernel 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: uprobes && shmem (Was: uprobes: Shift ->readpage check from __copy_insn() to uprobe_register()) 2014-05-16 18:49 ` Hugh Dickins 2014-05-16 19:29 ` Oleg Nesterov @ 2014-05-17 2:07 ` Hugh Dickins 2014-05-17 16:58 ` Oleg Nesterov 1 sibling, 1 reply; 5+ messages in thread From: Hugh Dickins @ 2014-05-17 2:07 UTC (permalink / raw) To: Oleg Nesterov Cc: Johannes Weiner, Ingo Molnar, Denys Vlasenko, Peter Zijlstra, Srikar Dronamraju, linux-kernel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: uprobes && shmem (Was: uprobes: Shift ->readpage check from __copy_insn() to uprobe_register()) 2014-05-17 2:07 ` Hugh Dickins @ 2014-05-17 16:58 ` Oleg Nesterov 0 siblings, 0 replies; 5+ messages in thread From: Oleg Nesterov @ 2014-05-17 16:58 UTC (permalink / raw) To: Hugh Dickins Cc: Johannes Weiner, Ingo Molnar, Denys Vlasenko, Peter Zijlstra, Srikar Dronamraju, linux-kernel On 05/16, Hugh Dickins wrote: > > 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. Yes, this should work, swap_address_space() can't be seen as ->i_mapping, > (Sorry for going on about backporting, when you may have no such intention.) No, no, thanks for additional info. Perhaps we will actually backport this, at least in rhel. Although in the latter case perhaps it would be better to extract shmem_mapping() from 0cd6144aadd2, it is simple and straightforward. Thanks, Oleg. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-05-17 16:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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
2014-05-17 2:07 ` Hugh Dickins
2014-05-17 16:58 ` Oleg Nesterov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox