On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Ok.. so my problem still remains, how do I get a non-blocking atomic
reference increment/decrement routine, that would prevent my
container from being deleted?
css_put() in my new patchset will be non-blocking.
I don't find cpusets using c
On Wed, Jul 18, 2007 at 11:00:39AM +0530, Balbir Singh wrote:
> Thinking out loud again, can we add can_destory() callbacks?
I remember suggesting such a callback long before :
http://marc.info/?l=linux-kernel&m=117576241131788&w=2
--
Regards,
vatsa
_
Balbir Singh wrote:
> Paul (??) Menage wrote:
>> On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>>> without too much knowledge of each other. BTW, what are the semantics
>>> of css_put() is it expected to free the container/run the release agent
>>> when the reference count of the container_su
Paul (??) Menage wrote:
> On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> without too much knowledge of each other. BTW, what are the semantics
>> of css_put() is it expected to free the container/run the release agent
>> when the reference count of the container_subsys_state drops to zero?
On Tue, 17 Jul 2007 14:36:10 +0200
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>
> > On every open/close one struct seq_operations leaks.
> > Kudos to /proc/slab_allocators.
> >
> > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
>
> ouch ...
>
>
On Mon, Jul 16, 2007 at 10:08:00AM -0500, Serge E. Hallyn wrote:
> Quoting Kirill Korotaev ([EMAIL PROTECTED]):
> > Serge E. Hallyn wrote:
> > > Quoting Andrew Morton ([EMAIL PROTECTED]):
> > >
> > >>On Mon, 4 Jun 2007 14:40:24 -0500 "Serge E. Hallyn" <[EMAIL PROTECTED]>
> > >>wrote:
> > >>
> > >
>From 32f86740d27ef77160e438cd7dc4fcd5df159dd0 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Tue, 17 Jul 2007 15:28:17 -0400
Subject: [PATCH 1/1] user namespace: fix copy_user_ns return value
When a CONFIG_USER_NS=n and a user tries to unshare some
namespace other than t
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
without too much knowledge of each other. BTW, what are the semantics
of css_put() is it expected to free the container/run the release agent
when the reference count of the container_subsys_state drops to zero?
If you css_put() the last refe
Quoting Kirill Korotaev ([EMAIL PROTECTED]):
> > Unfortunately I'm unlikely to be there (late notice - I really need to
> > keep a better list of upcoming conferences and proposal deadlines!).
> > But it still sounds like a good idea.
>
> It's a pity :/ I though you are the primary candidate for p
Paul (??) Menage wrote:
> On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>>
>> That sounds correct. I wonder now if the solution should be some form
>> of delegation for deletion of unreferenced containers (HINT: work queue
>> or kernel threads).
>
> What a great idea. In fact, that's exactly
Quoting Paul (?$BJuN\) Menage ([EMAIL PROTECTED]):
> On 7/17/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >
> >Depending on the format of the containers mini-summit, would it make
> >sense to set up a phone number so others can dial in? Or would it be
> >better to have a smaller group anyway?
Paul M wrote:
> In fact, that's exactly what the release agent
> patch already does.
I'm feeling lazy ;) What's the Subject of that
patch, for my easy searching?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jacks
Paul M wrote:
> Right, that's what the release agent patch for process containers does
> - there's a file in the hierarchy root called "release_agent" that
> contains the path to the program to run if a notify_on_release
> container goes idle. When you mount the "cpuset" filesystem, it
> automatica
On 7/17/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
Paul M wrote:
> In fact, that's exactly what the release agent
> patch already does.
I'm feeling lazy ;) What's the Subject of that
patch, for my easy searching?
"Support for automatic userspace release agents"
Paul
On 7/17/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
At least for cpusets (the mother of all containers), notify on release
is part of the user visible API of cpusets. The kernel does not remove
cpusets; it runs a user program, /sbin/cpuset_release_agent. That
program might choose to rmdir the
> That sounds correct. I wonder now if the solution should be some form
> of delegation for deletion of unreferenced containers (HINT: work queue
> or kernel threads).
At least for cpusets (the mother of all containers), notify on release
is part of the user visible API of cpusets. The kernel doe
Oleg Nesterov [EMAIL PROTECTED] wrote:
| On 07/16, [EMAIL PROTECTED] wrote:
| >
| > Oleg Nesterov [EMAIL PROTECTED] wrote:
| > |
| > | Could you please give more details why we need this change?
| >
| > Well, with multiple pid namespaces, we may need to allocate a new
| > 'struct pid_namespace' i
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
That sounds correct. I wonder now if the solution should be some form
of delegation for deletion of unreferenced containers (HINT: work queue
or kernel threads).
What a great idea. In fact, that's exactly what the release agent
patch already
Paul (??) Menage wrote:
> Because as soon as you do the atomic_dec_and_test() on css->refcnt and
> the refcnt hits zero, then theoretically someone other thread (that
> already holds container_mutex) could check that the refcount is zero
> and free the container structure.
>
Hi, Paul,
That sound
> Because as soon as you do the atomic_dec_and_test() on css->refcnt and
> the refcnt hits zero, then theoretically someone other thread (that
> already holds container_mutex) could check that the refcount is zero
> and free the container structure.
Not just theory ... I've debugged crashes from l
On 7/17/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
On Tue, 2007-07-17 at 08:49 -0700, Paul (宝瑠) Menage wrote:
> Because as soon as you do the atomic_dec_and_test() on css->refcnt and
> the refcnt hits zero, then theoretically someone other thread (that
> already holds container_mutex) could check
On 7/17/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
Depending on the format of the containers mini-summit, would it make
sense to set up a phone number so others can dial in? Or would it be
better to have a smaller group anyway?
I'd be interested in calling in if I can't make it myself.
On Tue, 2007-07-17 at 08:49 -0700, Paul (宝瑠) Menage wrote:
> Because as soon as you do the atomic_dec_and_test() on css->refcnt and
> the refcnt hits zero, then theoretically someone other thread (that
> already holds container_mutex) could check that the refcount is zero
> and free the container s
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Paul (??) Menage wrote:
> On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> >
>> > >mutex_lock(&container_mutex);
>> > >set_bit(CONT_RELEASABLE, &cont->flags);
>> > >- if (atomic_dec_and_test(&c
> Unfortunately I'm unlikely to be there (late notice - I really need to
> keep a better list of upcoming conferences and proposal deadlines!).
> But it still sounds like a good idea.
It's a pity :/ I though you are the primary candidate for presenting containers
at KLS.
> Depending on the forma
On 07/16, [EMAIL PROTECTED] wrote:
>
> Oleg Nesterov [EMAIL PROTECTED] wrote:
> |
> | Stupid question: why do we need to put the pid namespace into the struct
> | pid? Isn't it better if the user of the struct pid should know its ns?
> | For example, if /proc does put_pid(), that pid should be fro
On 07/16, [EMAIL PROTECTED] wrote:
>
> Oleg Nesterov [EMAIL PROTECTED] wrote:
> |
> | Could you please give more details why we need this change?
>
> Well, with multiple pid namespaces, we may need to allocate a new
> 'struct pid_namespace' if the CLONE_NEWPID flag is specified. And
> as a part o
On Tue, Jul 17, 2007 at 02:36:10PM +0200, Ingo Molnar wrote:
> * Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>
> > On every open/close one struct seq_operations leaks.
> > Kudos to /proc/slab_allocators.
> >
> > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
>
> ouch ...
>
> Acked-by: Ingo M
* Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> On every open/close one struct seq_operations leaks.
> Kudos to /proc/slab_allocators.
>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
ouch ...
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
-stable material too, as far as timer_info/stats goes
On every open/close one struct seq_operations leaks.
Kudos to /proc/slab_allocators.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
fs/proc/base.c|2 +-
kernel/sched_debug.c |2 +-
kernel/time/timer_list.c |2 +-
kernel/time/timer_stats.c |2 +-
4 files
Quoting Rohit Seth ([EMAIL PROTECTED]):
> On Sat, 2007-07-14 at 05:21 +0200, Kir Kolyshkin wrote:
> > I just got an idea -- what about organizing a one-day "containers
> > mini-summit" just before the Kernel Summit? We can all meet face to
> > face, discuss all the issues and come out with a good
These aren't modular, so SLAB_PANIC is OK.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
fs/proc/inode.c |4 +---
kernel/posix-timers.c |3 ++-
mm/shmem.c|4 +---
3 files changed, 4 insertions(+), 7 deletions(-)
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
Paul (??) Menage wrote:
> On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> >
>> > >mutex_lock(&container_mutex);
>> > >set_bit(CONT_RELEASABLE, &cont->flags);
>> > >- if (atomic_dec_and_test(&css->refcnt)) {
>> > >- check_for
On Tue, 17 Jul 2007 13:07:55 +0400 Kirill Korotaev <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Mon, 16 Jul 2007 16:24:12 +0400
> > Pavel Emelianov <[EMAIL PROTECTED]> wrote:
> >
> >
> >>When user locks an ipc shmem segmant with SHM_LOCK ctl and the
> >>segment is already locked the
Andrew Morton wrote:
> On Mon, 16 Jul 2007 16:24:12 +0400
> Pavel Emelianov <[EMAIL PROTECTED]> wrote:
>
>
>>When user locks an ipc shmem segmant with SHM_LOCK ctl and the
>>segment is already locked the shmem_lock() function returns 0.
>>After this the subsequent code leaks the existing user st
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> >mutex_lock(&container_mutex);
> >set_bit(CONT_RELEASABLE, &cont->flags);
> >- if (atomic_dec_and_test(&css->refcnt)) {
> >- check_for_release(cont);
> >- }
>
On Mon, Jul 16, 2007 at 07:35:01PM -0700, Paul (宝瑠) Menage wrote:
> On 7/16/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> >
> >- if (notify_on_release(cont)) {
> >+ if (atomic_dec_and_test(&css->refcnt) && notify_on_release(cont)) {
>
> This seems like a good idea, as long as atomic_de
37 matches
Mail list logo
