Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

It was known that there are going to be bugs to work through, many of them relatively benign like the leaks of data near string constants (probably other string constants) in rodata. It makes sense to have it default to WARN with BUG / noreturn as a non-default configuration option for it, I guess

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

It was known that there are going to be bugs to work through, many of them relatively benign like the leaks of data near string constants (probably other string constants) in rodata. It makes sense to have it default to WARN with BUG / noreturn as a non-default configuration option for it, I guess

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Tue, Jul 25, 2017 at 5:11 PM, Linus Torvalds wrote: > On Tue, Jul 25, 2017 at 4:35 PM, Kees Cook wrote: >> >> In this case, there isn't a sensible way to continue. > > Kees, stop this idiocy already. > > These have been FALSE POSITIVES.

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Tue, Jul 25, 2017 at 5:11 PM, Linus Torvalds wrote: > On Tue, Jul 25, 2017 at 4:35 PM, Kees Cook wrote: >> >> In this case, there isn't a sensible way to continue. > > Kees, stop this idiocy already. > > These have been FALSE POSITIVES. They haven't actually been bugs in > the code, they have

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Tue, Jul 25, 2017 at 4:35 PM, Kees Cook wrote: > > In this case, there isn't a sensible way to continue. Kees, stop this idiocy already. These have been FALSE POSITIVES. They haven't actually been bugs in the code, they have been bugs in the *checking* code. In two

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Tue, Jul 25, 2017 at 4:35 PM, Kees Cook wrote: > > In this case, there isn't a sensible way to continue. Kees, stop this idiocy already. These have been FALSE POSITIVES. They haven't actually been bugs in the code, they have been bugs in the *checking* code. In two years, when this code is

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

(Finally getting back around to this thread, sorry for the delay...) On Wed, Jul 19, 2017 at 9:04 PM, Linus Torvalds wrote: > As it is, the full dmesg does show that > > detected buffer overflow in memcpy > > but since it was printed out separately, if comes

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

(Finally getting back around to this thread, sorry for the delay...) On Wed, Jul 19, 2017 at 9:04 PM, Linus Torvalds wrote: > As it is, the full dmesg does show that > > detected buffer overflow in memcpy > > but since it was printed out separately, if comes before the "-- cut > here --"

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Fri 2017-07-21 12:15:09, Andy Shevchenko wrote: > On Fri, 2017-07-21 at 09:59 +0800, Ye Xiaolong wrote: > > Hi, > > > > On 07/19, Linus Torvalds wrote: > > > Hmm. I wonder why the kernel test robot ends up having that annoying > > > line doubling for the dmesg. > > > > > > > Hmm, this line

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Fri 2017-07-21 12:15:09, Andy Shevchenko wrote: > On Fri, 2017-07-21 at 09:59 +0800, Ye Xiaolong wrote: > > Hi, > > > > On 07/19, Linus Torvalds wrote: > > > Hmm. I wonder why the kernel test robot ends up having that annoying > > > line doubling for the dmesg. > > > > > > > Hmm, this line

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Fri, 2017-07-21 at 09:59 +0800, Ye Xiaolong wrote: > Hi, > > On 07/19, Linus Torvalds wrote: > > Hmm. I wonder why the kernel test robot ends up having that annoying > > line doubling for the dmesg. > > > > Hmm, this line doubling issue should be caused by we set both >

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Fri, 2017-07-21 at 09:59 +0800, Ye Xiaolong wrote: > Hi, > > On 07/19, Linus Torvalds wrote: > > Hmm. I wonder why the kernel test robot ends up having that annoying > > line doubling for the dmesg. > > > > Hmm, this line doubling issue should be caused by we set both >

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Thu, Jul 20, 2017 at 6:59 PM, Ye Xiaolong wrote: > On 07/19, Linus Torvalds wrote: >>Hmm. I wonder why the kernel test robot ends up having that annoying >>line doubling for the dmesg. >> > > Hmm, this line doubling issue should be caused by we set both >

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Thu, Jul 20, 2017 at 6:59 PM, Ye Xiaolong wrote: > On 07/19, Linus Torvalds wrote: >>Hmm. I wonder why the kernel test robot ends up having that annoying >>line doubling for the dmesg. >> > > Hmm, this line doubling issue should be caused by we set both > 'earlyprintk=ttyS0,115200' and

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Thu, 20 Jul 2017 11:41:38 -0700 Linus Torvalds wrote: > On Thu, Jul 20, 2017 at 8:51 AM, Masami Hiramatsu wrote: > > > > Acked-by: Masami Hiramatsu > > Tested-by: Masami Hiramatsu > > Ok, I

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Thu, 20 Jul 2017 11:41:38 -0700 Linus Torvalds wrote: > On Thu, Jul 20, 2017 at 8:51 AM, Masami Hiramatsu wrote: > > > > Acked-by: Masami Hiramatsu > > Tested-by: Masami Hiramatsu > > Ok, I committed that patch as-is. > > Other architectures may end up with the same issue, unless they

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

