Re: [LKP] [userns] BUG: unable to handle kernel NULL pointer dereference at (null)
On Tue, Dec 16, 2014 at 09:47:39AM +0800, Huang, Ying wrote:
> On Mon, 2014-12-15 at 11:31 -0600, Eric W. Biederman wrote:
> > Huang Ying writes:
> >
> > > FYI, we noticed the below changes on
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> > > for-testing
> > > commit bbea5f5532501fdd67f46442ba7b1122d7ff3123
> > > ("userns: Add a knob to disable setgroups on a per user namespace basis")
> >
> > Thank you.
> >
> > I am quite puzzled by this failure. There was an similar failure when
> > /proc/[pid]/setgroups was read (if I recall correctly). I don't see how
> > that change could result at failures during open or failures during
> > boot. I added a new file to proc which any reasonable system should
> > leave alone. Are you by chance running trinity during boot?
>
> Yes. We are running trinity during boot.
>
> > If the reproducer gave me any clue about which file that was opened or
> > which code path this happened on I would be bery interested. If for no
> > other reason that to confirm that I have fixed the issue.
>
> This is just boot test, with trinity running after kernel boot.
>
> Fengguang, do you have more information?
The trinity runs like this
cd /tmp
/usr/local/bin/trinity -q -X -x get_robust_list -N 99
Here are all the call traces. You can see some tracesys_phase2() in
some of the traces. It's a very reproducible error.
dmesg-vm-vp-quantal-x86_64-14:20141214024709:x86_64-rhel:3.18.0-rc6-00015-gbbea5f5:1
[5.970508] init: Failed to create pty - disabling logging for job
[5.973062] init: Failed to create pty - disabling logging for job
[5.989614] init: Failed to create pty - disabling logging for job
[ 16.365667] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 16.366010] IP: [< (null)>] (null)
[ 16.366010] PGD 15ce4067 PUD 15d40067 PMD 0
[ 16.366010] Oops: 0010 [#1] SMP
[ 16.366010] Modules linked in:
[ 16.366010] CPU: 0 PID: 308 Comm: trinity-main Not tainted
3.18.0-rc6-00015-gbbea5f5 #1
[ 16.366010] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 16.366010] task: 880015d0bac0 ti: 8806c000 task.ti:
8806c000
[ 16.366010] RIP: 0010:[<>] [< (null)>]
(null)
[ 16.366010] RSP: 0018:8806fd80 EFLAGS: 00010246
[ 16.366010] RAX: 818e4bc0 RBX: 8806fe38 RCX: 8800149bb540
[ 16.366010] RDX: RSI: 8806fe38 RDI: 8800149bb540
[ 16.366010] RBP: 8806fe28 R08: R09:
[ 16.366010] R10: R11: 8800149bb540 R12: 880015939400
[ 16.366010] R13: 8806fde8 R14: R15: 0041
[ 16.366010] FS: 7f38e5814700() GS:88001360()
knlGS:
[ 16.366010] CS: 0010 DS: ES: CR0: 80050033
[ 16.366010] CR2: CR3: 163c5000 CR4: 06f0
[ 16.366010] DR0: 021223d8 DR1: DR2:
[ 16.366010] DR3: DR6: 0ff0 DR7: 00090602
[ 16.366010] Stack:
[ 16.366010] 811f05c8 8800121df000 880015d0bac0
880015d0bac0
[ 16.366010] 8800149bb540 8806ff24 8800121df000
880015d0bac0
[ 16.366010] 880015d0bac0 df9a5ea7
880006b9f160
[ 16.366010] Call Trace:
[ 16.366010] [] ? path_openat+0x538/0x680
[ 16.366010] [] do_filp_open+0x3a/0xb0
[ 16.366010] [] ? __alloc_fd+0xa7/0x130
[ 16.366010] [] do_sys_open+0x12c/0x220
[ 16.366010] [] SyS_open+0x1e/0x20
[ 16.366010] [] system_call_fastpath+0x12/0x17
[ 16.366010] Code: Bad RIP value.
[ 16.366010] RIP [< (null)>] (null)
[ 16.366010] RSP
[ 16.366010] CR2:
[ 16.448360] ---[ end trace 28f4ad5b31699327 ]---
[ 16.449384] Kernel panic - not syncing: Fatal exception
dmesg-vm-vp-quantal-x86_64-16:20141214033109:x86_64-rhel:3.18.0-rc6-00015-gbbea5f5:1
[5.751305] init: Failed to create pty - disabling logging for job
[5.754282] init: Failed to create pty - disabling logging for job
[5.770351] init: Failed to create pty - disabling logging for job
[ 16.202720] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 16.203063] IP: [< (null)>] (null)
[ 16.203063] PGD 158b6067 PUD 158ab067 PMD 0
[ 16.203063] Oops: 0010 [#1] SMP
[ 16.203063] Modules linked in:
[ 16.203063] CPU: 1 PID: 308 Comm: trinity-main Not tainted
3.18.0-rc6-00015-gbbea5f5 #1
[ 16.203063] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 16.203063] task: 88001624 ti: 880015fa4000 task.ti:
880015fa4000
[ 16.203063] RIP: 0010:[<>] [< (null)>]
(null)
[ 16.203063] RSP: 0018:880015fa7d80 EFLAGS: 00010246
[ 16.203063] RAX: 818e4bc0 RBX:
Re: [LKP] [userns] BUG: unable to handle kernel NULL pointer dereference at (null)
On Mon, 2014-12-15 at 11:31 -0600, Eric W. Biederman wrote:
> Huang Ying writes:
>
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> > for-testing
> > commit bbea5f5532501fdd67f46442ba7b1122d7ff3123
> > ("userns: Add a knob to disable setgroups on a per user namespace basis")
>
> Thank you.
>
> I am quite puzzled by this failure. There was an similar failure when
> /proc/[pid]/setgroups was read (if I recall correctly). I don't see how
> that change could result at failures during open or failures during
> boot. I added a new file to proc which any reasonable system should
> leave alone. Are you by chance running trinity during boot?
Yes. We are running trinity during boot.
> If the reproducer gave me any clue about which file that was opened or
> which code path this happened on I would be bery interested. If for no
> other reason that to confirm that I have fixed the issue.
This is just boot test, with trinity running after kernel boot.
Fengguang, do you have more information?
Best Regards,
Huang, Ying
> I have rewritten the implementation of /proc/[pid]/setgroups so it is
> simpler and more robust and does not have any errors I can detect.
>
> Thank you very much for picking up my for-testing branch and beating up
> on it.
>
> Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [userns] BUG: unable to handle kernel NULL pointer dereference at (null)
Huang Ying writes:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> for-testing
> commit bbea5f5532501fdd67f46442ba7b1122d7ff3123
> ("userns: Add a knob to disable setgroups on a per user namespace basis")
Thank you.
I am quite puzzled by this failure. There was an similar failure when
/proc/[pid]/setgroups was read (if I recall correctly). I don't see how
that change could result at failures during open or failures during
boot. I added a new file to proc which any reasonable system should
leave alone. Are you by chance running trinity during boot?
If the reproducer gave me any clue about which file that was opened or
which code path this happened on I would be bery interested. If for no
other reason that to confirm that I have fixed the issue.
I have rewritten the implementation of /proc/[pid]/setgroups so it is
simpler and more robust and does not have any errors I can detect.
Thank you very much for picking up my for-testing branch and beating up
on it.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [userns] BUG: unable to handle kernel NULL pointer dereference at (null)
Huang Ying ying.hu...@intel.com writes: FYI, we noticed the below changes on git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing commit bbea5f5532501fdd67f46442ba7b1122d7ff3123 (userns: Add a knob to disable setgroups on a per user namespace basis) Thank you. I am quite puzzled by this failure. There was an similar failure when /proc/[pid]/setgroups was read (if I recall correctly). I don't see how that change could result at failures during open or failures during boot. I added a new file to proc which any reasonable system should leave alone. Are you by chance running trinity during boot? If the reproducer gave me any clue about which file that was opened or which code path this happened on I would be bery interested. If for no other reason that to confirm that I have fixed the issue. I have rewritten the implementation of /proc/[pid]/setgroups so it is simpler and more robust and does not have any errors I can detect. Thank you very much for picking up my for-testing branch and beating up on it. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [userns] BUG: unable to handle kernel NULL pointer dereference at (null)
On Mon, 2014-12-15 at 11:31 -0600, Eric W. Biederman wrote: Huang Ying ying.hu...@intel.com writes: FYI, we noticed the below changes on git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing commit bbea5f5532501fdd67f46442ba7b1122d7ff3123 (userns: Add a knob to disable setgroups on a per user namespace basis) Thank you. I am quite puzzled by this failure. There was an similar failure when /proc/[pid]/setgroups was read (if I recall correctly). I don't see how that change could result at failures during open or failures during boot. I added a new file to proc which any reasonable system should leave alone. Are you by chance running trinity during boot? Yes. We are running trinity during boot. If the reproducer gave me any clue about which file that was opened or which code path this happened on I would be bery interested. If for no other reason that to confirm that I have fixed the issue. This is just boot test, with trinity running after kernel boot. Fengguang, do you have more information? Best Regards, Huang, Ying I have rewritten the implementation of /proc/[pid]/setgroups so it is simpler and more robust and does not have any errors I can detect. Thank you very much for picking up my for-testing branch and beating up on it. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [userns] BUG: unable to handle kernel NULL pointer dereference at (null)
On Tue, Dec 16, 2014 at 09:47:39AM +0800, Huang, Ying wrote: On Mon, 2014-12-15 at 11:31 -0600, Eric W. Biederman wrote: Huang Ying ying.hu...@intel.com writes: FYI, we noticed the below changes on git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing commit bbea5f5532501fdd67f46442ba7b1122d7ff3123 (userns: Add a knob to disable setgroups on a per user namespace basis) Thank you. I am quite puzzled by this failure. There was an similar failure when /proc/[pid]/setgroups was read (if I recall correctly). I don't see how that change could result at failures during open or failures during boot. I added a new file to proc which any reasonable system should leave alone. Are you by chance running trinity during boot? Yes. We are running trinity during boot. If the reproducer gave me any clue about which file that was opened or which code path this happened on I would be bery interested. If for no other reason that to confirm that I have fixed the issue. This is just boot test, with trinity running after kernel boot. Fengguang, do you have more information? The trinity runs like this cd /tmp /usr/local/bin/trinity -q -X -x get_robust_list -N 99 Here are all the call traces. You can see some tracesys_phase2() in some of the traces. It's a very reproducible error. dmesg-vm-vp-quantal-x86_64-14:20141214024709:x86_64-rhel:3.18.0-rc6-00015-gbbea5f5:1 [5.970508] init: Failed to create pty - disabling logging for job [5.973062] init: Failed to create pty - disabling logging for job [5.989614] init: Failed to create pty - disabling logging for job [ 16.365667] BUG: unable to handle kernel NULL pointer dereference at (null) [ 16.366010] IP: [ (null)] (null) [ 16.366010] PGD 15ce4067 PUD 15d40067 PMD 0 [ 16.366010] Oops: 0010 [#1] SMP [ 16.366010] Modules linked in: [ 16.366010] CPU: 0 PID: 308 Comm: trinity-main Not tainted 3.18.0-rc6-00015-gbbea5f5 #1 [ 16.366010] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 16.366010] task: 880015d0bac0 ti: 8806c000 task.ti: 8806c000 [ 16.366010] RIP: 0010:[] [ (null)] (null) [ 16.366010] RSP: 0018:8806fd80 EFLAGS: 00010246 [ 16.366010] RAX: 818e4bc0 RBX: 8806fe38 RCX: 8800149bb540 [ 16.366010] RDX: RSI: 8806fe38 RDI: 8800149bb540 [ 16.366010] RBP: 8806fe28 R08: R09: [ 16.366010] R10: R11: 8800149bb540 R12: 880015939400 [ 16.366010] R13: 8806fde8 R14: R15: 0041 [ 16.366010] FS: 7f38e5814700() GS:88001360() knlGS: [ 16.366010] CS: 0010 DS: ES: CR0: 80050033 [ 16.366010] CR2: CR3: 163c5000 CR4: 06f0 [ 16.366010] DR0: 021223d8 DR1: DR2: [ 16.366010] DR3: DR6: 0ff0 DR7: 00090602 [ 16.366010] Stack: [ 16.366010] 811f05c8 8800121df000 880015d0bac0 880015d0bac0 [ 16.366010] 8800149bb540 8806ff24 8800121df000 880015d0bac0 [ 16.366010] 880015d0bac0 df9a5ea7 880006b9f160 [ 16.366010] Call Trace: [ 16.366010] [811f05c8] ? path_openat+0x538/0x680 [ 16.366010] [811f26ca] do_filp_open+0x3a/0xb0 [ 16.366010] [811ff947] ? __alloc_fd+0xa7/0x130 [ 16.366010] [811df5ec] do_sys_open+0x12c/0x220 [ 16.366010] [811df6fe] SyS_open+0x1e/0x20 [ 16.366010] [81897f29] system_call_fastpath+0x12/0x17 [ 16.366010] Code: Bad RIP value. [ 16.366010] RIP [ (null)] (null) [ 16.366010] RSP 8806fd80 [ 16.366010] CR2: [ 16.448360] ---[ end trace 28f4ad5b31699327 ]--- [ 16.449384] Kernel panic - not syncing: Fatal exception dmesg-vm-vp-quantal-x86_64-16:20141214033109:x86_64-rhel:3.18.0-rc6-00015-gbbea5f5:1 [5.751305] init: Failed to create pty - disabling logging for job [5.754282] init: Failed to create pty - disabling logging for job [5.770351] init: Failed to create pty - disabling logging for job [ 16.202720] BUG: unable to handle kernel NULL pointer dereference at (null) [ 16.203063] IP: [ (null)] (null) [ 16.203063] PGD 158b6067 PUD 158ab067 PMD 0 [ 16.203063] Oops: 0010 [#1] SMP [ 16.203063] Modules linked in: [ 16.203063] CPU: 1 PID: 308 Comm: trinity-main Not tainted 3.18.0-rc6-00015-gbbea5f5 #1 [ 16.203063] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 16.203063] task: 88001624 ti: 880015fa4000 task.ti: 880015fa4000 [ 16.203063] RIP: 0010:[] [ (null)] (null) [ 16.203063] RSP: 0018:880015fa7d80
