From: Petr Vorel <pvorel@suse.cz>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Christian Brauner <christian@brauner.io>,
Alexey Gladkov <legion@kernel.org>,
"Eric W . Biederman" <ebiederm@xmission.com>,
"Serge E . Hallyn" <serge@hallyn.com>,
Vasily Averin <vvs@virtuozzo.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/1] ns: Move MAX_PID_NS_LEVEL to ns_common.h, reuse it
Date: Fri, 25 Mar 2022 17:12:25 +0100 [thread overview]
Message-ID: <Yj3p6etC9Wr/gvr5@pevik> (raw)
In-Reply-To: <20220325153714.eau4ja6pcr2a34sh@wittgenstein>
Hi all,
> On Fri, Mar 25, 2022 at 12:21:27PM +0100, Petr Vorel wrote:
> > Move MAX_PID_NS_LEVEL to ns_common.h and reuse it in check in
> > user_namespace.c.
> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > Hi Christian, all,
> > I don't see putting MAX_PID_NS_LEVEL into ns_common.h as an elegant
> > solution but IMHO better than use a hardwired number or redefinition in
> > user_namespace.h.
> Hey Petr,
> Weird I either deleted that message by accident or didn't get it.
Interesting. BTW I didn't get any bounce suggesting mail to you didn't arrive.
> > Kind regards,
> > Petr
> > include/linux/ns_common.h | 3 +++
> > include/linux/pid_namespace.h | 3 ---
> > kernel/user_namespace.c | 2 +-
> > 3 files changed, 4 insertions(+), 4 deletions(-)
> > diff --git a/include/linux/ns_common.h b/include/linux/ns_common.h
> > index 0f1d024bd958..173fab9dadf7 100644
> > --- a/include/linux/ns_common.h
> > +++ b/include/linux/ns_common.h
> > @@ -4,6 +4,9 @@
> > #include <linux/refcount.h>
> > +/* MAX_PID_NS_LEVEL is needed for limiting size of 'struct pid' */
> > +#define MAX_PID_NS_LEVEL 32
> The only two namespaces where this applies to have the same hard-coded
> limit. If you want to get rid of the raw number you should just
> introduce a generic define that expresses the limit for both pidns
> and userns. Using "MAX_PID_NS_LEVEL" in the userns case is very
> confusing. So if you wanted to do this introducing something like
> #define MAX_NS_LEVEL 32
> and using it in both places makes more sense.
Thanks a lot, I overlooked they aren't related.
I wonder if there should be just one constant for both (i.e. MAX_NS_LEVEL) as
you suggest, 2 constants, i.e keep MAX_PID_NS_LEVEL and add MAX_USER_NS_LEVEL
(which happen to be both 32).
Also understand if you prefer just to keep the raw number (MAX_PID_NS_LEVEL has
more use than just a single place, but user namespaces need it just on single
place).
Kind regards,
Petr
> Christian
prev parent reply other threads:[~2022-03-25 16:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 11:21 [PATCH 1/1] ns: Move MAX_PID_NS_LEVEL to ns_common.h, reuse it Petr Vorel
2022-03-25 13:29 ` Eric W. Biederman
2022-03-25 16:04 ` Petr Vorel
2022-03-25 15:37 ` Christian Brauner
2022-03-25 16:12 ` Petr Vorel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yj3p6etC9Wr/gvr5@pevik \
--to=pvorel@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=christian@brauner.io \
--cc=ebiederm@xmission.com \
--cc=legion@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=vvs@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.