linux-kernel - Re: [PATCH v5 3.1.0-rc4-tip 5/26] Uprobes: copy of the original instruction.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111005151111.GA28694@redhat.com>
Date:	Wed, 5 Oct 2011 17:11:11 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linux-mm <linux-mm@...ck.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Hugh Dickins <hughd@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jonathan Corbet <corbet@....net>,
	LKML <linux-kernel@...r.kernel.org>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Roland McGrath <roland@...k.frob.com>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v5 3.1.0-rc4-tip 5/26]   Uprobes: copy of the original
	instruction.

Srikar, warning.

I am going to discuss the things I do not really understand ;)
Hopefully someone will correct me if I am wrong.

On 10/05, Srikar Dronamraju wrote:
>
> * Oleg Nesterov <oleg@...hat.com> [2011-10-03 18:29:05]:
>
> > > +	page_cache_sync_readahead(mapping, &filp->f_ra, filp, idx, 1);
> >
> > This schedules the i/o,
> >
> > > +	page = grab_cache_page(mapping, idx);
> >
> > This finds/locks the page in the page-cache,
> >
> > > +	if (!page)
> > > +		return -ENOMEM;
> > > +
> > > +	vaddr = kmap_atomic(page);
> > > +	memcpy(insn, vaddr + off1, nbytes);
> >
> > What if this page is not PageUptodate() ?
>
> Since we do a synchronous read ahead, I thought the page would be
> populated and upto date.

What does this "synchronous" actually mean?

First of all, page_cache_sync_readahead() can simply return. Or
__do_page_cache_readahead() can "skip" the page if it is already in the
page cache.

IOW, we do not even know if ->readpage() was called. But even if it was
called, afaics (in general) the page will be unlocked and marked Uptodate
when I/O completes, not when ->readpage() returns.

> would these two lines after grab_cache_page help?
>
> 	if (!PageUptodate(page))
> 		mapping->a_ops->readpage(filp, page);

This doesn't look right. At least you need lock_page().

Anyway. Why you can't simply use read_mapping_page() or even kernel_read() ?

But the real question is:

> > But I am starting to think I simply do not understand this change.
> > To the point, I do not underestand why do we need copy_insn() at all.
> > We are going to replace this page, can't we save/analyze ->insn later
> > when we copy the content of the old page? Most probably I missed
> > something simple...

Could you please explain?

> > But this should not be possible, no? How it can map this vaddr above
> > TASK_SIZE ?
> >
> > get_user_pages(tsk => NULL) is fine. Why else do we need mm->owner ?
>
> >
> > Probably used by the next patches... Say, is_32bit_app(tsk). This
> > can use mm->context.ia32_compat (hopefully will be replaced with
> > MMF_COMPAT).
> >
>
> We used the tsk struct for checking if the application was 32 bit and
> for calling get_user_pages. Since we can pass NULL to get_user_pages and
> since we can use mm->context.ia32_compat or MMF_COMPAT, I will remove
> get_mm_owner, that way we dont need to be dependent on CONFIG_MM_OWNER.

Great!

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/