All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: syzbot <syzbot+30d675e3ca03c1c351e7@syzkaller.appspotmail.com>,
	bp@suse.de, hpa@zytor.com, linux-kernel@vger.kernel.org,
	mingo@redhat.com, ricardo.neri-calderon@linux.intel.com,
	syzkaller-bugs@googlegroups.com, tglx@linutronix.de,
	x86@kernel.org, yhs@fb.com
Subject: Re: WARNING in arch_uprobe_analyze_insn
Date: Tue, 15 May 2018 18:18:18 +0200	[thread overview]
Message-ID: <20180515161818.GA22580@redhat.com> (raw)
In-Reply-To: <20180515234825.d9bea077f296354f3724f736@kernel.org>

On 05/15, Masami Hiramatsu wrote:
>
> On Tue, 15 May 2018 15:36:30 +0200
> Oleg Nesterov <oleg@redhat.com> wrote:
>
> > Unfortunately, insn_get_length() returns void, and I do not see any
> > insn-was-decoded-correctly helper. Perhaps we should simply remove
> > this WARN_ON() ?
>
> Yes, it should just return an error,

OK, I'll send the fix,

> since user can miss the
> probe address on user binary and we can not make sure
> that is on a instruction boundary.

Or this insn is actually invalid.

> > Alternatively, If am right we can move this check down after the "good_insns"
> > checks, but this doesn't look very clean to me.
>
> I think it is enough if arch_uprobe_analyze_insn() returns an error.
> That makes prepare_uprobe() fail and finally leads uprobe_register()
> fail.

I meant that this way we could probably keep WARN_ON(). Nevermind.

Thanks!

Oleg.

  reply	other threads:[~2018-05-15 16:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14 14:24 WARNING in arch_uprobe_analyze_insn syzbot
2018-05-15 13:36 ` Oleg Nesterov
2018-05-15 14:48   ` Masami Hiramatsu
2018-05-15 16:18     ` Oleg Nesterov [this message]
2018-05-18 16:27 ` [PATCH] uprobes/x86: remove the wrong WARN_ON() in uprobe_init_insn() Oleg Nesterov
2018-05-18 23:58   ` Masami Hiramatsu

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=20180515161818.GA22580@redhat.com \
    --to=oleg@redhat.com \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ricardo.neri-calderon@linux.intel.com \
    --cc=syzbot+30d675e3ca03c1c351e7@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yhs@fb.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.