[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sivp7eai.fsf@rustcorp.com.au>
Date: Fri, 25 Oct 2013 22:28:29 +1030
From: Rusty Russell <rusty@...tcorp.com.au>
To: Ming Lei <tom.leiming@...il.com>
Cc: Russell King - ARM Linux <linux@....linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Chen Gang <gang.chen@...anux.com>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH] kernel/kallsyms.c: only show legal kernel symbol
Ming Lei <tom.leiming@...il.com> writes:
> On Fri, Oct 25, 2013 at 1:50 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
>> Ming Lei <tom.leiming@...il.com> writes:
>>> On Fri, Oct 25, 2013 at 7:08 AM, Rusty Russell <rusty@...tcorp.com.au> wrote:
>>>>
>>>> Sorry, I was imprecise. I was referring to the kernel's kallsyms
>>>> tables produced by scripts/kallsyms.c. This patch left them in the
>>>> the kallsyms tables and filtered them out from /proc/kallsyms.
>>>
>>> Yes, but it isn't easy to do it by script/kallsyms.c , and IMO, it should
>>> be correct to hide them for user space but keep them in kallsyms table.
>>
>> So they'll appear in backtraces? And turn up randomly for other symbol
>> dereferences?
>>
>> I don't think you really want this!
>
> Basically these symbols are only used to generate code, and in
> kernel mode, CPU won't run into the corresponding addresses
> because the generate code is copied to other address during booting,
> so I understand they won't appear in backtraces.
An oops occurs when something went *wrong*. We look up all kinds of
stuff. Are you so sure that *none* of the callers will ever see these
strange symbols and produce a confusing result?
Cheers,
Rusty.
--
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/
Powered by blists - more mailing lists