"Denis V. Lunev" <[EMAIL PROTECTED]> writes:
> Daniel Lezcano wrote:
>>> This place is a very tricky, indeed. If we keep the namespace until
>>> timewait bucket death - we'll keep the namespace alive at least 5
>>> _minutes_ after all process death.
>>
>> Yes, that's right. And for me that makes
Matt Mackall [EMAIL PROTECTED] wrote:
| On Wed, Sep 19, 2007 at 05:16:44PM -0700, [EMAIL PROTECTED] wrote:
| > Matt,
| >
| > The pid-namespace patcheset (http://lkml.org/lkml/2007/8/10/118)
| > was added to the -mm tree in 2.6.23-rc3-mm1.
| >
| > With CONFIG_CC_OPTIMIZE_FOR_SIZE=y this patchset i
Daniel Lezcano wrote:
>> This place is a very tricky, indeed. If we keep the namespace until
>> timewait bucket death - we'll keep the namespace alive at least 5
>> _minutes_ after all process death.
>
> Yes, that's right. And for me that makes totally sense. The namespace
> should not be destroye
On Thu, Sep 20, 2007 at 01:09:51PM +0400, Pavel Emelyanov wrote:
> J. Bruce Fields wrote:
> > On Tue, Sep 18, 2007 at 05:41:08PM +0400, Pavel Emelyanov wrote:
> >> This is the next step in fs/locks.c cleanup before turning
> >> it into using the struct pid *.
> >>
> >> This time I found, that ther
OK, this version I can't see any more problem with. Thanks!
--b.
On Thu, Sep 20, 2007 at 12:48:32PM +0400, Pavel Emelyanov wrote:
> This code is run under lock_kernel(), which is dropped during
> sleeping operations, so the following race is possible:
>
> CPU1:CP
Denis V. Lunev wrote:
Eric W. Biederman wrote:
Sockets need to get a reference to their network namespace,
or possibly a simple hold if someone registers on the network
namespace notifier and will free the sockets when the namespace
is going to be destroyed.
Signed-off-by: Eric W. Biederman <[E
Eric W. Biederman wrote:
> Sockets need to get a reference to their network namespace,
> or possibly a simple hold if someone registers on the network
> namespace notifier and will free the sockets when the namespace
> is going to be destroyed.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTE
From: Andrey Mirkin <[EMAIL PROTECTED]>
Right now register edi is just cleared before calling do_exit.
That is wrong because correct return value will be ignored.
Value from rax should be copied to rdi instead of clearing edi.
Signed-off-by: Andrey Mirkin <[EMAIL PROTECTED]>
-
diff --git a/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> + case PR_GET_CAPBSET:
> + error = put_user(current->cap_bset, (unsigned long
> __user *)arg2);
> + break;
> + case PR_SET_CAPBSET:
> + if (!c
On Tue, 18 Sep 2007, J. Bruce Fields wrote:
> On Tue, Sep 18, 2007 at 12:54:56PM -0400, Trond Myklebust wrote:
> >
> > It gets even better when you throw mmap() into the mix :-)
>
> Hm. Documentation/mandatory.txt claims that it mandatory locks and
> mmap() with MAP_SHARED exclude each other, bu
Paul Jackson wrote:
>>> functions are used in process creation/termination, we would need to
>>> keep them inline, when optimizing for performance.
>> I'd keep them inline for performance reasons.
>
> As Matt Mackall explained more carefully in his reply, it's no longer
> clear that inlining is be
Hello, Eric!
Current locking in mainstream seems broken to me.
1. struct net->list is manipulated under double net_mutex/net_list_mutex
2. net_list_mutex has been taken only in cleanup_net/net_ns_init inside
net_mutes and seems pointless now
3. for_each_net (iterating against net_namespace_list)
> > functions are used in process creation/termination, we would need to
> > keep them inline, when optimizing for performance.
>
> I'd keep them inline for performance reasons.
As Matt Mackall explained more carefully in his reply, it's no longer
clear that inlining is best for performance in as
[EMAIL PROTECTED] wrote:
> Matt,
>
> The pid-namespace patcheset (http://lkml.org/lkml/2007/8/10/118)
> was added to the -mm tree in 2.6.23-rc3-mm1.
>
> With CONFIG_CC_OPTIMIZE_FOR_SIZE=y this patchset increases the kernel
> text size by about 5K (closer to 6K when the config token is set to N).
J. Bruce Fields wrote:
> On Tue, Sep 18, 2007 at 05:41:08PM +0400, Pavel Emelyanov wrote:
>> This is the next step in fs/locks.c cleanup before turning
>> it into using the struct pid *.
>>
>> This time I found, that there are some places that do a
>> similar thing - they try to apply a lock on a
This code is run under lock_kernel(), which is dropped during
sleeping operations, so the following race is possible:
CPU1:CPU2:
vfs_setlease();vfs_setlease();
lock_kernel();
lock_kernel(); /* spin */
ge
Pavel Emelyanov wrote:
> Currently /proc/locks is shown with a proc_read function, but
> its behavior is rather complex as it has to manually handle
> current offset and buffer length. On the other hand, files
> that show objects from lists can be easily reimplemented using
> the sequential files
Currently /proc/locks is shown with a proc_read function, but
its behavior is rather complex as it has to manually handle
current offset and buffer length. On the other hand, files
that show objects from lists can be easily reimplemented using
the sequential files and the seq_list_XXX() helpers.
J. Bruce Fields wrote:
> On Wed, Sep 19, 2007 at 06:26:05PM +0400, Pavel Emelyanov wrote:
>> This code is run under lock_kernel(), which is dropped during
>> sleeping operations, so the following race is possible:
>>
>> CPU1:CPU2:
>> vfs_setlease();
J. Bruce Fields wrote:
> On Wed, Sep 19, 2007 at 03:35:27PM +0400, Pavel Emelyanov wrote:
>> Currently /proc/locks is shown with a proc_read function, but
>> its behavior is rather complex as it has to manually handle
>> current offset and buffer length. On the other hand, files
>> that show objec
20 matches
Mail list logo
