All of lore.kernel.org
 help / color / mirror / Atom feed
From: zhouchengming <zhouchengming1@huawei.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@suse.de>, <ananth@linux.vnet.ibm.com>,
	<anil.s.keshavamurthy@intel.com>, <davem@davemloft.net>,
	<hpa@zytor.com>, <tglx@linutronix.de>, <peterz@infradead.org>,
	<jkosina@suse.cz>, <rostedt@goodmis.org>, <mjurczyk@google.com>,
	<x86@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules
Date: Sat, 28 Oct 2017 17:51:46 +0800	[thread overview]
Message-ID: <59F45332.7050806@huawei.com> (raw)
In-Reply-To: <20171028174310.384d62976cc5ba4859325d3a@kernel.org>

On 2017/10/28 16:43, Masami Hiramatsu wrote:
> On Fri, 27 Oct 2017 21:30:24 +0800
> zhouchengming<zhouchengming1@huawei.com>  wrote:
>
>> On 2017/10/27 20:33, Borislav Petkov wrote:
>>> On Fri, Oct 27, 2017 at 07:42:45PM +0800, zhouchengming wrote:
>>>> This is a real bug happened on one of our machines, below is the calltrace.
>>>> We can see the trigger is at alternatives_text_reserved+0x20/0x80, and
>>>> encounter a deleted (poisoned) list_head.
>>> Looks like some out-of-tree, old kernel thing. We don't have
>>> mlx4_stats_sysfs_create() upstream and looking at the boot timestamps,
>>> it could be that register_jprobe() is not ready yet.
>> Yes, it's an out-of-tree module, loaded when boot kernel. register_kprobe()
>> maybe not ready yet, but the bug is not caused by it obviously.
>>
>>> Looking at the Code, though:
>>>
>>>     20:   74 59                   je     0x7b
>>>     22:   66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)
>>>     29:   00 00
>>>     2b:*  48 3b 71 20             cmp    0x20(%rcx),%rsi<-- trapping instruction
>>>     2f:   72 3a                   jb     0x6b
>>>     31:   48 3b 79 28             cmp    0x28(%rcx),%rdi
>>>     35:   77 34                   ja     0x6b
>>>
>>> %rcx is 0xdead0000000000d0 and that is POISON_POINTER_DELTA + 0xd0 so
>>> that looks more like smp_alt_modules is not initialized yet but I could
>>> could very well be wrong because this is an old kernel. So trigger that
>>> with the upstream kernel without out of tree modules.
>> The smp_alt_modules is defined by LIST_HEAD, so it's initialized at start.
>>
>> A deleted list_head->next = LIST_POISON1 = 0xdead000000000000 + 0x100, then
>> container_of() to get the struct smp_alt_module: -0x30 = 0xdead0000000000d0
>>
>> Obviously, it's a deleted list_head, and I have explained clearly how it happen in
>> the patch comment.
> Ah, I see. It looks alternatives_text_reserved() bug at a glance.
> But simply adding smp_alt mutex to alternatives_text_reserved() causes
> ABBA deadlock in the kprobe's path.
> So your solution is to replace the smp_alt with text_mutex, since
> alternatives_text_reserved is x86 specific function.
>
> Hmm, let me see... I agree that will be a simple way to solve, but
> it also means we have 2 resources protected by text_mutex.

Yes, the smp_alt mutex must be held outside the text_mutex, this is a simpler way
to solve, because we will need another x86 specific interface if we want to hold
the smp_alt mutex.

But like you said, it's not good to use one text_mutex to protect 2 resources...
I hope there is any better way.

Thanks.

> Thank you,
>
>

  reply	other threads:[~2017-10-28  9:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-27  9:34 [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules Zhou Chengming
2017-10-27 11:15 ` Borislav Petkov
2017-10-27 11:42   ` zhouchengming
2017-10-27 12:33     ` Borislav Petkov
2017-10-27 13:30       ` zhouchengming
2017-10-28  8:43         ` Masami Hiramatsu
2017-10-28  9:51           ` zhouchengming [this message]
2017-10-27 14:15       ` Peter Zijlstra
2017-10-28  1:26         ` zhouchengming
2017-10-28  8:44           ` Masami Hiramatsu
2017-10-30  8:03 ` Masami Hiramatsu
2017-10-31 21:59   ` Steven Rostedt
2017-11-01  1:48     ` zhouchengming

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=59F45332.7050806@huawei.com \
    --to=zhouchengming1@huawei.com \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=bp@suse.de \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mjurczyk@google.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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.