Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1300068 > unrolled thread

Re: cgroup: BUG: unable to handle kernel NULL pointer dereference

Started byTejun Heo <tj@kernel.org>
First post2016-01-02 13:00 +0100
Last post2016-01-04 20:20 +0100
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: cgroup: BUG: unable to handle kernel NULL pointer dereference Tejun Heo <tj@kernel.org> - 2016-01-02 13:00 +0100
    Re: cgroup: BUG: unable to handle kernel NULL pointer dereference "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2016-01-02 19:30 +0100
      Re: cgroup: BUG: unable to handle kernel NULL pointer dereference "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2016-01-03 02:10 +0100
        Re: cgroup: BUG: unable to handle kernel NULL pointer dereference "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2016-01-03 04:50 +0100
    Re: cgroup: BUG: unable to handle kernel NULL pointer dereference Tejun Heo <tj@kernel.org> - 2016-01-04 20:20 +0100
    Re: cgroup: BUG: unable to handle kernel NULL pointer dereference "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2016-01-04 20:20 +0100

#1300068 — Re: cgroup: BUG: unable to handle kernel NULL pointer dereference

FromTejun Heo <tj@kernel.org>
Date2016-01-02 13:00 +0100
SubjectRe: cgroup: BUG: unable to handle kernel NULL pointer dereference
Message-ID<qMt0L-7Eq-23@gated-at.bofh.it>
On Fri, Jan 01, 2016 at 03:40:28PM -0800, Jeremiah Mahler wrote:
> all,
> 
> When running the latest linux-next (20151231) two of my machines
> hang early in the boot sequence.  The initial message is for a
> NULL pointer dereference.
> 
>   BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> 
> And the RIP line refers to cgroup_path.
> 
>   RIP [<ffffffff810eb178>] cgroup_path+0x30/0x80
> 
> Attached are pictures of the back trace.
> 
> Let me know if I can do anything else to help.  I will investigate the
> problem further if I get a chance.

This is most likely from the recent changes from cgroup ns support.
Reverted the patchset for now as it also introduced a bisectability
issue.  Serge, can you please look into this one?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1300109

From"Serge E. Hallyn" <serge.hallyn@ubuntu.com>
Date2016-01-02 19:30 +0100
Message-ID<qMz69-37P-7@gated-at.bofh.it>
In reply to#1300068
On Sat, Jan 02, 2016 at 06:54:37AM -0500, Tejun Heo wrote:
> On Fri, Jan 01, 2016 at 03:40:28PM -0800, Jeremiah Mahler wrote:
> > all,
> > 
> > When running the latest linux-next (20151231) two of my machines
> > hang early in the boot sequence.  The initial message is for a
> > NULL pointer dereference.
> > 
> >   BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> > 
> > And the RIP line refers to cgroup_path.
> > 
> >   RIP [<ffffffff810eb178>] cgroup_path+0x30/0x80
> > 
> > Attached are pictures of the back trace.
> > 
> > Let me know if I can do anything else to help.  I will investigate the
> > problem further if I get a chance.
> 
> This is most likely from the recent changes from cgroup ns support.
> Reverted the patchset for now as it also introduced a bisectability
> issue.  Serge, can you please look into this one?

Tried to reproduce with setting CONFIG_CFQ_GROUP_IOSCHED=y, but did not
succeed.  Could you send me the .config?  Also, if someone could send
the objdump -d output that might help.  Though really, it seems clear
that current->nsproxy must be NULL.  Hm, that's right -  we used to have
that issue in pidns (or was it netns) during process exit.  I don't know
that I'll get time this afternoon, but I'll look into it asap.

thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1300159

From"Serge E. Hallyn" <serge.hallyn@ubuntu.com>
Date2016-01-03 02:10 +0100
Message-ID<qMFlg-75N-3@gated-at.bofh.it>
In reply to#1300109
On Sat, Jan 02, 2016 at 01:50:49PM -0800, Jeremiah Mahler wrote:
> Serge,
> 
> On Sat, Jan 02, 2016 at 12:24:16PM -0600, Serge E. Hallyn wrote:
> [...]
> > 
> > Tried to reproduce with setting CONFIG_CFQ_GROUP_IOSCHED=y, but did not
> > succeed.  Could you send me the .config?  Also, if someone could send
> > the objdump -d output that might help.  Though really, it seems clear
> > that current->nsproxy must be NULL.  Hm, that's right -  we used to have
> > that issue in pidns (or was it netns) during process exit.  I don't know
> > that I'll get time this afternoon, but I'll look into it asap.
> > 
> > thanks.
> 
> Attached is the .config I used.  I can send an objdump, but do you want
> a dump of the kernel, where the cgroup code is?
> 
> -- 
> - Jeremiah Mahler

