From: Eric W. Biederman <ebiederm@xmission.com>
To: lkp@lists.01.org
Subject: Re: 601d5abfea [ 13.686356] BUG: unable to handle kernel paging request at 34ca027e
Date: Fri, 12 Oct 2018 19:08:22 -0500 [thread overview]
Message-ID: <871s8ur9mx.fsf@xmission.com> (raw)
In-Reply-To: <20181012085450.GK13396@shao2-debian>
[-- Attachment #1: Type: text/plain, Size: 12390 bytes --]
kernel test robot <rong.a.chen@intel.com> writes:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git siginfo-next
>
This is an odd one. This is the first time I recall the lkp test robot
emailing me and telling me that I have fixed an issue. I don't mind I
am just a little surprised.
Recently it was discovered that on my branch passing a large negative signal
number to rt_sigqueueinfo could cause an oops. The underlying issues
were fixed by:
b2a2ab527d6d ("signal: Guard against negative signal numbers in copy_siginfo_from_user")
a36700589b85 ("signal: Guard against negative signal numbers in copy_siginfo_from_user32")
It appears that this issue was found in linux-next before these fixes
were applied. And then the top of my siginfo-next branch where these
fixes exist was tested.
I have not problem with that sequence of events it is just a little
surprising.
If I have not read this test report correctly please let me know.
Eric
> commit 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0
> Author: Eric W. Biederman <ebiederm@xmission.com>
> AuthorDate: Fri Oct 5 09:02:48 2018 +0200
> Commit: Eric W. Biederman <ebiederm@xmission.com>
> CommitDate: Mon Oct 8 09:35:26 2018 +0200
>
> signal: In sigqueueinfo prefer sig not si_signo
>
> Andrei Vagin <avagin@gmail.com> reported:
>
> > Accoding to the man page, the user should not set si_signo, it has to be set
> > by kernel.
> >
> > $ man 2 rt_sigqueueinfo
> >
> > The uinfo argument specifies the data to accompany the signal. This
> > argument is a pointer to a structure of type siginfo_t, described in
> > sigaction(2) (and defined by including <sigaction.h>). The caller
> > should set the following fields in this structure:
> >
> > si_code
> > This must be one of the SI_* codes in the Linux kernel source
> > file include/asm-generic/siginfo.h, with the restriction that
> > the code must be negative (i.e., cannot be SI_USER, which is
> > used by the kernel to indicate a signal sent by kill(2)) and
> > cannot (since Linux 2.6.39) be SI_TKILL (which is used by the
> > kernel to indicate a signal sent using tgkill(2)).
> >
> > si_pid This should be set to a process ID, typically the process ID of
> > the sender.
> >
> > si_uid This should be set to a user ID, typically the real user ID of
> > the sender.
> >
> > si_value
> > This field contains the user data to accompany the signal. For
> > more information, see the description of the last (union sigval)
> > argument of sigqueue(3).
> >
> > Internally, the kernel sets the si_signo field to the value specified
> > in sig, so that the receiver of the signal can also obtain the signal
> > number via that field.
> >
> > On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
> >>
> >> If there is some application that calls sigqueueinfo directly that has
> >> a problem with this added sanity check we can revisit this when we see
> >> what kind of crazy that application is doing.
> >
> >
> > I already know two "applications" ;)
> >
> > https://github.com/torvalds/linux/blob/master/tools/testing/selftests/ptrace/peeksiginfo.c
> > https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/sigpending.c
> >
> > Disclaimer: I'm the author of both of them.
>
> Looking at the kernel code the historical behavior has alwasy been to prefer
> the signal number passed in by the kernel.
>
> So sigh. Implmenet __copy_siginfo_from_user and __copy_siginfo_from_user32 to
> take that signal number and prefer it. The user of ptrace will still
> use copy_siginfo_from_user and copy_siginfo_from_user32 as they do not and
> never have had a signal number there.
>
> Luckily this change has never made it farther than linux-next.
>
> Fixes: e75dc036c445 ("signal: Fail sigqueueinfo if si_signo != sig")
> Reported-by: Andrei Vagin <avagin@gmail.com>
> Tested-by: Andrei Vagin <avagin@gmail.com>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> 4ce5f9c9e7 signal: Use a smaller struct siginfo in the kernel
> 601d5abfea signal: In sigqueueinfo prefer sig not si_signo
> a36700589b signal: Guard against negative signal numbers in copy_siginfo_from_user32
> 771b65e89c Add linux-next specific files for 20181011
> +------------------------------------------+------------+------------+------------+---------------+
> | | 4ce5f9c9e7 | 601d5abfea | a36700589b | next-20181011 |
> +------------------------------------------+------------+------------+------------+---------------+
> | boot_successes | 56 | 16 | 27 | 8 |
> | boot_failures | 5 | 3 | 1 | 6 |
> | EIP:__copy_user_ll | 1 | | | |
> | Mem-Info | 1 | 1 | 1 | 1 |
> | BUG:unable_to_handle_kernel | 3 | 2 | 0 | 2 |
> | Oops:#[##] | 4 | 2 | 0 | 5 |
> | EIP:copy_siginfo_from_user | 4 | | | |
> | Kernel_panic-not_syncing:Fatal_exception | 4 | 2 | 0 | 5 |
> | EIP:known_siginfo_layout | 0 | 2 | 0 | 5 |
> +------------------------------------------+------------+------------+------------+---------------+
>
> [child3:558] migrate_pages (294) returned ENOSYS, marking as inactive.
> [child3:558] mq_open (277) returned ENOSYS, marking as inactive.
> [child3:558] pkey_free (382) returned ENOSYS, marking as inactive.
> [child2:557] uselib (86) returned ENOSYS, marking as inactive.
> [child0:555] mq_timedreceive (280) returned ENOSYS, marking as inactive.
> [ 13.686356] BUG: unable to handle kernel paging request at 34ca027e
> [ 13.688081] *pdpt = 000000000c7ab001 *pde = 0000000000000000
> [ 13.697660] Oops: 0000 [#1]
> [ 13.698554] CPU: 0 PID: 555 Comm: trinity-c0 Tainted: G T 4.19.0-rc1-00078-g601d5abf #1
> [ 13.700926] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> [ 13.707252] EIP: known_siginfo_layout+0x35/0x70
> [ 13.708468] Code: 80 00 00 00 74 37 85 d2 7e 3b 83 f8 1f 7e 0e 83 fa 06 0f 9e c0 5b 5d c3 90 8d 74 26 00 8d 48 ff bb d8 04 01 50 0f a3 cb 73 e5 <0f> b6 84 00 c0 ab c0 c1 5b 5d 39 c2 0f 9e c0 c3 8d 76 00 b8 01 00
> [ 13.713020] EAX: b984ab5f EBX: 500104d8 ECX: b984ab5e EDX: 000010e0
> [ 13.714608] ESI: b984ab5f EDI: b70b2000 EBP: cc7b3f38 ESP: cc7b3f34
> [ 13.716177] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010283
> [ 13.717871] CR0: 80050033 CR2: 34ca027e CR3: 0c665560 CR4: 000406f0
> [ 13.719461] DR0: b72b2000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 13.721066] DR6: ffff0ff0 DR7: 00000600
> [ 13.722200] Call Trace:
> [ 13.723069] __copy_siginfo_from_user+0x2f/0x60
> [ 13.724361] sys_rt_tgsigqueueinfo+0x36/0x90
> [ 13.729191] do_int80_syscall_32+0x4f/0xe0
> [ 13.730392] entry_INT80_32+0xda/0xda
> [ 13.731494] EIP: 0x809af42
> [ 13.732413] Code: 89 c8 c3 90 8d 74 26 00 85 c0 c7 01 01 00 00 00 75 d8 a1 ec bd a7 08 eb d1 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 cd 80 <c3> 8d b6 00 00 00 00 8d bc 27 00 00 00 00 8b 10 a3 14 be a7 08 85
> [ 13.737100] EAX: ffffffda EBX: 7552a122 ECX: 00000000 EDX: b984ab5f
> [ 13.738788] ESI: b70b2000 EDI: 000000ae EBP: fffffffe ESP: bfd60988
> [ 13.740579] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000292
> [ 13.742438] CR2: 0000000034ca027e
> [ 13.743642] ---[ end trace e1fbccf706ef9461 ]---
> [ 13.745144] EIP: known_siginfo_layout+0x35/0x70
>
> # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
> git bisect start 771b65e89c8a51d611b8049718693a4202e4f732 0238df646e6224016a45505d2c111a24669ebe21 --
> git bisect good bee1c1784c6492d93950701744f1066c567ec398 # 20:39 G 18 0 8 8 Merge remote-tracking branch 'i2c/i2c/for-next'
> git bisect good b85fc5b27d65d27b5d67cdeadbf1ddbc740fb3e7 # 20:53 G 18 0 10 10 Merge remote-tracking branch 'iommu/next'
> git bisect good 375ee3d4cd804cb24791a10c9a223b13a068e460 # 21:02 G 18 0 7 7 Merge remote-tracking branch 'tty/tty-next'
> git bisect bad 23662bdad2b2f3ff6e1abc891ed70bad0a455d98 # 21:13 B 1 1 0 0 Merge remote-tracking branch 'userns/for-next'
> git bisect good 3b63b156e75d1d9010f77d512a7a3bb2f6add86a # 21:26 G 18 0 10 10 Merge remote-tracking branch 'slave-dma/next'
> git bisect good a22163785338b3dab233107c340558f2a132c15c # 21:35 G 18 0 6 6 Merge remote-tracking branch 'rpmsg/for-next'
> git bisect good 6d8099c167641e51d4b561b13c0ae350ffcda0ef # 21:45 G 18 0 11 11 Merge remote-tracking branch 'gpio/for-next'
> git bisect good 973d55984be3c3c65384b7df464d6215aae52ea9 # 21:58 G 17 0 5 5 Merge remote-tracking branch 'pinctrl/for-next'
> git bisect good cd60ab7abb3df301c4ff2cf7d619cf7e30cca289 # 22:08 G 18 0 8 8 signal/powerpc: Remove pkey parameter from __bad_area_nosemaphore
> git bisect good c852680959d0964198e829da80f012b3df43060c # 22:17 G 18 0 7 7 signal/arm64: Use send_sig_fault where appropriate
> git bisect good 5ee527d7cefddebd72970d290e5cc06c9ae32890 # 22:27 G 18 0 8 8 signal/unicore32: Use send_sig_fault where appropriate
> git bisect good f28380185193610c716a90ec9b9e696638a495ce # 22:41 G 18 0 11 11 signal: Remove the need for __ARCH_SI_PREABLE_SIZE and SI_PAD_SIZE
> git bisect good ae7795bc6187a15ec51cf258abae656a625f9980 # 22:55 G 18 0 6 6 signal: Distinguish between kernel_siginfo and siginfo
> git bisect bad 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0 # 23:05 B 2 1 2 2 signal: In sigqueueinfo prefer sig not si_signo
> git bisect good 4ce5f9c9e7546915c559ffae594e6d73f918db00 # 00:07 G 27 0 11 11 signal: Use a smaller struct siginfo in the kernel
> # first bad commit: [601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0] signal: In sigqueueinfo prefer sig not si_signo
> git bisect good 4ce5f9c9e7546915c559ffae594e6d73f918db00 # 00:16 G 83 0 30 41 signal: Use a smaller struct siginfo in the kernel
> # extra tests with debug options
> git bisect bad 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0 # 00:36 B 6 2 5 5 signal: In sigqueueinfo prefer sig not si_signo
> # extra tests on HEAD of linux-next/master
> git bisect bad 771b65e89c8a51d611b8049718693a4202e4f732 # 00:36 B 3 5 0 4 Add linux-next specific files for 20181011
> # extra tests on tree/branch userns/siginfo-next
> git bisect good a36700589b85443e28170be59fa11c8a104130a5 # 00:50 G 29 0 10 10 signal: Guard against negative signal numbers in copy_siginfo_from_user32
> # extra tests with first bad commit reverted
> git bisect good c9c9ead64294d0df96006708ba47007624c7b069 # 01:10 G 29 0 9 9 Revert "signal: In sigqueueinfo prefer sig not si_signo"
> # extra tests on tree/branch linux-next/master
> git bisect bad 771b65e89c8a51d611b8049718693a4202e4f732 # 01:10 B 3 5 0 4 Add linux-next specific files for 20181011
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/lkp Intel Corporation
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: kernel test robot <rong.a.chen@intel.com>
Cc: linux-kernel@vger.kernel.org, LKP <lkp@01.org>
Subject: Re: [LKP] 601d5abfea [ 13.686356] BUG: unable to handle kernel paging request at 34ca027e
Date: Fri, 12 Oct 2018 19:08:22 -0500 [thread overview]
Message-ID: <871s8ur9mx.fsf@xmission.com> (raw)
In-Reply-To: <20181012085450.GK13396@shao2-debian> (kernel test robot's message of "Fri, 12 Oct 2018 16:54:50 +0800")
kernel test robot <rong.a.chen@intel.com> writes:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git siginfo-next
>
This is an odd one. This is the first time I recall the lkp test robot
emailing me and telling me that I have fixed an issue. I don't mind I
am just a little surprised.
Recently it was discovered that on my branch passing a large negative signal
number to rt_sigqueueinfo could cause an oops. The underlying issues
were fixed by:
b2a2ab527d6d ("signal: Guard against negative signal numbers in copy_siginfo_from_user")
a36700589b85 ("signal: Guard against negative signal numbers in copy_siginfo_from_user32")
It appears that this issue was found in linux-next before these fixes
were applied. And then the top of my siginfo-next branch where these
fixes exist was tested.
I have not problem with that sequence of events it is just a little
surprising.
If I have not read this test report correctly please let me know.
Eric
> commit 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0
> Author: Eric W. Biederman <ebiederm@xmission.com>
> AuthorDate: Fri Oct 5 09:02:48 2018 +0200
> Commit: Eric W. Biederman <ebiederm@xmission.com>
> CommitDate: Mon Oct 8 09:35:26 2018 +0200
>
> signal: In sigqueueinfo prefer sig not si_signo
>
> Andrei Vagin <avagin@gmail.com> reported:
>
> > Accoding to the man page, the user should not set si_signo, it has to be set
> > by kernel.
> >
> > $ man 2 rt_sigqueueinfo
> >
> > The uinfo argument specifies the data to accompany the signal. This
> > argument is a pointer to a structure of type siginfo_t, described in
> > sigaction(2) (and defined by including <sigaction.h>). The caller
> > should set the following fields in this structure:
> >
> > si_code
> > This must be one of the SI_* codes in the Linux kernel source
> > file include/asm-generic/siginfo.h, with the restriction that
> > the code must be negative (i.e., cannot be SI_USER, which is
> > used by the kernel to indicate a signal sent by kill(2)) and
> > cannot (since Linux 2.6.39) be SI_TKILL (which is used by the
> > kernel to indicate a signal sent using tgkill(2)).
> >
> > si_pid This should be set to a process ID, typically the process ID of
> > the sender.
> >
> > si_uid This should be set to a user ID, typically the real user ID of
> > the sender.
> >
> > si_value
> > This field contains the user data to accompany the signal. For
> > more information, see the description of the last (union sigval)
> > argument of sigqueue(3).
> >
> > Internally, the kernel sets the si_signo field to the value specified
> > in sig, so that the receiver of the signal can also obtain the signal
> > number via that field.
> >
> > On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
> >>
> >> If there is some application that calls sigqueueinfo directly that has
> >> a problem with this added sanity check we can revisit this when we see
> >> what kind of crazy that application is doing.
> >
> >
> > I already know two "applications" ;)
> >
> > https://github.com/torvalds/linux/blob/master/tools/testing/selftests/ptrace/peeksiginfo.c
> > https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/sigpending.c
> >
> > Disclaimer: I'm the author of both of them.
>
> Looking at the kernel code the historical behavior has alwasy been to prefer
> the signal number passed in by the kernel.
>
> So sigh. Implmenet __copy_siginfo_from_user and __copy_siginfo_from_user32 to
> take that signal number and prefer it. The user of ptrace will still
> use copy_siginfo_from_user and copy_siginfo_from_user32 as they do not and
> never have had a signal number there.
>
> Luckily this change has never made it farther than linux-next.
>
> Fixes: e75dc036c445 ("signal: Fail sigqueueinfo if si_signo != sig")
> Reported-by: Andrei Vagin <avagin@gmail.com>
> Tested-by: Andrei Vagin <avagin@gmail.com>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> 4ce5f9c9e7 signal: Use a smaller struct siginfo in the kernel
> 601d5abfea signal: In sigqueueinfo prefer sig not si_signo
> a36700589b signal: Guard against negative signal numbers in copy_siginfo_from_user32
> 771b65e89c Add linux-next specific files for 20181011
> +------------------------------------------+------------+------------+------------+---------------+
> | | 4ce5f9c9e7 | 601d5abfea | a36700589b | next-20181011 |
> +------------------------------------------+------------+------------+------------+---------------+
> | boot_successes | 56 | 16 | 27 | 8 |
> | boot_failures | 5 | 3 | 1 | 6 |
> | EIP:__copy_user_ll | 1 | | | |
> | Mem-Info | 1 | 1 | 1 | 1 |
> | BUG:unable_to_handle_kernel | 3 | 2 | 0 | 2 |
> | Oops:#[##] | 4 | 2 | 0 | 5 |
> | EIP:copy_siginfo_from_user | 4 | | | |
> | Kernel_panic-not_syncing:Fatal_exception | 4 | 2 | 0 | 5 |
> | EIP:known_siginfo_layout | 0 | 2 | 0 | 5 |
> +------------------------------------------+------------+------------+------------+---------------+
>
> [child3:558] migrate_pages (294) returned ENOSYS, marking as inactive.
> [child3:558] mq_open (277) returned ENOSYS, marking as inactive.
> [child3:558] pkey_free (382) returned ENOSYS, marking as inactive.
> [child2:557] uselib (86) returned ENOSYS, marking as inactive.
> [child0:555] mq_timedreceive (280) returned ENOSYS, marking as inactive.
> [ 13.686356] BUG: unable to handle kernel paging request at 34ca027e
> [ 13.688081] *pdpt = 000000000c7ab001 *pde = 0000000000000000
> [ 13.697660] Oops: 0000 [#1]
> [ 13.698554] CPU: 0 PID: 555 Comm: trinity-c0 Tainted: G T 4.19.0-rc1-00078-g601d5abf #1
> [ 13.700926] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> [ 13.707252] EIP: known_siginfo_layout+0x35/0x70
> [ 13.708468] Code: 80 00 00 00 74 37 85 d2 7e 3b 83 f8 1f 7e 0e 83 fa 06 0f 9e c0 5b 5d c3 90 8d 74 26 00 8d 48 ff bb d8 04 01 50 0f a3 cb 73 e5 <0f> b6 84 00 c0 ab c0 c1 5b 5d 39 c2 0f 9e c0 c3 8d 76 00 b8 01 00
> [ 13.713020] EAX: b984ab5f EBX: 500104d8 ECX: b984ab5e EDX: 000010e0
> [ 13.714608] ESI: b984ab5f EDI: b70b2000 EBP: cc7b3f38 ESP: cc7b3f34
> [ 13.716177] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010283
> [ 13.717871] CR0: 80050033 CR2: 34ca027e CR3: 0c665560 CR4: 000406f0
> [ 13.719461] DR0: b72b2000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 13.721066] DR6: ffff0ff0 DR7: 00000600
> [ 13.722200] Call Trace:
> [ 13.723069] __copy_siginfo_from_user+0x2f/0x60
> [ 13.724361] sys_rt_tgsigqueueinfo+0x36/0x90
> [ 13.729191] do_int80_syscall_32+0x4f/0xe0
> [ 13.730392] entry_INT80_32+0xda/0xda
> [ 13.731494] EIP: 0x809af42
> [ 13.732413] Code: 89 c8 c3 90 8d 74 26 00 85 c0 c7 01 01 00 00 00 75 d8 a1 ec bd a7 08 eb d1 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 cd 80 <c3> 8d b6 00 00 00 00 8d bc 27 00 00 00 00 8b 10 a3 14 be a7 08 85
> [ 13.737100] EAX: ffffffda EBX: 7552a122 ECX: 00000000 EDX: b984ab5f
> [ 13.738788] ESI: b70b2000 EDI: 000000ae EBP: fffffffe ESP: bfd60988
> [ 13.740579] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000292
> [ 13.742438] CR2: 0000000034ca027e
> [ 13.743642] ---[ end trace e1fbccf706ef9461 ]---
> [ 13.745144] EIP: known_siginfo_layout+0x35/0x70
>
> # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
> git bisect start 771b65e89c8a51d611b8049718693a4202e4f732 0238df646e6224016a45505d2c111a24669ebe21 --
> git bisect good bee1c1784c6492d93950701744f1066c567ec398 # 20:39 G 18 0 8 8 Merge remote-tracking branch 'i2c/i2c/for-next'
> git bisect good b85fc5b27d65d27b5d67cdeadbf1ddbc740fb3e7 # 20:53 G 18 0 10 10 Merge remote-tracking branch 'iommu/next'
> git bisect good 375ee3d4cd804cb24791a10c9a223b13a068e460 # 21:02 G 18 0 7 7 Merge remote-tracking branch 'tty/tty-next'
> git bisect bad 23662bdad2b2f3ff6e1abc891ed70bad0a455d98 # 21:13 B 1 1 0 0 Merge remote-tracking branch 'userns/for-next'
> git bisect good 3b63b156e75d1d9010f77d512a7a3bb2f6add86a # 21:26 G 18 0 10 10 Merge remote-tracking branch 'slave-dma/next'
> git bisect good a22163785338b3dab233107c340558f2a132c15c # 21:35 G 18 0 6 6 Merge remote-tracking branch 'rpmsg/for-next'
> git bisect good 6d8099c167641e51d4b561b13c0ae350ffcda0ef # 21:45 G 18 0 11 11 Merge remote-tracking branch 'gpio/for-next'
> git bisect good 973d55984be3c3c65384b7df464d6215aae52ea9 # 21:58 G 17 0 5 5 Merge remote-tracking branch 'pinctrl/for-next'
> git bisect good cd60ab7abb3df301c4ff2cf7d619cf7e30cca289 # 22:08 G 18 0 8 8 signal/powerpc: Remove pkey parameter from __bad_area_nosemaphore
> git bisect good c852680959d0964198e829da80f012b3df43060c # 22:17 G 18 0 7 7 signal/arm64: Use send_sig_fault where appropriate
> git bisect good 5ee527d7cefddebd72970d290e5cc06c9ae32890 # 22:27 G 18 0 8 8 signal/unicore32: Use send_sig_fault where appropriate
> git bisect good f28380185193610c716a90ec9b9e696638a495ce # 22:41 G 18 0 11 11 signal: Remove the need for __ARCH_SI_PREABLE_SIZE and SI_PAD_SIZE
> git bisect good ae7795bc6187a15ec51cf258abae656a625f9980 # 22:55 G 18 0 6 6 signal: Distinguish between kernel_siginfo and siginfo
> git bisect bad 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0 # 23:05 B 2 1 2 2 signal: In sigqueueinfo prefer sig not si_signo
> git bisect good 4ce5f9c9e7546915c559ffae594e6d73f918db00 # 00:07 G 27 0 11 11 signal: Use a smaller struct siginfo in the kernel
> # first bad commit: [601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0] signal: In sigqueueinfo prefer sig not si_signo
> git bisect good 4ce5f9c9e7546915c559ffae594e6d73f918db00 # 00:16 G 83 0 30 41 signal: Use a smaller struct siginfo in the kernel
> # extra tests with debug options
> git bisect bad 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0 # 00:36 B 6 2 5 5 signal: In sigqueueinfo prefer sig not si_signo
> # extra tests on HEAD of linux-next/master
> git bisect bad 771b65e89c8a51d611b8049718693a4202e4f732 # 00:36 B 3 5 0 4 Add linux-next specific files for 20181011
> # extra tests on tree/branch userns/siginfo-next
> git bisect good a36700589b85443e28170be59fa11c8a104130a5 # 00:50 G 29 0 10 10 signal: Guard against negative signal numbers in copy_siginfo_from_user32
> # extra tests with first bad commit reverted
> git bisect good c9c9ead64294d0df96006708ba47007624c7b069 # 01:10 G 29 0 9 9 Revert "signal: In sigqueueinfo prefer sig not si_signo"
> # extra tests on tree/branch linux-next/master
> git bisect bad 771b65e89c8a51d611b8049718693a4202e4f732 # 01:10 B 3 5 0 4 Add linux-next specific files for 20181011
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/lkp Intel Corporation
next prev parent reply other threads:[~2018-10-13 0:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-12 8:54 601d5abfea [ 13.686356] BUG: unable to handle kernel paging request at 34ca027e kernel test robot
2018-10-12 8:54 ` [LKP] " kernel test robot
2018-10-13 0:08 ` Eric W. Biederman [this message]
2018-10-13 0:08 ` Eric W. Biederman
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=871s8ur9mx.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=lkp@lists.01.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.