the problem and gotten
a patch in.
This patch works because pid_vnr returns 0 for processes outside of
the current pid namespace.
> This patch uses the simple fix suggested by Oleg Nesterov.
>
> Signed-off-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
Acked-by: "Eric W. Biederm
Benjamin Thery <[EMAIL PROTECTED]> writes:
> Support for network namespaces in mainline is pretty complete for
> some time now, but there is still this issue with sysfs that prevents
> more people to use it easily.
Ben your patchset is completely inappropriate.
Temporarily adding elements to th
make it next to
impossible to boot without sysfs should at be able to
boot a test kernel now.
Plus no ABIs are harmed with this patch.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/Kconfig |2 +-
net/core/dev.c | 12 +++-
net/core/net-sys
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>> Benjamin Thery <[EMAIL PROTECTED]> writes:
>>
>> > Support for network namespaces in mainline is pretty complete for
>> > some time now,
Greg KH <[EMAIL PROTECTED]> writes:
> On Wed, Oct 22, 2008 at 05:21:44PM +0200, Benjamin Thery wrote:
>> Network devices from sub-network namespaces appear in sysfs
>> with a name that looks like this: [EMAIL PROTECTED]
>> eg: [EMAIL PROTECTED], [EMAIL PROTECTED]
>
> How does the default udev rule
Stephen Hemminger <[EMAIL PROTECTED]> writes:
>> The well-known user space tools don't use /sys at all. Modern
>> network tools use rtnetlink (ip) old network tools use /proc/net.
>>
>> Very few things actually use /sys and for those things [EMAIL PROTECTED] or
>> [EMAIL PROTECTED] are completel
Benjamin Thery <[EMAIL PROTECTED]> writes:
> Serge E. Hallyn wrote:
>> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>>> To make testing of the network namespace simpler allow
>>> the network namespace code and the sysfs code to be
>>> compiled
Benjamin Thery <[EMAIL PROTECTED]> writes:
> In fact, I feared that would be an issue before I sent the patches.
> Thanks for confirming this.
>
> But, as this alternative was discussed a bit after Al's comments on your
> last patches, I had to give it a try and code a proof-of-concept.
Yes. We
jamin Thery it only makes sense to call
device_rename in the initial network namespace for now.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Acked-by: Benjamin Thery <[EMAIL PROTECTED]>
Tested-by: Serge Hallyn <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PR
David Miller <[EMAIL PROTECTED]> writes:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Thu, 23 Oct 2008 08:56:08 -0700
>
>> To make testing of the network namespace simpler allow
>> the network namespace code and the sysfs code to be
>> compiled and run a
> + case SO_NSID:
> + if (!capable(CAP_NET_ADMIN)) {
> + ret = -EPERM;
> + } else {
> + struct net *old_net, *new_net;
> +
> + ret = -EINVAL;
> + new_net = get_net_ns_by_id(val);
> +
Dave Hansen <[EMAIL PROTECTED]> writes:
> I hate the syscall. It's a very un-Linux-y way of doing things. There,
> I said it. Here's an alternative. It still uses the syscall to
> initiate things, but it uses debugfs to transport the data instead.
> This is just a concept demonstration. It do
Dave Hansen <[EMAIL PROTECTED]> writes:
> On Thu, 2008-10-30 at 16:33 -0700, Eric W. Biederman wrote:
>> If you called it a core dump instead of a checkpoint you have exactly the
>> same
> set
>> of issues.
>
> I completely agree with you that there
Vivien Chappelier <[EMAIL PROTECTED]> writes:
> To bring back the discussion you had with Eric W. Biederman, it seems to
> me that the only real issue is on the addition of the global nsid index
> that is not really fit to be used hierarchically. However, I don't
> und
Andreas B Aaen <[EMAIL PROTECTED]> writes:
> On Friday 31 October 2008 00:07, Eric W. Biederman wrote:
> Ok. Here is my use case.
> I need a to talk to 500 IPv4 networks with possible overlapping IP addresses.
> The packages arrive on 500 VLANs. I want one process to listen to
Thinking it over a little more I have the following thought.
For binding a socket to a namespace let's use the a fd arg.
That way we can either supply another existing network socket
or the result of an open call. Simple, and faster if you
are creating more than one socket in the other network n
Daniel Lezcano <[EMAIL PROTECTED]> writes:
> Andreas B Aaen wrote:
>> Ok. Here is my use case.
>> I need a to talk to 500 IPv4 networks with possible overlapping IP
>> addresses. The packages arrive on 500 VLANs. I want one process to listen to
>> a
>> port on each of these networks. I don't wan
Dave Hansen <[EMAIL PROTECTED]> writes:
>> I was thinking about restore. Creating objects with a certain id can
>> easily be a security risk if you are not creating the namespace those
>> objects live in at the same time. There is currently the downside
>> that we can't create namespaces as unpr
Daniel Lezcano <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Thinking it over a little more I have the following thought.
>>
>> For binding a socket to a namespace let's use the a fd arg.
>> That way we can either supply another existing network s
Daniel Lezcano <[EMAIL PROTECTED]> writes:
> This patch adds the socketat syscall which allows to specify in
> which network namespace we want to create a socket. The network
> namespace destination is referred by a socket fd previously opened
> in the destination network namespace.
Looks good an
ked-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/core/dev.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8f9d3b3..9475f3e 100644
--- a/net/core/dev.c
+++ b/net/cor
earlier thinko and add the needed kfree_skb and everything
cleans up beautifully.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/core/dev.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 811507c..a0c6060 100644
directly from net_dev_init().This guarantes
that the loopback device is the first device registered and
the last network device to go away.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
drivers/net/loopback.c| 13 ++---
include/linux/netdevice.h |1 +
net/core
entries in proc
got inverted and generally broken for threads, and frankly
all it saved was a single d_hash_and_lookup so there was
very little point to it. So remove the check and keep
the code stupid and correct.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/proc/
Dave can you please drop this one for the moment.
I cleaned up my patch after the basic testing was over and the
result is a kernel that won't boot. So if we can prevent this
patch from spreading and breaking a git-bisect that would be great.
I will follow up in a moment with a properly tested
Since the network namespace is recorded in the
superblock we don't need to remember it on
each directory under /proc/net.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/proc/generic.c | 17 -
fs/proc/proc_net.c | 13 ++---
in
This is accomplished by dropping the /proc//net
dentry when we discover an older version of /proc/net
is mounted upon it. This prevents new lookups from
using the mount and ultimately proc_shrink_automounts
will catch up with it and remove the old mount point.
Signed-off-by: Eric W. Biederman
esn't need to care about it.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/proc/base.c |6 +-
fs/proc/proc_net.c | 212 +++
include/linux/magic.h |1 +
include/net/net_namespace.h |1 +
- Implement proc_create_root to create a generic root directory.
- Factor out release_proc_entry so that we can free a generic root directory.
- Remove static from proc_sops so that we can access it in other files
implementing a proc generic filesystem.
Signed-off-by: Eric W. Biederman <[EM
This is a genearl mechanism that is capable of removing
any unused mounts on /proc in any directory. As we flush
the mounts when a processes dies this mechanism is tailored
for flushing mounts in the per task and per task group
directories.
Signed-off-by: Eric W. Biederman <[EMAIL PROTEC
.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/namespace.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index cce4670..65b3dc8 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1815,8 +1815,8 @@ stati
We need to setup the network namespace state before we register
the notifier. Otherwise if a network device is already registered
we get a nasty NULL pointer dereference.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/core/fib_rules.c |7 ---
1 files changed, 4 inse
directly from net_dev_init().This guarantes
that the loopback device is the first device registered and
the last network device to go away.
But do it carefully so we register the loopback device after
we clear dev_boot_phase.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
drive
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Thu, 06 Nov 2008 02:48:35 -0800
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
>> This is a genearl mechanism that is capable of removing
>> any unused mounts on /proc in any directory. As we flush
>> the
Andrew Morton <[EMAIL PROTECTED]> writes:
> OK, so that's a for-2.6.28 bugfix, yes?
>
> The other six patches will fall under Alexey's procfs tree.
Fundamentally they are all bug fixes, but whatever works.
Eric
___
Containers mailing list
[EMAIL PROTE
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Thu, 06 Nov 2008 02:48:35 -0800
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
>> +void proc_shrink_automounts(void)
>> +{
>> +struct list_head *list = &proc_automounts;
>> +
>> +mark_mounts
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Thu, 06 Nov 2008 18:05:46 -0800 [EMAIL PROTECTED] (Eric W. Biederman)
> wrote:
>
>> Andrew Morton <[EMAIL PROTECTED]> writes:
>>
>> > On Thu, 06 Nov 2008 02:48:35 -0800
>> > [EMAIL PRO
mental patch.
Oops. I forgot to account for the rare but possible
case of someone not compiling procfs into their kernel.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
include/linux/proc_fs.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linu
Daniel Lezcano <[EMAIL PROTECTED]> writes:
> AFAIU, the Eric's proposal in case a new syscall was not accepted. IMHO a new
> syscall, with the man pages is better than adding an extra obscure argument
> to a
> well known API. But if there is a reason to not add a new syscall, we can
> consider E
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Thu, 06 Nov 2008 19:51:23 -0800 [EMAIL PROTECTED] (Eric W. Biederman)
> wrote:
>
>> If we could do all of this with reference counting so that the
>> mount would persist exactly until the last user of it has gone
>&g
Andrew Morton <[EMAIL PROTECTED]> writes:
> I was thinking more along the lines of some repeated operation which
> generates reclaimable storage, only nothing reclaims that storage
> sufficiently promptly (the 500 second delay, perhaps).
>
> Like the problem we had with SLAB_DESTROY_BY_RCU and, um
David Miller <[EMAIL PROTECTED]> writes:
> I'm putting a revert changeset in there, then your two new patches on
> top.
>
> I'm not screwing up my GIT tree for everyone who pulls from me just
> because you can't be bothered to test the actual changes you send me.
Understood. When I sent the emai
Vivien Chappelier <[EMAIL PROTECTED]> writes:
> Hi,
>
> The socketat() option is fine but only solves half of the problem. I also
> need
> to be able to change the default namespace of a process to join an existing
> network namespace.
I'm trying to get a feel. What kind of applications do yo
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 11/11, Sukadev Bhattiprolu wrote:
>>
>> Subject: [PATCH 3/3] sig: Handle pid namespace crossing when sending signals.
>
>> I add a struct pid sender parameter to __group_send_sig_info, as that is
>> the only function called with si_pid != task_tgid_vn
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 11/11, Sukadev Bhattiprolu wrote:
>>
>> Subject: [PATCH 3/3] sig: Handle pid namespace crossing when sending signals.
>
>> I add a struct pid sender parameter to __group_send_sig_info, as that is
>> the only function called with si_pid != task_tgid_vn
On this patchset it looks like the conversation has wound down with no
real objects except that some very simple pieces of the code appear
magic.
What looks to be the best path for getting this set of patches merged
into /proc?
Alexy will you pick this up in your /proc tree as Andrew suggested?
Alexey Dobriyan <[EMAIL PROTECTED]> writes:
> OK, I fixed some small issues and pushed out to proc.git so it starts
> propagate to -next.
Thanks.
Eric
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/co
nders at this point. As those devices should
not even be in sysfs at the moment. But it keeps us from doing the
wrong thing when sysfs support starts coming on line.
Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
> Signed-off-by: Daniel Lezcano <[EMAIL PROTECTED]>
> -
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Tue, 25 Nov 2008, Dave Hansen wrote:
>> >
>> > I think the end result was, if this file can only be changed by root, then
>> > we do not need to worry about namespaces. This file is a privileged file
>> > that can only be modified by root.
>> >
>
Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Tue, 25 Nov 2008, Eric W. Biederman wrote:
>
>>
>>
>
> I'm speechless too.
I'm a bit tired so probably am pushing to hard.
At the same time I don't see a single reason not to use
struct pid for
Steven Rostedt <[EMAIL PROTECTED]> writes:
> From: Steven Rostedt <[EMAIL PROTECTED]>
>
> Impact: feature to function trace a single thread
>
> This patch adds the ability to function trace a single thread.
> The file:
>
> /debugfs/tracing/set_ftrace_pid
>
> contains the pid to trace. Valid pids
Ingo Molnar <[EMAIL PROTECTED]> writes:
> i dont see the point of the complexity you are advocating. 99.9% of
> the users run a unique PID space.
I'm not advocating complexity. I'm advocating using the same APIs as
the rest of the kernel, for doing the same functions.
> Tracing is about keepin
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> Ingo Molnar <[EMAIL PROTECTED]> writes:
>>
>> > i dont see the point of the complexity you are advocating. 99.9% of
>> > the users run a unique
Steven Rostedt <[EMAIL PROTECTED]> writes:
> From: Steven Rostedt <[EMAIL PROTECTED]>
>
> Impact: clean up
>
> Use the new task struct trace flags to determine if a process should be
> traced or not.
Looks reasonable.
> Note: this moves the searching of the pid to the slow path of setting
> the
Steven Rostedt <[EMAIL PROTECTED]> writes:
>> > # echo $$ > /debugfs/tracing/set_ftrace_pid
>> > # echo function_graph > /debugfs/tracing/current_tracer
>> >
>> > Will cause only the current task to be traced. Note, the trace flags are
>> > also inherited by child processes, so the children of
Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Wed, 3 Dec 2008, Eric W. Biederman wrote:
>
>> Steven Rostedt <[EMAIL PROTECTED]> writes:
>>
>> The way patch 2 uses pids is just stupid. It has nothing to do with
>> pids aren't unique. You do a fu
Steven Rostedt <[EMAIL PROTECTED]> writes:
> From: Steven Rostedt <[EMAIL PROTECTED]>
>
> Impact: clean up
>
> Eric Biederman suggested using the struct pid for filtering on
> pids in the kernel. This patch is based off of a demonstration
> of an implementation that Eric sent me in an email.
A li
Steven Rostedt <[EMAIL PROTECTED]> writes:
> From: Steven Rostedt <[EMAIL PROTECTED]>
>
> Impact: New feature
>
> This patch lets the swapper tasks of all CPUS be filtered by the
> set_ftrace_pid file.
>
> If '0' is echoed into this file, then all the idle tasks (aka swapper)
> is flagged to be tr
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>> > Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
>>
>> What does this patch actually do? Is swapper currently excluded from
>> tracing for undisclosed reasons and this patch permits it to be traced?
>>
Steven Rostedt <[EMAIL PROTECTED]> writes:
> From: Steven Rostedt <[EMAIL PROTECTED]>
>
> Impact: clean up
>
> Eric Biederman suggested using the struct pid for filtering on
> pids in the kernel. This patch is based off of a demonstration
> of an implementation that Eric sent me in an email.
Plea
Dave Hansen <[EMAIL PROTECTED]> writes:
> On Thu, 2008-12-04 at 04:56 -0800, Dave Hansen wrote:
>> On Thu, 2008-12-04 at 04:42 -0800, Eric W. Biederman wrote:
>> >
>> > > +static void clear_ftrace_pid_task(struct pid **pid)
>>
Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Thu, 4 Dec 2008, Andrew Morton wrote:
>
>> On Thu, 04 Dec 2008 00:26:41 -0500 Steven Rostedt <[EMAIL PROTECTED]> wrote:
>>
>> > From: Steven Rostedt <[EMAIL PROTECTED]>
>> >
>> > Impact: New feature
>> >
>> > This patch lets the swapper tasks of a
Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Thu, 4 Dec 2008, Eric W. Biederman wrote:
>
>> Steven Rostedt <[EMAIL PROTECTED]> writes:
>>
>> > From: Steven Rostedt <[EMAIL PROTECTED]>
>> >
>> > Impact: clean up
>> >
>&
Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Thu, 4 Dec 2008, Eric W. Biederman wrote:
>
>> Ingo Molnar <[EMAIL PROTECTED]> writes:
>>
>> > * Andrew Morton <[EMAIL PROTECTED]> wrote:
>> >
>> >> > Signed-off-by: Steven Rost
Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Thu, 4 Dec 2008, Eric W. Biederman wrote:
>> >> >
>> >> >> > +static struct pid * const ftrace_swapper_pid = (struct pid *)1;
>> >> >>
>> >> >> eh?
>&
Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Thu, 4 Dec 2008, Eric W. Biederman wrote:
>>
>> Right. I simply meant most of the
>> if (likely(p->pid)) conditional except for the counts is pretty much a don't
>> care. Keeping the idle tasks off of the
Steven Rostedt <[EMAIL PROTECTED]> writes:
> Other pids get allocated per task. In the beginning of copy_process we
> have:
>
> if (pid != &init_struct_pid) {
> retval = -ENOMEM;
> pid = alloc_pid(task_active_pid_ns(p));
>
> Where alloc_pid allocates a pid
Andrew Morton writes:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 11 Dec 2008 08:16:55 -0800 (PST) bugme-dae...@bugzilla.kernel.org
> wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=12199
>>
>>Summary: /pr
robert@exasol.com writes:
> Thanks for your analysis! That sounds reasonable (I didn't recognize the use
> of
> CLONE_NEWNS - just pasting from the examples ;-) - but I needed it to mount a
> proc filesystem in the new PID namespace while using the other one
> "outside"). So, I may not count
Sukadev Bhattiprolu writes:
> The obvious trade-off is with systems that don't use containers which
> are porbably the majority at present. For them next_task() now becomes
> more expensive (instead of a simply going to next item on list, they have
> lookup in the pidmap, a lookup in pid hash ta
Gowrishankar M writes:
> Below patch addresses a common solution for any place where a process
> should be checked if it is associated to caller namespace. At present,
> we use 'task_pid_vnr(t) > 0' to further proceed with task 't' in current
> namespace.
>
> To avoid applying this check in every
processes in current namespace are scanned
Yes. This case in capability.c needs to be fixed.
Acked-by: "Eric W. Biederman"
> Signed-off-by: Gowrishankar M
> ---
> kernel/capability.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/
Gowrishankar M
Nacked-by: "Eric W. Biederman"
sysrq is a debugging helper and send_sig_all should apply to
ever process in the system. It should only apply to the initial
pid namespace.
Attempting to make it namespace aware is wrong.
Eric
__
Gowrishankar M writes:
> From: Gowrishankar M
>
> Below patch addresses a common solution for any place where a process
> should be checked if it is associated to caller namespace. At present,
> we use 'task_pid_vnr(t) > 0' to further proceed with task 't' in current
> namespace.
>
> To avoid ap
oses to use new macro controller to fix the boundary of
> processes list in current namespace.
Nacked-by: "Eric W. Biederman"
This has nothing to do with pids. The command is to set the
iopriority for a given user. This is a problem of the user names
"Serge E. Hallyn" writes:
> Quoting Gowrishankar M (gowrishanka...@linux.vnet.ibm.com):
>> From: Gowrishankar M
>>
>> At present we scan all processes in init namespace, while getting or setting
>> process priorities for a user. Incase of PID namespace, it leads to leak
>> priority to processes
"Serge E. Hallyn" writes:
> The uid check needs to be fixed for user namespaces, agreed. I could
> go either way though on whether we should also restrict to the same
> pidns.
It would be a subtle unexpected semantic change, that we would need
to copy linux-abi and document etc. I'm not convi
David Howells writes:
> Serge E. Hallyn wrote:
>
>> Yup - patch coming (probably next week) for that,
>
> Thanks.
>
>> but there's the question, given that user namespaces are hierarchical, of
>> whether, if pidns B is a child of pidns A created by userid 500, a task in
>> pidns A should see key
Sukadev Bhattiprolu writes:
> This patchset implements the design/simplified semantics suggested by
> Oleg Nesterov. The simplified semantics for container-init are:
>
> - container-init must never be terminated by a signal from a
> descendant process.
>
> - container-init mu
Sukadev Bhattiprolu writes:
> Eric W. Biederman [ebied...@xmission.com] wrote:
>
> |
> | - container-init is responsible for setting the rest of the signals
> | to SIG_IGN.
>
> Oleg pointed out that we could drop SIG_DFL signals to global init early
> to ensure wait
Oleg Nesterov writes:
>> I was going through the ->si_pid assignments to try and fix them at
>> source (like the mqueue patch I sent last week).
>
> OK.
Note. When a signal goes to a process group (or similar) we can't fix
si_pid at the source. We have to fix it when only a single destination
Christoph Hellwig writes:
> On Tue, Jan 06, 2009 at 02:32:41AM +0300, Alexey Dobriyan wrote:
>> This is current version of /proc/net as separate file system patchset,
>> rebased, etc. I'll put it into -next again when merge window closes.
>
> I still don't see the point for that. Why not /proc/n
"Serge E. Hallyn" writes:
> Quoting Trond Myklebust (trond.mykleb...@fys.uio.no):
>> On Tue, 2009-01-06 at 14:02 -0600, Serge E. Hallyn wrote:
>> > Quoting Matt Helsley (matth...@us.ibm.com):
>> > > We can often specify the UTS namespace to use when starting an RPC
>> > > client.
>> > > However
d Myklebust wrote:
>> > > > On Tue, 2009-01-06 at 15:04 -0800, Eric W. Biederman wrote:
>> > > > > That implies to me you want to capture the value at mount time, and
>> > > > > to
>> > > > > pass it in to the rpc_call creation, a
"J. Bruce Fields" writes:
> If people seem to think they can do live process and container
> migration:
>
> http://ols.fedoraproject.org/OLS/Reprints-2008/mirkin-reprint.pdf
>
> then moving the NFS state strikes me as not the greatest of their
> troubles.
>
> I'm not volunteering!
Reasonab
Daniel Lezcano writes:
> ch...@versecorp.net wrote:
>> On Wed, Jan 14, 2009 at 09:50:29AM +0100, Daniel Lezcano wrote:
>>
>>> Guenter Roeck wrote:
>>>
As far as I recall, if you have sysfs active and use the sysfs patch to
let you configure both sysfs and network namespaces, you can onl
Guenter Roeck writes:
> There are two key elements affecting performance when creating large
> numbers of interfaces:
> - full_name_hash() doesn't do a good job in selecting hash buckets
> - sysfs uses a linked list to store directory entries, and strcmp() to
> compare entries.
>
> The sysfs prob
"Chris R. Jones" writes:
> On Thu, Jan 15, 2009 at 11:21:43PM +0100, Daniel Lezcano wrote:
>> ch...@versecorp.net wrote:
>> >>Did you tried with the macvlan ?
>> >>
>> >
>> >I just tried it - and it does work - I can move the vlan interfaces into
>> >the
>> >namespace. But that's not a sol
KAMEZAWA Hiroyuki writes:
> What makes me confused is "Container". There is no "Container" in
> the linux kernel, just cgroup and its subsyss.
> (Some source codes still use "cont" but new codes all use "cgroup" or "cgrp" )
>
> So, I asked whether "Container" means "Namespace subsys" or something
Daniel Lezcano writes:
>
> Hmm, at the first glance I would say it is useless but perhaps there is a
> trick
> here I do not understand.
> Eric, is there any particular reason to call synchronize_net before exiting
> the
> dev_change_net_namespace function ?
I haven't thought about that part of
Daniel Lezcano writes:
> Eric W. Biederman wrote:
>> Daniel Lezcano writes:
>>
>>> Hmm, at the first glance I would say it is useless but perhaps there is a
> trick
>>> here I do not understand.
>>> Eric, is there any particular reason
Sukadev Bhattiprolu writes:
> From: Sukadev Bhattiprolu
> Date: Wed, 24 Dec 2008 14:14:18 -0800
> Subject: [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing pid ns
> boundary
>
> When sending a signal to a descendant namespace, set ->si_pid to 0 since
> the sender does not have a pid in t
Oleg Nesterov writes:
> On 02/19, Eric W. Biederman wrote:
>>
>> Sukadev Bhattiprolu writes:
>>
>> > From: Sukadev Bhattiprolu
>> > Date: Wed, 24 Dec 2008 14:14:18 -0800
>> > Subject: [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing pid
"H. Peter Anvin" writes:
> Daniel Lezcano wrote:
>>>
>>> Resource limit partitioning is a much bigger and orthogonal problem.
>>>
>> In this case we don't have the pty allocated independently, no ?
>> I mean one container can allocate 4095 pty, making a pty starvation for
>> others
>> contain
Oleg Nesterov writes:
> On 02/19, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>> >
>> > SI_FROMUSER() == T, unless we have more (hopefully not) in-kernel
>> > users which send SI_FROMUSER() signals, .si_pid must be valid?
>>
Daniel Lezcano writes:
> But if I am able to create a new instance of devpts for a container and modify
> the configuration of another devpts from this container, is it acceptable ?
> Can
> we convince people to use the containers for security and have anybody able to
> make a pty starvation fro
Roland McGrath writes:
>> Suppose I have 3 processes in a process group in three separate pid
>> namespaces.
>>
>> Looking from the init pid namespace I have:
>> pid pgrp ppid
>> 10 101
>> 11 1010
>> 12 1011
>>
>> Looking from the pid namespace of pid 11 I hav
Roland McGrath writes:
>> It is especially useful, and this is a deliberate feature.
>
> Ok, I thought that might be so.
>
>> In practice I don't care about si_pid and I doubt I care about processes
>> sending signals outside of their pid namespace. But I do care about
>> sharing a tty and a s
Roland McGrath writes:
>> > think it would be best to fully elucidate what we think about desireable
>> > semantics for the whole spectrum of cross-NS signal-sending cases before
>> > actually choosing the implementation details.
>
> ... and then you answered all the questions that are already we
1 - 100 of 1332 matches
Mail list logo
