Re: printk badness with VMAP_STACK

2016-10-27 Thread Petr Mladek
On Wed 2016-10-26 15:55:00, Laura Abbott wrote: > Hi, > > I was playing around with overflowing stacks and I managed to generate a test > case that hung the kernel with vmapped stacks. The test case is just > > static void noinline foo1(void) > { >pr_info("%p\n", (void *)current_stack_poi

Re: printk badness with VMAP_STACK

2016-10-27 Thread Sergey Senozhatsky
Hello, thanks for Cc-ing. On (10/27/16 11:19), Petr Mladek wrote: [..] > Yeah, logbuf_lock is taken on many locations but logbuf_cpu is set > only in vprintk_emit(). It means that the other locations, including > console_unlock() are not protected against this type of recursion. > > There is act

Re: printk badness with VMAP_STACK

2016-10-26 Thread Laura Abbott
On 10/26/2016 04:34 PM, Linus Torvalds wrote: On Wed, Oct 26, 2016 at 3:55 PM, Laura Abbott wrote: I was playing around with overflowing stacks and I managed to generate a test case that hung the kernel with vmapped stacks. The test case is just static void noinline foo1(void) { pr_inf

Re: printk badness with VMAP_STACK

2016-10-26 Thread Linus Torvalds
On Wed, Oct 26, 2016 at 3:55 PM, Laura Abbott wrote: > > I was playing around with overflowing stacks and I managed to generate a > test > case that hung the kernel with vmapped stacks. The test case is just > > static void noinline foo1(void) > { >pr_info("%p\n", (void *)current_stack_poi