All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Alexander Viro
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Subject: Re: [PATCH] core_pattern: set core helpers root and namespace to crashing process
Date: Thu, 13 Dec 2012 14:25:34 -0800	[thread overview]
Message-ID: <20121213142534.ea07a3c8.akpm@linux-foundation.org> (raw)
In-Reply-To: <20121213181220.GB14796-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>

On Thu, 13 Dec 2012 13:12:20 -0500
Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:

> On Thu, Dec 13, 2012 at 06:20:48AM -0600, Serge Hallyn wrote:
> > Quoting Neil Horman (nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org):
> > > Theres one problem I currently see with it, and that is that I'm not sure we can
> > > change the current behavior of how the root fs is set for the pipe reader, lest
> > > we break some user space expectations. As such, I've added a sysctl in this
> > > patch to allow administrators to globally select if a core reader specified via
> > > /proc/sys/kernel/core_pattern should use the global rootfs, or the (possibly)
> > > chrooted fs of the crashing process.
> > 
> > Practical question:  How is the admin to make an educated decision on
> > how to set the sysctl?

By reading the documentation which Neil didn't include?

> My thought was that the admin typically wouldn't touch this at all.  I really
> added it as a backwards compatibility option only.  Setting the user space
> helper task to the root of the crashing parent has the possibility of breaking
> existing installs because the core_pattern helper might be expecting global file
> system access.  Moving forward, my expectation would be that core_pattern
> helpers would be written with the default setting in mind, and we could
> eventually deprecate the control entirely.
> 
> If you have a better mechanism in mind however (or if you think that removing
> the control is a resaonable approach), I'm certainly open to that.

Yeah, this is a tiresome patch but I can't think of a better way.

Except, perhaps, adding a new token to the core_pattern which says
"switch namespaces"?

Is there any propect that the core_pattern itself will later become a
per-namespace containerised thing?  I guess that if the per-container
core_pattern has been configured, we can implicitly do the namespace
switch as well.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Serge Hallyn <serge.hallyn@canonical.com>,
	linux-kernel@vger.kernel.org,
	Daniel Berrange <berrange@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	containers@lists.linux-foundation.org
Subject: Re: [PATCH] core_pattern: set core helpers root and namespace to crashing process
Date: Thu, 13 Dec 2012 14:25:34 -0800	[thread overview]
Message-ID: <20121213142534.ea07a3c8.akpm@linux-foundation.org> (raw)
In-Reply-To: <20121213181220.GB14796@hmsreliant.think-freely.org>

On Thu, 13 Dec 2012 13:12:20 -0500
Neil Horman <nhorman@tuxdriver.com> wrote:

> On Thu, Dec 13, 2012 at 06:20:48AM -0600, Serge Hallyn wrote:
> > Quoting Neil Horman (nhorman@tuxdriver.com):
> > > Theres one problem I currently see with it, and that is that I'm not sure we can
> > > change the current behavior of how the root fs is set for the pipe reader, lest
> > > we break some user space expectations. As such, I've added a sysctl in this
> > > patch to allow administrators to globally select if a core reader specified via
> > > /proc/sys/kernel/core_pattern should use the global rootfs, or the (possibly)
> > > chrooted fs of the crashing process.
> > 
> > Practical question:  How is the admin to make an educated decision on
> > how to set the sysctl?

By reading the documentation which Neil didn't include?

> My thought was that the admin typically wouldn't touch this at all.  I really
> added it as a backwards compatibility option only.  Setting the user space
> helper task to the root of the crashing parent has the possibility of breaking
> existing installs because the core_pattern helper might be expecting global file
> system access.  Moving forward, my expectation would be that core_pattern
> helpers would be written with the default setting in mind, and we could
> eventually deprecate the control entirely.
> 
> If you have a better mechanism in mind however (or if you think that removing
> the control is a resaonable approach), I'm certainly open to that.

Yeah, this is a tiresome patch but I can't think of a better way.

Except, perhaps, adding a new token to the core_pattern which says
"switch namespaces"?

Is there any propect that the core_pattern itself will later become a
per-namespace containerised thing?  I guess that if the per-container
core_pattern has been configured, we can implicitly do the namespace
switch as well.


  parent reply	other threads:[~2012-12-13 22:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11 19:59 [PATCH] core_pattern: set core helpers root and namespace to crashing process Neil Horman
     [not found] ` <1355255996-25953-1-git-send-email-nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
2012-12-13 12:20   ` Serge Hallyn
2012-12-13 12:20     ` Serge Hallyn
2012-12-13 18:12     ` Neil Horman
     [not found]       ` <20121213181220.GB14796-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2012-12-13 22:25         ` Andrew Morton [this message]
2012-12-13 22:25           ` Andrew Morton
     [not found]           ` <20121213142534.ea07a3c8.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2012-12-14  2:49             ` Neil Horman
2012-12-14  2:49               ` Neil Horman
     [not found]               ` <20121214024938.GA6591-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>
2012-12-14  9:04                 ` Daniel P. Berrange
2012-12-14  9:04                   ` Daniel P. Berrange
2012-12-13 18:12     ` Neil Horman
2012-12-14 21:04   ` [PATCH v2] " Neil Horman
2012-12-14 21:04 ` Neil Horman
     [not found]   ` <1355519048-28473-1-git-send-email-nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
2012-12-14 21:49     ` Andrew Morton
2012-12-14 21:49       ` Andrew Morton
2012-12-14 23:10     ` Eric W. Biederman
2012-12-14 23:10       ` Eric W. Biederman
     [not found]       ` <87d2ycut5l.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-15  0:50         ` Neil Horman
2012-12-15  0:50           ` Neil Horman
  -- strict thread matches above, loose matches on Subject: below --
2012-12-11 19:59 [PATCH] " Neil Horman

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=20121213142534.ea07a3c8.akpm@linux-foundation.org \
    --to=akpm-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.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.