Commit-ID: a237f762681e2a394ca67f21df2feb2b76a3609b
Gitweb: https://git.kernel.org/tip/a237f762681e2a394ca67f21df2feb2b76a3609b
Author: W. Trevor King
AuthorDate: Fri, 12 Jan 2018 15:24:59 -0800
Committer: Thomas Gleixner
CommitDate: Sun, 14 Jan 2018 11:42:10 +0100
security/Kconfig
On Fri, Jan 12, 2018 at 05:19:32PM -0800, Dave Hansen wrote:
> On 01/12/2018 03:24 PM, W. Trevor King wrote:
> >> If you're going to patch this, please send an update to -tip that
> >> corrects the filename.
> >
> > Here you go :).
>
> Feel fr
The reference landed with the config option in 385ce0ea (x86/mm/pti:
Add Kconfig, 2017-12-04), but the referenced file was not committed
then. It eventually landed in 01c9b17b (x86/Documentation: Add PTI
description, 2018-01-05) as pti.txt.
Signed-off-by: W. Trevor King
---
On Fri, Jan 12, 2018
The reference landed with the config option in 385ce0ea (x86/mm/pti:
Add Kconfig, 2017-12-04), but the referenced file was never committed.
Signed-off-by: W. Trevor King
---
security/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/security/Kconfig b/security/Kconfig
index
On Tue, Jan 17, 2017 at 02:03:29PM +1300, Michael Kerrisk (man-pages) wrote:
> + case NS_GET_OWNER_UID:
> + if (ns->ops->type != CLONE_NEWUSER)
> + return -EINVAL;
> + user_ns = container_of(ns, struct user_namespace, ns);
> + argp = (unsi
On Fri, Jan 13, 2017 at 10:27:42AM -0700, Jonathan Corbet wrote:
> > -if a task's pid is written to another cpusets 'cpuset.tasks' file, then its
> > +if a task's pid is written to another cpuset's 'tasks' file, then its
>
> So I'll confess that I don't understand this change. All of the
> contro
This looks like it was accidentally caught up in e21a05cb (doc:
cpuset: Update the cpuset flag file, 2010-02-24).
While I'm touching the line, also fix the posessive "cpusets" ->
"cpuset's".
Signed-off-by: W. Trevor King
---
Documentation/cgroup-v1/cpus
On Tue, Jul 26, 2016 at 11:25:24AM -0700, Andrew Vagin wrote:
> Sure. If a process wants to compare two namespaces, it needs to get file
> descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
> process which has them),
> and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
On Sun, Jul 24, 2016 at 09:30:03AM -0500, Eric W. Biederman wrote:
> I am not at all certain it makes sense to return -ENOENT.
>
> Without the -ENOENT check the code is much cleaner, and clearer.
This is fine with me, and makes even more sense for owner (user)
namespaces than it does for net name
On Thu, Jul 14, 2016 at 07:12:19PM -0700, Andrey Vagin wrote:
> +struct ns_common *ns_get_owner(struct ns_common *ns)
> +{
> + …
> + return &get_user_ns(user_ns)->ns;
> +}
Is there a reason to return the generic ‘struct ns_common *’ here
instead of ‘struct user_namespace *’? The current u
On Sat, Jul 23, 2016 at 04:56:44PM -0500, Eric W. Biederman wrote:
> "W. Trevor King" writes:
> > On Sat, Jul 23, 2016 at 02:38:56PM -0700, James Bottomley wrote:
> >> On Sat, 2016-07-23 at 14:14 -0700, W. Trevor King wrote:
> >> > namespaces(7) and clo
On Sat, Jul 23, 2016 at 02:38:56PM -0700, James Bottomley wrote:
> On Sat, 2016-07-23 at 14:14 -0700, W. Trevor King wrote:
> > namespaces(7) and clone(2) both have:
> >
> > When a network namespace is freed (i.e., when the last process
> > in the namespace termin
On Thu, Jul 14, 2016 at 11:20:14AM -0700, Andrey Vagin wrote:
> Pid and user namepaces are hierarchical. There is no way to discover
> parent-child relationships too.
It bothers me that network namespaces are not hierarchical too ;).
namespaces(7) and clone(2) both have:
When a network namespac
On Thu, Jul 14, 2016 at 11:20:16AM -0700, Andrey Vagin wrote:
> +struct ns_common *ns_get_owner(struct ns_common *ns)
> +{
> + const struct cred *cred = current_cred();
> + struct user_namespace *user_ns, *p;
> +
> + user_ns = p = ns->user_ns;
> + if (user_ns == NULL) { /* ns is ini
On Thu, Jul 14, 2016 at 11:20:17AM -0700, Andrey Vagin wrote:
> +int open_related_ns(struct ns_common *ns,
> +struct ns_common *(*get_ns)(struct ns_common *ns))
> +{
> + struct path path = {};
> + struct file *f;
> + void *err;
> + int fd;
> +
> + fd = get_unuse
On Tue, Jul 12, 2016 at 05:08:43PM -0700, Andrew Vagin wrote:
> Here is a patch to get an owning user namespace:
> https://github.com/avagin/linux-task-diag/commit/7fad8ff3fc4110bebf0920cec2388390b3bd2238
> https://github.com/avagin/linux-task-diag/commit/2663bc803d324785e328261f3c07a0fef37d2088
>
On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley wrote:
> In theory, we could get nsfs to show this information as an option
> (just add a show_options entry to the superblock ops), but the
> problem is that although each namespace has a parent user_ns,
> there's no way to get it without d
On Fri, Jul 08, 2016 at 01:38:19PM -0700, Andrew Vagin wrote:
> What do you think about the idea to mount nsfs and be able to look up
> any alive namespace by inum:
>
> $ tree .
> .
> ├── mnt{inum}
> │ └── user -> ../user{inum}
> ├── pid{inum}
> │ ├── pid{inum}
> │ │ └── user
On Thu, Jul 07, 2016 at 11:54:54PM -0700, Andrew Vagin wrote:
> On Thu, Jul 07, 2016 at 10:26:50PM -0700, W. Trevor King wrote:
> > On Thu, Jul 07, 2016 at 08:26:47PM -0700, James Bottomley wrote:
> > > On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
> > > >
On Thu, Jul 07, 2016 at 10:26:50PM -0700, W. Trevor King wrote:
> And if you want to put that whole ancestor tree in fdinfo, you have
> to come up with some way to handle the two-parent branching.
Going towards the roots is nice, because you know a given namespace
will only have two parent
On Thu, Jul 07, 2016 at 08:26:47PM -0700, James Bottomley wrote:
> On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
> > On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
> > > I think we can show all required information in fdinfo. We open
> > > a namespaces file (/proc/pid/ns/N)
I'm just chipping in from the peanut gallery, so sorry if this misses
some earlier discussion.
On Fri, May 20, 2016 at 12:53:26PM -0400, Tejun Heo wrote:
> Why does an unpriv NS need to have cgroup delegated to it without
> cooperation from cgroup manager? If for resource control, I'm
> pretty su
This should have happened in 6255c46f (cgroup: rename cgroup
documentations, 2016-01-11).
Signed-off-by: W. Trevor King
---
Documentation/cgroup-v2.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index 65b3eac
off-by documentation from Linux and Git
into a new repository [1].
On Sat, Nov 24, 2012 at 09:25:15AM -0500, W. Trevor King wrote:
> So. What license is the DCO distributed under and who holds
> copyright?
The Git project did some similar copying of the DCO into a new project
[2] and i
On Wed, Nov 21, 2012 at 12:10:43AM +, Alan Cox wrote:
> > Not just a separate document but project / github / whatever given
> > that other projects are referring to it now, and we stand to gain more
> > in the community by streamlining it more and making it ubiquitous.
>
> Cutting and pasting
The FCC ID on the board is HEDEN1207DTXR01, which belongs to Accton
Technology Corporation. This matches the expected 1113 ID. Perhaps
my board just has a dying EEPROM?
Signed-off-by: W. Trevor King
---
I'm not sure if this qualifies as a patch-able issue, but I thought
I'd send it
26 matches
Mail list logo