Hi, On 07/19, Linus Torvalds wrote: >Hmm. I wonder why the kernel test robot ends up having that annoying >line doubling for the dmesg. > Hmm, this line doubling issue should be caused by we set both 'earlyprintk=ttyS0,115200' and 'console=ttyS0,115200' in cmdline, after I remove any of it, this

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

Hi, On 07/19, Linus Torvalds wrote: >Hmm. I wonder why the kernel test robot ends up having that annoying >line doubling for the dmesg. > Hmm, this line doubling issue should be caused by we set both 'earlyprintk=ttyS0,115200' and 'console=ttyS0,115200' in cmdline, after I remove any of it, this

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Thu, 20 Jul 2017 11:41:38 -0700 Linus Torvalds wrote: > On Thu, Jul 20, 2017 at 8:51 AM, Masami Hiramatsu wrote: > > > > Acked-by: Masami Hiramatsu > > Tested-by: Masami Hiramatsu > > Ok, I

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Thu, 20 Jul 2017 11:41:38 -0700 Linus Torvalds wrote: > On Thu, Jul 20, 2017 at 8:51 AM, Masami Hiramatsu wrote: > > > > Acked-by: Masami Hiramatsu > > Tested-by: Masami Hiramatsu > > Ok, I committed that patch as-is. > > Other architectures may end up with the same issue, unless they

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Thu, Jul 20, 2017 at 8:51 AM, Masami Hiramatsu wrote: > > Acked-by: Masami Hiramatsu > Tested-by: Masami Hiramatsu Ok, I committed that patch as-is. Other architectures may end up with the same issue, unless they really happen

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Thu, Jul 20, 2017 at 8:51 AM, Masami Hiramatsu wrote: > > Acked-by: Masami Hiramatsu > Tested-by: Masami Hiramatsu Ok, I committed that patch as-is. Other architectures may end up with the same issue, unless they really happen to have just a single instruction that fits in their

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Wed, 19 Jul 2017 21:04:25 -0700 Linus Torvalds wrote: > Hmm. I wonder why the kernel test robot ends up having that annoying > line doubling for the dmesg. > > On Wed, Jul 19, 2017 at 6:42 PM, kernel test robot > wrote: > > > > FYI, we

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

On Wed, 19 Jul 2017 21:04:25 -0700 Linus Torvalds wrote: > Hmm. I wonder why the kernel test robot ends up having that annoying > line doubling for the dmesg. > > On Wed, Jul 19, 2017 at 6:42 PM, kernel test robot > wrote: > > > > FYI, we noticed the following commit: > > > > commit:

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

Hi Linus, On Wed, 19 Jul 2017 21:04:25 -0700 Linus Torvalds wrote: > Hmm. I wonder why the kernel test robot ends up having that annoying > line doubling for the dmesg. > > On Wed, Jul 19, 2017 at 6:42 PM, kernel test robot > wrote: > > >

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

Hi Linus, On Wed, 19 Jul 2017 21:04:25 -0700 Linus Torvalds wrote: > Hmm. I wonder why the kernel test robot ends up having that annoying > line doubling for the dmesg. > > On Wed, Jul 19, 2017 at 6:42 PM, kernel test robot > wrote: > > > > FYI, we noticed the following commit: > > > >

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> So the fortify_string code has decided that only a single-byte (or > empty) memcpy is ok. > > And that, in turn, seems to be because we're copying from > optprobe_template_entry, which is declared as > > extern __visible kprobe_opcode_t optprobe_template_entry; > > so the fortify code

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> So the fortify_string code has decided that only a single-byte (or > empty) memcpy is ok. > > And that, in turn, seems to be because we're copying from > optprobe_template_entry, which is declared as > > extern __visible kprobe_opcode_t optprobe_template_entry; > > so the fortify code

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

Hmm. I wonder why the kernel test robot ends up having that annoying line doubling for the dmesg. On Wed, Jul 19, 2017 at 6:42 PM, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 6974f0c4555e285ab217cee58b6e874f776ff409

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

Hmm. I wonder why the kernel test robot ends up having that annoying line doubling for the dmesg. On Wed, Jul 19, 2017 at 6:42 PM, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 6974f0c4555e285ab217cee58b6e874f776ff409 ("include/linux/string.h: > add the option

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 > [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 Probably this: /* Copy arch-dep-instance from template */ memcpy(buf, _template_entry, TMPL_END_IDX); Not a real bug, just technically undefined because these

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 > [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 Probably this: /* Copy arch-dep-instance from template */ memcpy(buf, _template_entry, TMPL_END_IDX); Not a real bug, just technically undefined because these

[lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

FYI, we noticed the following commit: commit: 6974f0c4555e285ab217cee58b6e874f776ff409 ("include/linux/string.h: add the option of fortified string.h functions") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master in testcase: boot on test machine: qemu-system-i386

[lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

FYI, we noticed the following commit: commit: 6974f0c4555e285ab217cee58b6e874f776ff409 ("include/linux/string.h: add the option of fortified string.h functions") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master in testcase: boot on test machine: qemu-system-i386