On 10/16/2017 09:24 AM, Oleg Nesterov wrote:
On 10/13, Konstantin Khlebnikov wrote:
On 13.10.2017 19:05, Oleg Nesterov wrote:
I won't insist, but this suggests we should add a new helper,
get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
as well.
That was in v3.
I'll pr
On 10/16/2017 02:36 PM, Andrew Morton wrote:
On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
wrote:
pid_t translate_pid(pid_t pid, int source, int target);
This syscall converts pid from source pid-ns into pid in target pid-ns.
If pid is unreachable from target pid-ns it returns z
:
On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
wrote:
On 10/16/17 5:52 PM, Andy Lutomirski wrote:
On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
wrote:
On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
On 10/16/2017 02:36 PM, Andrew
translate_pid(1, ns1, ns2) > 0 - is ns1 inside ns2?
translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
Signed-off-by: Konstantin Khlebnikov
Reanimated-by: Nagarathnam Muthusamy
---
v1: https://lkml.org/lkml/2015/9/15/411
v2: https://lkml
On 07/23/2018 01:55 PM, Michael Tirado wrote:
Hey, I'm not seeing much activity on this so here's my $0.02
Unix socket automatically translates pid attached to SCM_CREDENTIALS.
This requires CAP_SYS_ADMIN for sending arbitrary pids and entering
into pid namespace, this expose process and cou
root 0 Mar 1 15:55 uts -> uts:[4026531838]
Though there is a problem of ID being recycled in longterm, managing
an ID per namespace is easier than having open file descriptors per
pid namespace. Existing namespace inode numbers recycles faster and hence
their usability as ID for this API is less.
lem of ID being recycled in longterm, managing
an ID per namespace is easier than having open file descriptors per
pid namespace. Existing namespace inode numbers recycles faster and hence
their usability as ID for this API is less.
Signed-off-by: Nagarathnam Muthusamy
---
arch/x86/entry/syscalls/sysca
nging further reduces the
likelihood of the a cache line holding a pid reference count
ping-ponging between cpus.
Fixes: b488893a390e ("pid namespaces: changes to show virtual ids to user")
Signed-off-by: "Eric W. Biederman"
Thanks!
Reviewed-by: Nagarathnam Muthusam
also updates cat /proc/sysvipc/msg to return print msg_lspid
and msg_lrpid in the pid namespace of the process that opened the proc
file.
Fixes: b488893a390e ("pid namespaces: changes to show virtual ids to user")
Signed-off-by: "Eric W. Biederman"
Thanks!
Reviewed-
On 3/23/2018 2:33 PM, ebied...@xmission.com wrote:
NAGARATHNAM MUTHUSAMY writes:
Thanks!
Reviewed-by: Nagarathnam Muthusamy
Does this look like it will address the issue you have been fighting
with pids?
We do use IPC shared memory but it is a single large one, shared by multiple
(Resending the reply as there was a reject due to HTML in email)
On 03/14/2018 03:03 PM, ebied...@xmission.com wrote:
Nagarathnam Muthusamy writes:
On 03/13/2018 08:29 PM, ebied...@xmission.com wrote:
The cost of that ``cheaper'' u64 that is not in any namespace is that
you now
le descriptors per
pid namespace. Existing namespace inode numbers recycles faster and
hence
their usability as ID for this API is less.
Signed-off-by: Nagarathnam Muthusamy
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 2 +
fs/nsfs.c
On 03/13/2018 01:47 PM, Jann Horn wrote:
On Mon, Mar 12, 2018 at 10:18 AM, wrote:
Resending the RFC with participants of previous discussions
in the list.
Following patch which is a variation of a solution discussed
in https://lwn.net/Articles/736330/ provides the users of
pid namespace, th
On 03/13/2018 02:28 PM, Jann Horn wrote:
On Tue, Mar 13, 2018 at 2:20 PM, Nagarathnam Muthusamy
wrote:
On 03/13/2018 01:47 PM, Jann Horn wrote:
On Mon, Mar 12, 2018 at 10:18 AM,
wrote:
Resending the RFC with participants of previous discussions
in the list.
Following patch which is a
On 03/13/2018 03:00 PM, Jann Horn wrote:
On Tue, Mar 13, 2018 at 2:44 PM, Nagarathnam Muthusamy
wrote:
On 03/13/2018 02:28 PM, Jann Horn wrote:
On Tue, Mar 13, 2018 at 2:20 PM, Nagarathnam Muthusamy
wrote:
On 03/13/2018 01:47 PM, Jann Horn wrote:
On Mon, Mar 12, 2018 at 10:18 AM
On 03/13/2018 04:10 PM, Jann Horn wrote:
On Tue, Mar 13, 2018 at 3:45 PM, Nagarathnam Muthusamy
wrote:
On 03/13/2018 03:00 PM, Jann Horn wrote:
On Tue, Mar 13, 2018 at 2:44 PM, Nagarathnam Muthusamy
wrote:
On 03/13/2018 02:28 PM, Jann Horn wrote:
On Tue, Mar 13, 2018 at 2:20 PM
anslate_pid(1, ns1, ns2) > 0 - is ns1 inside ns2?
translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
Signed-off-by: Konstantin Khlebnikov
Reanimated-by: Nagarathnam Muthusamy
---
v1: https://lkml.org/lkml/2015/9/15/411
v2: https://lkml
On 05/15/2018 10:36 AM, Konstantin Khlebnikov wrote:
On 15.05.2018 20:19, Nagarathnam Muthusamy wrote:
On 04/24/2018 10:36 PM, Konstantin Khlebnikov wrote:
On 23.04.2018 20:37, Nagarathnam Muthusamy wrote:
On 04/05/2018 12:02 AM, Konstantin Khlebnikov wrote:
On 05.04.2018 01:29
On 5/31/2018 11:58 PM, Konstantin Khlebnikov wrote:
On Thu, May 31, 2018 at 9:05 PM, Eric W. Biederman
wrote:
Nagarathnam Muthusamy writes:
Ping? Any additional comments on this patch?
Konstantin's v5 no.
I am uncomfortable with unnecessary flexibility. I don't want to
translate_pid(1, ns1, ns2) > 0 - is ns1 inside ns2?
translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
Signed-off-by: Konstantin Khlebnikov
Reanimated-by: Nagarathnam Muthusamy
---
v1: https://lkml.org/lkml/2015/9/15/411
v2: https://lkml
From: Nagarathnam Muthusamy
Following commit disables the creation of user namespace inside
the chroot environment.
userns: Don't allow creation if the user is chrooted
commit 3151527ee007b73a0ebd296010f1c0454a919c7d
Consider a system in which a non-root user creates a combination
of
work on solving the issue with
pivot_root and mount namespace combination.
Thanks,
Nagarathnam.
Eric
nagarathnam.muthus...@oracle.com writes:
From: Nagarathnam Muthusamy
Following commit disables the creation of user namespace inside
the chroot environment.
userns: Don't allow cre
translate_pid(1, ns1, ns2) > 0 - is ns1 inside ns2?
translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
Signed-off-by: Konstantin Khlebnikov
Reanimated-by: Nagarathnam Muthusamy
---
v1: https://lkml.org/lkml/2015/9/15/411
v2: https://lkml
On 04/03/2018 02:38 PM, Andrew Morton wrote:
On Mon, 2 Apr 2018 15:57:29 -0600 nagarathnam.muthus...@oracle.com wrote:
pid_t translate_pid(pid_t pid, int source, int target);
This syscall converts pid from source pid-ns into pid in target pid-ns.
If pid is unreachable from target pid-ns it r
On 04/03/2018 02:52 PM, Andrew Morton wrote:
On Tue, 3 Apr 2018 14:45:28 -0700 Nagarathnam Muthusamy
wrote:
This changelog doesn't explain what the value is to our users. I
assume it is a performance optimization because "backward translation
requires scanning all tasks"?
On 04/04/2018 12:11 PM, Konstantin Khlebnikov wrote:
Each process have different pids, one for each pid namespace it belongs.
When interaction happens within single pid-ns translation isn't required.
More complicated scenarios needs special handling.
For example:
- reading pid-files or logs wr
irtual ids to user")
Reviewed-by: Nagarathnam Muthusamy
Signed-off-by: "Eric W. Biederman"
03f1fc0918 ipc/util: Helpers for making the sysvipc operations pid namespace
aware
98f929b1bd ipc/shm: Fix shmctl(..., IPC_STAT, ...) between pid namespaces.
0d79cbf83b ip
id and shm_lprid from the no_file
error cleanup path to the no_id error cleanup path. Ensuring that an
early error exit won't cause the oops above.
Reported-by: kernel test robot
Signed-off-by: Eric W. Biederman
Thanks!
Reviewed-by: Nagarathnam Muthusamy
---
ipc/shm.c | 4 ++--
1 file
On 03/28/2018 04:04 PM, ebied...@xmission.com wrote:
NAGARATHNAM MUTHUSAMY writes:
On 3/23/2018 2:33 PM, ebied...@xmission.com wrote:
NAGARATHNAM MUTHUSAMY writes:
Thanks!
Reviewed-by: Nagarathnam Muthusamy
Does this look like it will address the issue you have been fighting
with
On 04/24/2018 10:36 PM, Konstantin Khlebnikov wrote:
On 23.04.2018 20:37, Nagarathnam Muthusamy wrote:
On 04/05/2018 12:02 AM, Konstantin Khlebnikov wrote:
On 05.04.2018 01:29, Eric W. Biederman wrote:
Nagarathnam Muthusamy writes:
On 04/04/2018 12:11 PM, Konstantin Khlebnikov wrote
On 05/15/2018 10:36 AM, Konstantin Khlebnikov wrote:
On 15.05.2018 20:19, Nagarathnam Muthusamy wrote:
On 04/24/2018 10:36 PM, Konstantin Khlebnikov wrote:
On 23.04.2018 20:37, Nagarathnam Muthusamy wrote:
On 04/05/2018 12:02 AM, Konstantin Khlebnikov wrote:
On 05.04.2018 01:29, Eric
On 05/15/2018 10:40 AM, Nagarathnam Muthusamy wrote:
On 05/15/2018 10:36 AM, Konstantin Khlebnikov wrote:
On 15.05.2018 20:19, Nagarathnam Muthusamy wrote:
On 04/24/2018 10:36 PM, Konstantin Khlebnikov wrote:
On 23.04.2018 20:37, Nagarathnam Muthusamy wrote:
On 04/05/2018 12:02 AM
On 11/8/18 7:49 PM, Dmitry V. Levin wrote:
Hi,
On Mon, Jul 16, 2018 at 10:57:48AM -0700, Nagarathnam Muthusamy wrote:
On 06/01/2018 12:18 PM, Konstantin Khlebnikov wrote:
Each process have different pids, one for each pid namespace it belongs.
When interaction happens within single pid-ns
't pid-namespace
ESRCH- task not found in @source namespace
Signed-off-by: Konstantin Khlebnikov
Signed-off-by: Nagarathnam Muthusamy
---
v1: https://lkml.org/lkml/2015/9/15/411
v2: https://lkml.org/lkml/2015/9/24/278
* use namespace-fd as second/third argument
* add -pid for getting parent
On 04/05/2018 12:02 AM, Konstantin Khlebnikov wrote:
On 05.04.2018 01:29, Eric W. Biederman wrote:
Nagarathnam Muthusamy writes:
On 04/04/2018 12:11 PM, Konstantin Khlebnikov wrote:
Each process have different pids, one for each pid namespace it
belongs.
When interaction happens within
ng
there.
It sounds like you may be struggling with lifetime issues and when
to close/get rid of your pid namespace identifier. That could deserve
a conversation. Idenitifiers that are not namespaced are absolutely not
the solution.
Eric
Signed-off-by: Nagarathnam Muthusamy
---
arch/x86/en
36 matches
Mail list logo
