Re: [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
On 15/04/17, Peter Zijlstra wrote: > On Fri, Apr 17, 2015 at 11:42:50AM -0400, Richard Guy Briggs wrote: > > On 15/04/17, Peter Zijlstra wrote: > > > On Fri, Apr 17, 2015 at 03:35:54AM -0400, Richard Guy Briggs wrote: > > > > Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. > > > > > > A wee bit about why might be nice.. > > > > It makes the following patch much cleaner to read: > > [PATCH V6 08/10] fork: audit on creation of new namespace(s) > > https://lkml.org/lkml/2015/4/17/50 > > > > I was hoping it might also make a lot of other code cleaner, but most of > > the other places where multiple CLONE_NEW* flags are used, not all six > > are used together, but only 5 are used. Ok, so it is helpful in 1 of 3: > > > > It would actually be useful in check_unshare_flags(): > > https://github.com/torvalds/linux/blob/v3.17/kernel/fork.c#L1791 > > > > but not in copy_namespaces() or unshare_nsproxy_namespaces(): > > https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L130 > > https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L183 > > Right, so no objections from me on this, its just that I only saw this > one patch in isolation without context and the changelog failed on > rationale. I realize you only saw a small window of this patchset, but this feels like bike shedding about the main objective of the set... I'll add a bit more justification and context if/when I respin for the rest of the set. > Does it perchance make sense to fold this patch into the next patch that > actually makes use of it? It would if it were the only potential user. I don't want to bury a surprise in something bigger. Is there a preferred way to use such a macro to make the other three examples cleaner, or is that just useless churn and obfuscation? Would there be a concise way to express all CLONE_NEW* flags *except* user? - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
On Fri, Apr 17, 2015 at 11:42:50AM -0400, Richard Guy Briggs wrote: > On 15/04/17, Peter Zijlstra wrote: > > On Fri, Apr 17, 2015 at 03:35:54AM -0400, Richard Guy Briggs wrote: > > > Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. > > > > A wee bit about why might be nice.. > > It makes the following patch much cleaner to read: > [PATCH V6 08/10] fork: audit on creation of new namespace(s) > https://lkml.org/lkml/2015/4/17/50 > > I was hoping it might also make a lot of other code cleaner, but most of > the other places where multiple CLONE_NEW* flags are used, not all six > are used together, but only 5 are used. Ok, so it is helpful in 1 of 3: > > It would actually be useful in check_unshare_flags(): > https://github.com/torvalds/linux/blob/v3.17/kernel/fork.c#L1791 > > but not in copy_namespaces() or unshare_nsproxy_namespaces(): > https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L130 > https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L183 > Right, so no objections from me on this, its just that I only saw this one patch in isolation without context and the changelog failed on rationale. Does it perchance make sense to fold this patch into the next patch that actually makes use of it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
On 15/04/17, Peter Zijlstra wrote: > On Fri, Apr 17, 2015 at 03:35:54AM -0400, Richard Guy Briggs wrote: > > Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. > > A wee bit about why might be nice.. It makes the following patch much cleaner to read: [PATCH V6 08/10] fork: audit on creation of new namespace(s) https://lkml.org/lkml/2015/4/17/50 I was hoping it might also make a lot of other code cleaner, but most of the other places where multiple CLONE_NEW* flags are used, not all six are used together, but only 5 are used. Ok, so it is helpful in 1 of 3: It would actually be useful in check_unshare_flags(): https://github.com/torvalds/linux/blob/v3.17/kernel/fork.c#L1791 but not in copy_namespaces() or unshare_nsproxy_namespaces(): https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L130 https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L183 - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
On Fri, Apr 17, 2015 at 03:35:54AM -0400, Richard Guy Briggs wrote: > Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. A wee bit about why might be nice.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. Signed-off-by: Richard Guy Briggs --- include/uapi/linux/sched.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index 34f9d73..21ed8f4 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -28,6 +28,12 @@ #define CLONE_NEWUSER 0x1000 /* New user namespace */ #define CLONE_NEWPID 0x2000 /* New pid namespace */ #define CLONE_NEWNET 0x4000 /* New network namespace */ +#define CLONE_NEW_MASK_ALL (CLONE_NEWNS \ + | CLONE_NEWUTS \ + | CLONE_NEWIPC \ + | CLONE_NEWUSER \ + | CLONE_NEWPID \ + | CLONE_NEWNET) /* mask of all namespace type flags */ #define CLONE_IO 0x8000 /* Clone io context */ /* -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. Signed-off-by: Richard Guy Briggs r...@redhat.com --- include/uapi/linux/sched.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index 34f9d73..21ed8f4 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -28,6 +28,12 @@ #define CLONE_NEWUSER 0x1000 /* New user namespace */ #define CLONE_NEWPID 0x2000 /* New pid namespace */ #define CLONE_NEWNET 0x4000 /* New network namespace */ +#define CLONE_NEW_MASK_ALL (CLONE_NEWNS \ + | CLONE_NEWUTS \ + | CLONE_NEWIPC \ + | CLONE_NEWUSER \ + | CLONE_NEWPID \ + | CLONE_NEWNET) /* mask of all namespace type flags */ #define CLONE_IO 0x8000 /* Clone io context */ /* -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
On Fri, Apr 17, 2015 at 03:35:54AM -0400, Richard Guy Briggs wrote: Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. A wee bit about why might be nice.. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
On Fri, Apr 17, 2015 at 11:42:50AM -0400, Richard Guy Briggs wrote: On 15/04/17, Peter Zijlstra wrote: On Fri, Apr 17, 2015 at 03:35:54AM -0400, Richard Guy Briggs wrote: Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. A wee bit about why might be nice.. It makes the following patch much cleaner to read: [PATCH V6 08/10] fork: audit on creation of new namespace(s) https://lkml.org/lkml/2015/4/17/50 I was hoping it might also make a lot of other code cleaner, but most of the other places where multiple CLONE_NEW* flags are used, not all six are used together, but only 5 are used. Ok, so it is helpful in 1 of 3: It would actually be useful in check_unshare_flags(): https://github.com/torvalds/linux/blob/v3.17/kernel/fork.c#L1791 but not in copy_namespaces() or unshare_nsproxy_namespaces(): https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L130 https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L183 Right, so no objections from me on this, its just that I only saw this one patch in isolation without context and the changelog failed on rationale. Does it perchance make sense to fold this patch into the next patch that actually makes use of it? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
On 15/04/17, Peter Zijlstra wrote: On Fri, Apr 17, 2015 at 03:35:54AM -0400, Richard Guy Briggs wrote: Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. A wee bit about why might be nice.. It makes the following patch much cleaner to read: [PATCH V6 08/10] fork: audit on creation of new namespace(s) https://lkml.org/lkml/2015/4/17/50 I was hoping it might also make a lot of other code cleaner, but most of the other places where multiple CLONE_NEW* flags are used, not all six are used together, but only 5 are used. Ok, so it is helpful in 1 of 3: It would actually be useful in check_unshare_flags(): https://github.com/torvalds/linux/blob/v3.17/kernel/fork.c#L1791 but not in copy_namespaces() or unshare_nsproxy_namespaces(): https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L130 https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L183 - RGB -- Richard Guy Briggs rbri...@redhat.com Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 07/10] sched: add a macro to ref all CLONE_NEW* flags
On 15/04/17, Peter Zijlstra wrote: On Fri, Apr 17, 2015 at 11:42:50AM -0400, Richard Guy Briggs wrote: On 15/04/17, Peter Zijlstra wrote: On Fri, Apr 17, 2015 at 03:35:54AM -0400, Richard Guy Briggs wrote: Added the macro CLONE_NEW_MASK_ALL to refer to all CLONE_NEW* flags. A wee bit about why might be nice.. It makes the following patch much cleaner to read: [PATCH V6 08/10] fork: audit on creation of new namespace(s) https://lkml.org/lkml/2015/4/17/50 I was hoping it might also make a lot of other code cleaner, but most of the other places where multiple CLONE_NEW* flags are used, not all six are used together, but only 5 are used. Ok, so it is helpful in 1 of 3: It would actually be useful in check_unshare_flags(): https://github.com/torvalds/linux/blob/v3.17/kernel/fork.c#L1791 but not in copy_namespaces() or unshare_nsproxy_namespaces(): https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L130 https://github.com/torvalds/linux/blob/v3.17/kernel/nsproxy.c#L183 Right, so no objections from me on this, its just that I only saw this one patch in isolation without context and the changelog failed on rationale. I realize you only saw a small window of this patchset, but this feels like bike shedding about the main objective of the set... I'll add a bit more justification and context if/when I respin for the rest of the set. Does it perchance make sense to fold this patch into the next patch that actually makes use of it? It would if it were the only potential user. I don't want to bury a surprise in something bigger. Is there a preferred way to use such a macro to make the other three examples cleaner, or is that just useless churn and obfuscation? Would there be a concise way to express all CLONE_NEW* flags *except* user? - RGB -- Richard Guy Briggs rbri...@redhat.com Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