Thanks - Shoulda looked at the exit path before - exit_io_context is called
after exit_task_namespaces().

I'll have to figure out the best way to handle this.  In the past we've
restructured exit code to ensure that anything wanting to dereference
nsproxy happened before exit_task_namespaces().  However, this is only
happening in a debug stmt at blkg_path() in
http://lxr.free-electrons.com/source/include/linux/blk-cgroup.h#L344
so simply returning the init_cgroup_namespace is actually the right thing
to do.  I'm tempted to add a init_cgroup_path() which ignores namespaces,
for use in debugging statements.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1300171

From"Serge E. Hallyn" <serge.hallyn@ubuntu.com>
Date2016-01-03 04:50 +0100
Message-ID<qMHQ5-5C-5@gated-at.bofh.it>
In reply to#1300159
On Sat, Jan 02, 2016 at 06:59:16PM -0600, Serge E. Hallyn wrote:
> On Sat, Jan 02, 2016 at 01:50:49PM -0800, Jeremiah Mahler wrote:
> > Serge,
> > 
> > On Sat, Jan 02, 2016 at 12:24:16PM -0600, Serge E. Hallyn wrote:
> > [...]
> > > 
> > > Tried to reproduce with setting CONFIG_CFQ_GROUP_IOSCHED=y, but did not
> > > succeed.  Could you send me the .config?  Also, if someone could send
> > > the objdump -d output that might help.  Though really, it seems clear
> > > that current->nsproxy must be NULL.  Hm, that's right -  we used to have
> > > that issue in pidns (or was it netns) during process exit.  I don't know
> > > that I'll get time this afternoon, but I'll look into it asap.
> > > 
> > > thanks.
> > 
> > Attached is the .config I used.  I can send an objdump, but do you want
> > a dump of the kernel, where the cgroup code is?
> > 
> > -- 
> > - Jeremiah Mahler
> 
> Thanks - Shoulda looked at the exit path before - exit_io_context is called
> after exit_task_namespaces().
> 
> I'll have to figure out the best way to handle this.  In the past we've
> restructured exit code to ensure that anything wanting to dereference
> nsproxy happened before exit_task_namespaces().  However, this is only
> happening in a debug stmt at blkg_path() in
> http://lxr.free-electrons.com/source/include/linux/blk-cgroup.h#L344
> so simply returning the init_cgroup_namespace is actually the right thing
> to do.  I'm tempted to add a init_cgroup_path() which ignores namespaces,
> for use in debugging statements.

Or really I think it makes more sense to make cgroup_path_ns() take
the namespace into account, switch over cgroup_path() users who want _ns(),
and leave cgroup_path() using the initial cgroup namespace.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1300980

FromTejun Heo <tj@kernel.org>
Date2016-01-04 20:20 +0100
Message-ID<qNiPE-7CQ-5@gated-at.bofh.it>
In reply to#1300068
Happy new year, Serge.

On Mon, Jan 04, 2016 at 01:15:53PM -0600, Serge E. Hallyn wrote:
> an updated set is at https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/commit/?h=cgroupns.v9
> Would you like a new patchset send to the list, or is the github
> tree ok?

Please repost.

Thanks!

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1300983

From"Serge E. Hallyn" <serge.hallyn@ubuntu.com>
Date2016-01-04 20:20 +0100
Message-ID<qNiPE-7CQ-7@gated-at.bofh.it>
In reply to#1300068
On Sat, Jan 02, 2016 at 06:54:37AM -0500, Tejun Heo wrote:
> On Fri, Jan 01, 2016 at 03:40:28PM -0800, Jeremiah Mahler wrote:
> > all,
> > 
> > When running the latest linux-next (20151231) two of my machines
> > hang early in the boot sequence.  The initial message is for a
> > NULL pointer dereference.
> > 
> >   BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> > 
> > And the RIP line refers to cgroup_path.
> > 
> >   RIP [<ffffffff810eb178>] cgroup_path+0x30/0x80
> > 
> > Attached are pictures of the back trace.
> > 
> > Let me know if I can do anything else to help.  I will investigate the
> > problem further if I get a chance.
> 
> This is most likely from the recent changes from cgroup ns support.
> Reverted the patchset for now as it also introduced a bisectability
> issue.  Serge, can you please look into this one?

Hi Tejun,

an updated set is at https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/commit/?h=cgroupns.v9
Would you like a new patchset send to the list, or is the github
tree ok?

This branch:
  1. puts lookup_one_len() under inode lock
  2. makes cgroup_path non-namespaced, so only calls to
     cgroup_path_ns() are namespaced.
  3. makes cgroup_path{,_ns} take the needed locks, since
     external callers cannot do so.
  4. Fixes the bisectability problem of to_cg_ns() being
     defined after use (patch 4 -> patch 3)

thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web