linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Kent <ikent@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Benjamin Coddington <bcodding@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Stanislav Kinsbursky <skinsbursky@parallels.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	David Howells <dhowells@redhat.com>,
	Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [RFC PATCH 3/4] kmod - add call_usermodehelper_ns() helper
Date: Thu, 04 Dec 2014 06:53:46 +0800	[thread overview]
Message-ID: <1417647226.2581.17.camel@pluto.fritz.box> (raw)
In-Reply-To: <87zjb4k7b6.fsf@x220.int.ebiederm.org>

On Wed, 2014-12-03 at 10:49 -0600, Eric W. Biederman wrote:
> 
> >> > Those are the general parameters.
> >> 
> >> It does seem very expensive to keep a thread around for every mount; I'm
> >> still trying to find a way around it..
> >
> > Yeah, that's not such a good idea.
> >
> > Several hundred mounts is going to create a big mess for system
> > administrators, not to mention the overhead. It's right up there with
> > symlinking /etc/mtab to /proc/self/mounts at sites with large direct
> > mount maps.
> 
> A thread will cost you maybe 40k.  In the grand scheme of things that
> really isn't a lot.  I agree that it would be nice to do better than
> one thread per mount.   But I start with a thread as a reference point
> as that is the trivial way to get things correct.

Sure it has merit because it's straight forward but my criticism isn't
about overhead. It's about system administrators annoyance and
frustration level when they're trying get things done.

For example, with the symlinking of the mount table and even just a few
hundred direct automounts, listing the mount table fills the screen with
tombs of stuff that really should be hidden (and only listed if
requested). That just gets in the way when you're trying desperately to
resolve some urgent problem.

There is a resource issue as well since so many site administration
applications will read the table and, as the number of entries gets
larger, so does the time these things take to run. Not having to deal
with this on a day to day basis tends to make us forget about these
little side issues but I think they are important. 

Point is, for process listings the issue is almost exactly the same.

Ian


  parent reply	other threads:[~2014-12-03 22:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25  1:07 [RFC PATCH 0/4] Namespace contrained helper execution Ian Kent
2014-11-25  1:07 ` [RFC PATCH 1/4] vfs - fs/namespaces.c: break out mntns_setfs() from mntns_install() Ian Kent
2014-11-25  1:07 ` [RFC PATCH 2/4] nsproxy - make create_new_namespaces() non-static Ian Kent
2014-11-25  1:07 ` [RFC PATCH 3/4] kmod - add call_usermodehelper_ns() helper Ian Kent
2014-11-25 21:52   ` Oleg Nesterov
2014-11-25 22:06     ` Oleg Nesterov
2014-11-25 22:23       ` Eric W. Biederman
2014-11-25 23:07         ` Ian Kent
2014-11-25 23:19           ` Eric W. Biederman
2014-11-25 23:50             ` Ian Kent
2014-11-26  0:44               ` Ian Kent
2014-11-26  1:38               ` Eric W. Biederman
2014-12-01 21:56                 ` Benjamin Coddington
2014-12-02 23:33                   ` Ian Kent
2014-12-03 16:49                     ` Eric W. Biederman
2014-12-03 18:14                       ` Benjamin Coddington
2014-12-03 22:53                       ` Ian Kent [this message]
2014-12-03 23:34                       ` Ian Kent
2014-11-25 23:14       ` Ian Kent
2014-11-26 11:46       ` David Howells
2014-11-26 15:00         ` Eric W. Biederman
2014-11-26 22:57           ` J. Bruce Fields
2014-11-25 22:36     ` Ian Kent
2014-11-25 23:27       ` Eric W. Biederman
2014-11-28  0:19         ` Ian Kent
2014-11-27  1:30       ` Oleg Nesterov
2014-11-25  1:07 ` [RFC PATCH 4/4] KEYS: exec request-key within the requesting task's namespace Ian Kent

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=1417647226.2581.17.camel@pluto.fritz.box \
    --to=ikent@redhat.com \
    --cc=bcodding@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=skinsbursky@parallels.com \
    --cc=trond.myklebust@primarydata.com \
    --cc=viro@ZenIV.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).