All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>, Anton Arapov <anton@redhat.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	William Cohen <wcohen@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] uprobes: Ignore unsupported instructions in uprobe_mmap
Date: Thu, 2 Aug 2012 22:12:25 +0530	[thread overview]
Message-ID: <20120802164225.GA4268@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120802135313.GA4334@redhat.com>

> > uprobe_mmap()->install_breakpoint() can fail if the probed insn is not
> > supported
> 
> But there are other reasons why it can fail,
> 
> > However failing mmap_region()/do_fork() because of a probe on an
> > unsupported instruction is wrong.
> 
> Srikar, I strongly, absolutely disagree. Please correct me, but..
> 
> Do you realize how much uprobes hooks in mmap_region/dup_mmap are broken?
> 
> (cough, can't resist, vma_adjust()->uprobe_mmap() is not right too, but
>  this is another story).
> 
> OK, lets start with dup_mmap:
> 
> 		// retval == 0
> 
> 		if (file && uprobe_mmap(tmp))
> 			goto out;
> 
> 	out:
> 		up_write(&mm->mmap_sem);
> 		flush_tlb_mm(oldmm);
> 		up_write(&oldmm->mmap_sem);
> 		return retval;
> 
> Given that retval == 0, what do you think dup_mmap() returns if
> uprobe_mmap() fails? And note that we didn't copy all vmas.
> OK, at least this can't crash (afaics), and easy to fix.
> 
> 
> But mmap_region() is worse, much worse. It simply can _not_ fail
> after uprobe_mmap (of course, I am not saying this is unfixable)
> without the crash. And note that the crash is "delayed". And btw,
> like dup_mmap(), mmap_region() doesn't return the error too.

Oh, thats really a bad mistake from my side. I apologize.

> 
> Srikar, I strongly believe this horror must not exist. Either
> we should teach mmap_region() and dup_mmap() (and vma_adjust!)
> to fail correctly, or we should ignore the error code.
> 
> It is that simple, isn't it?
> 

Right.

> Whatever you do with uprobe_mmap(), even if you change it to always
> return 0, the code in mmap_region() is absolutely, absolutely broken.
> 

But uprobe_mmap() still needs to walk thro the probe list and 
insert the other probes. Currently we just ignore the remaining probes
and that has to be fixed within uprobe_mmap.

> Do you agree?
> 
> And once again. I agree, in the long term we should reconsider
> this change. But we need a simple fix for now/stable.
> 

Agree.

> > Hence change uprobe_mmap() to ignore unsupported instructions.
> 
> OK. Now suppose that mmap_region()-> uprobe_mmap() fails because
> the caller is SIGKILL'ed (so __get_user_pages fails). Given that
> mmap_region() can't handle the error correctly, the kernel can
> crash.
> 

How about having your fix + my patch to fix the uprobe_mmap()?

-- 
Thanks and Regards
Srikar


  reply	other threads:[~2012-08-02 16:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-28 16:31 [PATCH] uprobes: mmap_region() corrupts mm->mm_rb if uprobe_mmap() fails Oleg Nesterov
2012-07-28 16:34 ` Oleg Nesterov
2012-07-30 13:22 ` William Cohen
2012-07-31  6:47 ` Srikar Dronamraju
2012-07-31 12:48   ` Oleg Nesterov
2012-07-31 13:25     ` Oleg Nesterov
2012-08-02 10:05     ` [PATCH] uprobes: Ignore unsupported instructions in uprobe_mmap Srikar Dronamraju
2012-08-02 13:53       ` Oleg Nesterov
2012-08-02 16:42         ` Srikar Dronamraju [this message]
2012-08-02 17:48           ` Oleg Nesterov
2012-08-03 12:13         ` Srikar Dronamraju
2012-08-03 13:38           ` Oleg Nesterov
2012-08-02 14:17       ` Oleg Nesterov
2012-08-02 16:54         ` Srikar Dronamraju
2012-08-02 17:53           ` Oleg Nesterov
2012-08-03  1:20             ` Srikar Dronamraju
2012-08-03 13:47               ` Oleg Nesterov
2012-08-03 17:46 ` [PATCH] uprobes: mmap_region() corrupts mm->mm_rb if uprobe_mmap() fails Srikar Dronamraju

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=20120802164225.GA4268@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=anton@redhat.com \
    --cc=fche@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=wcohen@redhat.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.