do page fault in atomic bug on arm

[Andrew Lunn]

On Mon, Nov 27, 2017 at 10:40:34AM +0900, Masami Hiramatsu wrote:
> On Sun, 26 Nov 2017 22:59:58 +0800
> Alex Shi <alex.shi at linaro.org> wrote:
> 
> > cc mhiramat at kernel.org
> > 
> > Thanks a lot for look into this! :)
> > 
> > Regards
> > Alex
> > 
> > On 11/25/2017 04:25 AM, Russell King - ARM Linux wrote:
> > > On Fri, Nov 24, 2017 at 07:27:00PM +0000, Russell King - ARM Linux wrote:
> > >> Adding Tixy, as he's more knowledgable in this area - I suggest
> > >> someone knowledgable in this area runs
> > >>
> > >> 	ftracetest test.d/kprobe/multiple_kprobes.tc
> > >>
> > >> and fixes these bugs... also running the entire ftracetest suite
> > >> would probably also be a very good idea.
> > > 
> > > There's some other stupidities as well:
> > > 
> > > trace_kprobe: Inserting kprobe at __error_lpae+0
> > > trace_kprobe: Inserting kprobe at str_lpae+0
> > > trace_kprobe: Inserting kprobe at __error_p+0
> > > trace_kprobe: Inserting kprobe at str_p1+0
> > > trace_kprobe: Inserting kprobe at str_p2+0
> > > trace_kprobe: Could not insert probe at str_p2+0: -22
> > > 
> > > str_lpae: .asciz "\nError: Kernel with LPAE support, but CPU does not support LPAE.\n"
> > > str_p1: .asciz  "\nError: unrecognized/unsupported processor variant (0x"
> > > str_p2: .asciz  ").\n"
> > > 
> > > So we successfully placed a kprobe on some ASCII strings, which are
> > > used prior to the kernel being properly up and running, which means
> > > we have to use relative references to these strings, and relative
> > > references to strings in other sections is not simple.
> 
> Oops, that's my mistake. It should pick only text symbols.

Hi Masami, Russell

Does the fact you are allowed to put a kprobe on an ASCII string from
userspace indicate a real problem? I would of thought the kernel core
kprobe could would be looking at the type of a symbol and rejecting
such requests. So fix the core, keep this test and make sure you get
an EINVAL back?

   Andrew