From: Nikolay Borisov <kernel-6AxghH7DbtA@public.gmane.org>
To: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Nikolay Borisov <kernel-6AxghH7DbtA@public.gmane.org>,
operations-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org
Subject: [RFC PATCH 0/4 v3] Inotify limits per usernamespace
Date: Wed, 13 Jul 2016 15:14:09 +0300 [thread overview]
Message-ID: <1468412053-30130-1-git-send-email-kernel@kyup.com> (raw)
Hello Eric,
Another day, another version...
So this is version 3 of the patches initially posted at [1].
Version 2 can be fount at [2]
So I reworked the way the state for namespaces are created and
the code is indeed a lot cleaner and easier to understand. I've
also moved from using uid and instead always work with kuids.
Finally I reworked the hashtable to be a global one and indexed by
the kuid value. With this I believe I have adressed all your points
in your previous review.
I still haven't tackled the issue with the semantics of the sysctls.
But judging from your last reply about being content with just setting
the limit at the top-level I believe the way to fix this would be
make a custom proc handler that writes to the variable in the
current userns. Opinions?
[1] http://thread.gmane.org/gmane.linux.kernel/2232000
[2] https://lists.linuxfoundation.org/pipermail/containers/2016-June/037019.html
Nikolay Borisov (4):
hashtable: Add __HASHTABLE_INITIALIZER
misc: Rename the HASH_SIZE macro
userns/inotify: Initial implementation of inotify per-userns
inotify: Convert to using new userns infrastructure
fs/logfs/dir.c | 6 +-
fs/notify/inotify/inotify.h | 2 +
fs/notify/inotify/inotify_fsnotify.c | 14 +++-
fs/notify/inotify/inotify_user.c | 136 +++++++++++++++++++++++++++----
include/linux/fsnotify_backend.h | 4 +-
include/linux/hashtable.h | 3 +
include/linux/sched.h | 4 -
include/linux/user_namespace.h | 45 ++++++++++
kernel/user_namespace.c | 106 +++++++++++++++++++++++-
net/ipv6/ip6_gre.c | 8 +-
net/ipv6/ip6_tunnel.c | 10 +--
net/ipv6/ip6_vti.c | 10 +--
net/ipv6/sit.c | 10 +--
security/keys/encrypted-keys/encrypted.c | 32 ++++----
14 files changed, 327 insertions(+), 63 deletions(-)
--
2.5.0
next reply other threads:[~2016-07-13 12:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-13 12:14 Nikolay Borisov [this message]
[not found] ` <1468412053-30130-1-git-send-email-kernel-6AxghH7DbtA@public.gmane.org>
2016-07-13 12:14 ` [PATCH 1/4] hashtable: Add __HASHTABLE_INITIALIZER Nikolay Borisov
2016-07-13 12:14 ` [PATCH 2/4] misc: Rename the HASH_SIZE macro Nikolay Borisov
2016-07-13 12:14 ` [PATCH 3/4] userns/inotify: Initial implementation of inotify per-userns Nikolay Borisov
2016-07-13 12:14 ` [PATCH 4/4] inotify: Convert to using new userns infrastructure Nikolay Borisov
2016-07-20 0:41 ` [RFC PATCH 0/4 v3] Inotify limits per usernamespace Eric W. Biederman
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=1468412053-30130-1-git-send-email-kernel@kyup.com \
--to=kernel-6axghh7dbta@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=operations-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox