Eric W. Biederman wrote:
> Dave Hansen <[EMAIL PROTECTED]> writes:
>
>
>>So, I think we have a difference of opinion. I think it's _all_ about
>>memory pressure, and you think it is _not_ about accounting for memory
>>pressure. :) Perhaps we mean different things, but we appear to
>>disagree gr
On Wed, Mar 21, 2007 at 01:39:38PM -0700, Andrew Morton wrote:
> On Wed, 21 Mar 2007 12:41:03 -0700
> [EMAIL PROTECTED] wrote:
>
> > This was discussed on containers and we thought it would be useful
> > to reserve this flag.
> > ---
> >
> > From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
> > Subje
On Wed, Mar 21, 2007 at 11:30:14AM -0600, Eric W. Biederman wrote:
> Cedric Le Goater <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] wrote:
> >> This was discussed on containers and we thought it would be useful
> >> to reserve this flag.
> >> ---
> >>
> >> From: Sukadev Bhattiprolu <[EMAIL
On Wed, Mar 21, 2007 at 03:23:28AM -0600, Eric W. Biederman wrote:
> [EMAIL PROTECTED] writes:
>
> > From: Cedric Le Goater <[EMAIL PROTECTED]>
> > Subject: [RFC][PATCH 06/14] Populate pid_nrs list with entry for init-pid-ns
> >
> > Create/destroy the pid->pid_nrs list - when allocating/freeing a
On Thu, Mar 22, 2007 at 09:33:50AM -0500, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> ...
> > Back to the main subject I still don't understand the idea of running
> > a kernel daemon as pid == 1. What would that buy us?
>
> I think the idea is that for lightweight a
On Thu, Mar 22, 2007 at 02:14:48PM +0100, Cedric Le Goater wrote:
>
> >> So I suggested to have a kthread be pid == 1 for each new pid
> >> namespace. the kthread can do the killing of all tasks if needed
> >> and will die when the refcount on the pid namespace == 0.
> >>
> >> Would such a (rough)
On Tue, Mar 20, 2007 at 11:00:57AM -0500, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> > "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >
> > > Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> > >> Dave Hansen <[EMAIL PROTECTED]> writes:
> > >> > On Mon, 2007-03-19 at
On Mon, Mar 19, 2007 at 08:04:12PM -0600, Eric W. Biederman wrote:
> Dave Hansen <[EMAIL PROTECTED]> writes:
>
> > I was tracking down why we need find_get_pid(1) in
> > proc_get_sb(), when I realized that we apparently
> > don't need a pid at all in the non-pid parts of /proc.
> >
> > Anyone see
On Tue, Mar 20, 2007 at 03:19:16PM -0600, Eric W. Biederman wrote:
> Dave Hansen <[EMAIL PROTECTED]> writes:
>
> >
> > So, I think we have a difference of opinion. I think it's _all_
> > about memory pressure, and you think it is _not_ about accounting
> > for memory pressure. :) Perhaps we mean d
On Thu, 2007-03-22 at 14:24 -0600, Eric W. Biederman wrote:
> Rishikesh <[EMAIL PROTECTED]> writes:
> > I am getting this error while compilation on x86 on ABAT. Job ID: 78220
> > You can find more detailed log here :
> > http://abat.linux.ibm.com/abat-repo/logs/[EMAIL
> > PROTECTED]/host:1/debug
Rishikesh <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> I am getting this error while compilation on x86 on ABAT. Job ID: 78220
> You can find more detailed log here :
> http://abat.linux.ibm.com/abat-repo/logs/[EMAIL
> PROTECTED]/host:1/debug/test.log.0
If you are inside ibm's firewall.
Otherwise
Dave Hansen <[EMAIL PROTECTED]> writes:
> So, doesn't that problem go away (or at least move to be umount's duty)
> if we completely disconnect those inodes' lifetime from that of any
> process or pid namespace?
If the last process has exited the pid namespace I would like the
code to continue to
[EMAIL PROTECTED] (Eric W. Biederman)22/03/2007 14:02 CST Pour : Benjamin Thery <[EMAIL PROTECTED]> cc : "Denis V. Lunev" <[EMAIL PROTECTED]>, Linux Containers <[EMAIL PROTECTED]>, Dave Hansen <[EMAIL PROTECTED]> ccc : Objet : Re: [Devel] Re: [PATCHSET] 2.6.20-lxc8 Benjamin Thery <[EMAIL PROTECTE
Benjamin Thery <[EMAIL PROTECTED]> writes:
> My investigations on the increase of cpu load when running netperf inside a
> container (ie. through etun2<->etun1) is progressing slowly.
>
> I'm not sure the cause is fragmentation as we supposed initially.
> In fact, it seems related to forwarding th
Dave Hansen <[EMAIL PROTECTED]> writes:
> On Thu, 2007-03-22 at 09:33 -0500, Serge E. Hallyn wrote:
>>
>>
>> I still prefer that we forego that kthread, and just work toward
>> allowing pid1 to exit. Really I think the crufty /proc/ handling
>> is the only reason we were going to punt on that f
Quoting Ian Kent ([EMAIL PROTECTED]):
> How does this affect getting ids for waitq request packets of other user
> space processes triggering mounts? I'm guessing that they would need to
> belong to the appropriate namespace for this mechanism to funtion
> correctly.
A feature of the pid namespace
Eric W. Biederman wrote:
> "Denis V. Lunev" <[EMAIL PROTECTED]> writes:
>
>> Kirill Korotaev wrote:
>>> if network device inside container has MTU higher then eth0 outside the
>> container,
>>> then packets will get fragmented.
>>> First time to MTU1 inside container and refragmented to MTU2
>>> o
On Thu, 22 Mar 2007 14:25:42 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> Additions and removal from tty_drivers list were just done as well as
> iterating on it for /proc/tty/drivers generation.
>
> testing: modprobe/rmmod loop of simple module which does nothing but
> tty_register_driver(
Quoting Dave Hansen ([EMAIL PROTECTED]):
> On Thu, 2007-03-22 at 09:33 -0500, Serge E. Hallyn wrote:
> >
> >
> > I still prefer that we forego that kthread, and just work toward
> > allowing pid1 to exit. Really I think the crufty /proc/ handling
> > is the only reason we were going to punt on t
On Thu, 2007-03-22 at 09:33 -0500, Serge E. Hallyn wrote:
>
>
> I still prefer that we forego that kthread, and just work toward
> allowing pid1 to exit. Really I think the crufty /proc/ handling
> is the only reason we were going to punt on that for now.
It's everything _but_ the /proc/ stuff
On Tue, 2007-03-20 at 16:04 -0600, Eric W. Biederman wrote:
> Dave Hansen <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2007-03-20 at 09:51 -0600, Eric W. Biederman wrote:
> >> Outlive is the wrong concept. Ideally we want something that will
> >> live as long as there are processes in the pid_ns.
>
Ian Kent <[EMAIL PROTECTED]> writes:
> btw please don't be confused by my use of "user space application". In
> my comments I'm talking about applications that are similar in function
> to autofs itself and not processes that might trigger mounts. For
> example the "autodir" package uses the autof
Ian Kent <[EMAIL PROTECTED]> writes:
> On Wed, 2007-03-21 at 15:58 -0500, Serge E. Hallyn wrote:
>> PS
>> Note that if I'm right, but some machine starts autofs in a child
>> pid_namespace, the pid_nr() the way I have it is wrong. I'm not sure in
>> that case how we go about fixing that. Someho
Cedric Le Goater <[EMAIL PROTECTED]> writes:
>> Back to the main subject I still don't understand the idea of running
>> a kernel daemon as pid == 1. What would that buy us?
>
> mostly a child reaper when there are no /sbin/init but its pid cannot
> be 1.
Yes we should be able to assign just ab
On Thu, 2007-03-22 at 15:33 +0100, Herbert Poetzl wrote:
> On Thu, Mar 22, 2007 at 11:28:43AM +0900, Ian Kent wrote:
> > On Wed, 2007-03-21 at 15:58 -0500, Serge E. Hallyn wrote:
> > > Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> > > > "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> > > >
> >
On Thu, 2007-03-22 at 08:31 -0500, Serge E. Hallyn wrote:
> > >
> > > From: "Serge E. Hallyn" <[EMAIL PROTECTED]>
> > > Subject: [PATCH] autofs: prevent pid wraparound in waitqs
> > >
> > > Instead of storing pid numbers for waitqs, store references
> > > to struct pids. Also store a reference t
On Thu, 2007-03-22 at 08:31 -0500, Serge E. Hallyn wrote:
> Quoting Ian Kent ([EMAIL PROTECTED]):
> > On Wed, 2007-03-21 at 21:19 -0500, Serge E. Hallyn wrote:
> > > Quoting Ian Kent ([EMAIL PROTECTED]):
> > > > On Tue, 2007-03-20 at 16:01 -0600, Eric W. Biederman wrote:
> > > > > "Serge E. Hallyn"
>>From sysvinit src/init.c:main
>>/*
>> * Is this telinit or init ?
>> */
>>isinit = (getpid() == 1);
>>for (f = 1; f < argc; f++) {
>>if (!strcmp(argv[f], "-i") || !strcmp(argv[f], "--init"))
>>isinit = 1;
>>
On Thu, Mar 22, 2007 at 09:39:09AM -0500, Serge E. Hallyn wrote:
> > What troubles will mounting both cpuset and ns in the same hierarchy
> > cause?
>
> Wow, don't recall the full context here.
Sorry to have come back so late on this :)
> But at least with Paul's container patchset, a subsystem
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
> > The nsproxy container subsystem could be said to be that unification.
> > If we really wanted to I suppose we could now always mount the nsproxy
> > subsystem, get rid of tsk->nspr
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
...
> Back to the main subject I still don't understand the idea of running
> a kernel daemon as pid == 1. What would that buy us?
I think the idea is that for lightweight application containers, where
there is no explicit /sbin/init process, the kth
On Thu, Mar 22, 2007 at 11:28:43AM +0900, Ian Kent wrote:
> On Wed, 2007-03-21 at 15:58 -0500, Serge E. Hallyn wrote:
> > Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> > > "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> > >
> > > >> > void autofs4_dentry_release(struct dentry *);
> > > >> > e
Cedric Le Goater <[EMAIL PROTECTED]> writes:
>>> So I suggested to have a kthread be pid == 1 for each new pid namespace.
>>> the kthread can do the killing of all tasks if needed and will die when
>>> the refcount on the pid namespace == 0.
>>>
>>> Would such a (rough) design be acceptable for m
On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
> The nsproxy container subsystem could be said to be that unification.
> If we really wanted to I suppose we could now always mount the nsproxy
> subsystem, get rid of tsk->nsproxy, and always get thta through it's
> nsproxy subsyste
Quoting Ian Kent ([EMAIL PROTECTED]):
> On Wed, 2007-03-21 at 21:19 -0500, Serge E. Hallyn wrote:
> > Quoting Ian Kent ([EMAIL PROTECTED]):
> > > On Tue, 2007-03-20 at 16:01 -0600, Eric W. Biederman wrote:
> > > > "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> > > >
> > > > >> > void autofs4_den
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >
> > So is the pid used for anything other than debugging?
> >
> > In any case, here is a replacement patch which sends the pid number
> > in the pid_namespace of the process which did the autofs4 moun
>> So I suggested to have a kthread be pid == 1 for each new pid namespace.
>> the kthread can do the killing of all tasks if needed and will die when
>> the refcount on the pid namespace == 0.
>>
>> Would such a (rough) design be acceptable for mainline ?
>
> The case that preserves existing se
"Denis V. Lunev" <[EMAIL PROTECTED]> writes:
> Kirill Korotaev wrote:
>>
>> if network device inside container has MTU higher then eth0 outside the
> container,
>> then packets will get fragmented.
>> First time to MTU1 inside container and refragmented to MTU2
>> outside the container. At least
Cedric Le Goater <[EMAIL PROTECTED]> writes:
> [ long long thread ]
>
> Eric W. Biederman wrote:
>> Cedric Le Goater <[EMAIL PROTECTED]> writes:
>>
> what about a kthread that would be spawned when a task is cloned in an
> unshared pid namespace ? This is an extra cost in term of tasks.
Additions and removal from tty_drivers list were just done as well as
iterating on it for /proc/tty/drivers generation.
testing: modprobe/rmmod loop of simple module which does nothing but
tty_register_driver() vs cat /proc/tty/drivers loop
BUG: unable to handle kernel paging request at virtual a
On Thu, Mar 22, 2007 at 03:26:51PM +0530, Srivatsa Vaddagiri wrote:
> On Mon, Feb 12, 2007 at 12:15:22AM -0800, [EMAIL PROTECTED] wrote:
> > +static void remove_dir(struct dentry *d)
> > +{
> > + struct dentry *parent = dget(d->d_parent);
>
> Don't we need to lock parent inode's mutex here? sysf
Kirill Korotaev wrote:
> Eric W. Biederman wrote:
>> Daniel Lezcano <[EMAIL PROTECTED]> writes:
>>
>>
>>> Benjamin Thery and I we were looking at this.
>>> For the moment we are investigating if there is IP fragmentation between the
>>> eth0 and the pair devices.
>>> The profiling shows us "pskb_ex
[ long long thread ]
Eric W. Biederman wrote:
> Cedric Le Goater <[EMAIL PROTECTED]> writes:
>
what about a kthread that would be spawned when a task is cloned in an
unshared pid namespace ? This is an extra cost in term of tasks.
>>> If you use kernel_thread this can happen. (Die ker
On Mon, Feb 12, 2007 at 12:15:22AM -0800, [EMAIL PROTECTED] wrote:
> +static void remove_dir(struct dentry *d)
> +{
> + struct dentry *parent = dget(d->d_parent);
Don't we need to lock parent inode's mutex here? sysfs seems to take
that lock.
> +
> + d_delete(d);
> + simple_rmdir(pare
Eric W. Biederman wrote:
> Daniel Lezcano <[EMAIL PROTECTED]> writes:
>
>
>>Benjamin Thery and I we were looking at this.
>>For the moment we are investigating if there is IP fragmentation between the
>>eth0 and the pair devices.
>>The profiling shows us "pskb_expand_head" and "csum_partial_copy_
45 matches
Mail list logo
