* [PATCH 2/5] lib/rhashtable: guarantee initial hashtable allocation
From: Davidlohr Bueso @ 2018-06-01 16:01 UTC (permalink / raw)
To: akpm, torvalds
Cc: tgraf, herbert, manfred, mhocko, guillaume.knispel, linux-api,
linux-kernel, Davidlohr Bueso, Davidlohr Bueso
In-Reply-To: <20180601160125.30031-1-dave@stgolabs.net>
rhashtable_init() may fail due to -ENOMEM, thus making the
entire api unusable. This patch removes this scenario,
however unlikely. In order to guarantee memory allocation,
this patch always ends up doing GFP_KERNEL|__GFP_NOFAIL
for both the tbl as well as alloc_bucket_spinlocks().
Upon the first table allocation failure, we shrink the
size to the smallest value that makes sense retry with
__GFP_NOFAIL semantics. With the defaults, this means that
from 64 buckets, we retry with only 4. Any later issues
regarding performance due to collisions or larger table
resizing (when more memory becomes available) is the last
of our problems.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
lib/rhashtable.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 05a4b1b8b8ce..ae17da6f0c75 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -175,7 +175,7 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
int i;
size = sizeof(*tbl) + nbuckets * sizeof(tbl->buckets[0]);
- if (gfp != GFP_KERNEL)
+ if ((gfp & ~__GFP_NOFAIL) != GFP_KERNEL)
tbl = kzalloc(size, gfp | __GFP_NOWARN | __GFP_NORETRY);
else
tbl = kvzalloc(size, gfp);
@@ -1067,9 +1067,16 @@ int rhashtable_init(struct rhashtable *ht,
}
}
+ /*
+ * This is api initialization and thus we need to guarantee the
+ * initial rhashtable allocation. Upon failure, retry with the
+ * smallest possible size with __GFP_NOFAIL semantics.
+ */
tbl = bucket_table_alloc(ht, size, GFP_KERNEL);
- if (tbl == NULL)
- return -ENOMEM;
+ if (unlikely(tbl == NULL)) {
+ size = min_t(u16, ht->p.min_size, HASH_MIN_SIZE);
+ tbl = bucket_table_alloc(ht, size, GFP_KERNEL | __GFP_NOFAIL);
+ }
atomic_set(&ht->nelems, 0);
--
2.16.3
^ permalink raw reply related
* [PATCH 1/5] lib/rhashtable: convert param sanitations to WARN_ON
From: Davidlohr Bueso @ 2018-06-01 16:01 UTC (permalink / raw)
To: akpm, torvalds
Cc: tgraf, herbert, manfred, mhocko, guillaume.knispel, linux-api,
linux-kernel, Davidlohr Bueso, Davidlohr Bueso
In-Reply-To: <20180601160125.30031-1-dave@stgolabs.net>
For the purpose of making rhashtable_init() unable to fail,
we can replace the returning -EINVAL with WARN_ONs whenever
the caller passes bogus parameters during initialization.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
lib/rhashtable.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 9427b5766134..05a4b1b8b8ce 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -1024,12 +1024,11 @@ int rhashtable_init(struct rhashtable *ht,
size = HASH_DEFAULT_SIZE;
- if ((!params->key_len && !params->obj_hashfn) ||
- (params->obj_hashfn && !params->obj_cmpfn))
- return -EINVAL;
+ WARN_ON((!params->key_len && !params->obj_hashfn) ||
+ (params->obj_hashfn && !params->obj_cmpfn));
- if (params->nulls_base && params->nulls_base < (1U << RHT_BASE_SHIFT))
- return -EINVAL;
+ WARN_ON(params->nulls_base &&
+ params->nulls_base < (1U << RHT_BASE_SHIFT));
memset(ht, 0, sizeof(*ht));
mutex_init(&ht->mutex);
--
2.16.3
^ permalink raw reply related
* [PATCH -next v2 0/5] rhashtable: guarantee first allocation
From: Davidlohr Bueso @ 2018-06-01 16:01 UTC (permalink / raw)
To: akpm, torvalds
Cc: tgraf, herbert, manfred, mhocko, guillaume.knispel, linux-api,
linux-kernel, Davidlohr Bueso
Changes from v1
lkml.kernel.org/r/20180524211135.27760-1-dave@stgolabs.net
- patch 2 is reworked a bit based on the commments from Herbert Xu.
o upon failure, retry immediately with GFP_NOFAIL (simpler)
o the caller now passes the needed semantics, not bucket_table_alloc().
o we consider min_size when resizing, not just HASH_MIN_SIZE.
- removed patch 3; not need after Michal's patch.
Hi,
This series is the result of the discussion with Linus around ipc
subsystem initialization and how it behaves with error return when
calling rhashtable_init()[1]. Instead of caring about the error
or calling the infamous BUG_ON, Linus suggested we guarantee the
rhashtable allocation.
First two patches modify rhashtable_init() to just return 0, future
patches will update more callers, particularly those that use BUG_ON.
patch 3+4 remove some ipc hacks we no longer need.
patch 5 updates the rhashtable test module. Trivial.
Please consider for v4.18.
Thanks!
[0] https://lkml.org/lkml/2018/5/23/758
Davidlohr Bueso (5):
lib/rhashtable: convert param sanitations to WARN_ON
lib/rhashtable: guarantee initial hashtable allocation
ipc: get rid of ids->tables_initialized hack
ipc: simplify ipc initialization
lib/test_rhashtable: rhashtable_init() can no longer fail
include/linux/ipc_namespace.h | 1 -
ipc/msg.c | 9 ++++-----
ipc/namespace.c | 20 ++++----------------
ipc/sem.c | 10 ++++------
ipc/shm.c | 9 ++++-----
ipc/util.c | 41 +++++++++++++----------------------------
ipc/util.h | 18 +++++++++---------
lib/rhashtable.c | 22 ++++++++++++++--------
lib/test_rhashtable.c | 6 +-----
9 files changed, 53 insertions(+), 83 deletions(-)
--
2.16.3
^ permalink raw reply
* Re: [PATCH RFC v5] pidns: introduce syscall translate_pid
From: NAGARATHNAM MUTHUSAMY @ 2018-06-01 15:55 UTC (permalink / raw)
To: Konstantin Khlebnikov, Eric W. Biederman
Cc: Konstantin Khlebnikov, Linux API, Linux Kernel Mailing List,
Jann Horn, Serge Hallyn, Oleg Nesterov, Andy Lutomirski,
Prakash Sangappa, Andrew Morton
In-Reply-To: <CALYGNiPyjJQ2dZHtF+Ug5TFjEcK2O9anLDDDG0JftXtykPAoEg@mail.gmail.com>
On 5/31/2018 11:58 PM, Konstantin Khlebnikov wrote:
> On Thu, May 31, 2018 at 9:05 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> writes:
>>
>>> Ping? Any additional comments on this patch?
>> Konstantin's v5 no.
>>
>> I am uncomfortable with unnecessary flexibility. I don't want to
>> encourage the increased usage of pids to identify namespaces. I saw
>> no arguments in favor of pids to identify namespaces from Konstantin.
>>
>> Your v4 updated to reflect Andrew Morton's concerns in the changelog
>> yes.
> Ok, whatever. If I the only blocker then let it be v4 design.
Thanks! I will resend the V4 patch with a plain text man page for
translate_pid.
Thanks,
Nagarathnam.
>
>> Eric
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-api" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]
From: David Howells @ 2018-06-01 8:42 UTC (permalink / raw)
To: Amir Goldstein
Cc: dhowells, Al Viro, linux-fsdevel, linux-afs, linux-kernel,
linux-api
In-Reply-To: <CAOQ4uxjbZEyqNPwE8m0QmCU7OG831r4Lpg+M1RWCOxDrsgErnA@mail.gmail.com>
Amir Goldstein <amir73il@gmail.com> wrote:
> Reject O_NON_RECURSIVE without O_CLONE_MOUNT?
Yes, I should add that.
> I am not sure what are the consequences of opening O_PATH with old kernel
> and getting an open file, can't think of anything bad.
> Can the same be claimed for O_PATH|O_CLONE_MOUNT?
Yes, actually, there can be consequences. Some files have side effects.
Think open("/dev/foobar", O_PATH).
> Wouldn't it be better to apply the O_TMPFILE kludge to the new
> open flag, so that apps can check if O_CLONE_MOUNT feature is supported
> by kernel?
Ugh. The problem is that the O_TMPFILE kludge can't be done because O_PATH
currently just masks off any bits it's not interested in rather than giving an
error.
Even the O_TMPFILE kludge doesn't protect you against someone having set
random unassigned bits when testing on a kernel that didn't support it.
And this bit:
/*
* Clear out all open flags we don't know about so that we don't report
* them in fcntl(F_GETFD) or similar interfaces.
*/
flags &= VALID_OPEN_FLAGS;
is just plain wrong. Effectively, it allows userspace to set random reserved
bits without consequences. It should give an error instead.
Probably we should really replace open() and openat() both before we can
allocate any further open flags.
</grumble>
David
^ permalink raw reply
* Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]
From: David Howells @ 2018-06-01 8:27 UTC (permalink / raw)
To: Al Viro
Cc: dhowells, Christoph Hellwig, linux-fsdevel, linux-afs,
linux-kernel, linux-api
In-Reply-To: <20180601063928.GS30522@ZenIV.linux.org.uk>
Al Viro <viro@ZenIV.linux.org.uk> wrote:
> > Instead of overloading this on open having a specific syscalls just
> > seems like a much saner idea.
>
> It's not just mount API; these can be used independently of that.
> Think of the uses where you pass those to ...at() and you'll see
> a bunch of applications of that thing.
I kind of agree with Christoph on this point. Yes, you can use the resultant
fd for other things, but that doesn't mean it has to be obtained initially
through open() or openat() rather than, say, a new pick_mount() syscall.
Further, having more parameters available gives us the opportunity to change
the settings on any mounts we create at the point of creation.
David
^ permalink raw reply
* Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]
From: Amir Goldstein @ 2018-06-01 8:02 UTC (permalink / raw)
To: David Howells; +Cc: Al Viro, linux-fsdevel, linux-afs, linux-kernel, linux-api
In-Reply-To: <152720691829.9073.10564431140980997005.stgit@warthog.procyon.org.uk>
[added linux-api]
On Fri, May 25, 2018 at 3:08 AM, David Howells <dhowells@redhat.com> wrote:
> Make it possible to clone a mount tree with a new pair of open flags that
> are used in conjunction with O_PATH:
>
> (1) O_CLONE_MOUNT - Clone the mount or mount tree at the path.
>
> (2) O_NON_RECURSIVE - Don't clone recursively.
>
> Note that it's not a good idea to reuse other flags (such as O_CREAT)
> because the open routine for O_PATH does not give an error if any other
> flags are used in conjunction with O_PATH, but rather just masks off any it
> doesn't use.
>
> The resultant file struct is marked FMODE_NEED_UNMOUNT to as it pins an
> extra reference for the mount. This will be cleared by the upcoming
> move_mount() syscall when it successfully moves a cloned mount into the
> filesystem tree.
>
> Note that care needs to be taken with the error handling in do_o_path() in
> the case that vfs_open() fails as the path may or may not have been
> attached to the file struct and FMODE_NEED_UNMOUNT may or may not be set.
> Note that O_DIRECT | O_PATH could be a problem with error handling too.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
[...]
> @@ -977,8 +979,11 @@ static inline int build_open_flags(int flags, umode_t mode, struct open_flags *o
> * If we have O_PATH in the open flag. Then we
> * cannot have anything other than the below set of flags
> */
> - flags &= O_DIRECTORY | O_NOFOLLOW | O_PATH;
> + flags &= (O_DIRECTORY | O_NOFOLLOW | O_PATH |
> + O_CLONE_MOUNT | O_NON_RECURSIVE);
> acc_mode = 0;
> + } else if (flags & (O_CLONE_MOUNT | O_NON_RECURSIVE)) {
> + return -EINVAL;
Reject O_NON_RECURSIVE without O_CLONE_MOUNT?
That would free at least one flag combination for future use.
Doesn't it make more sense for user API to opt-into
O_RECURSIVE_CLONE, rather than opt-out of it?
> }
>
> op->open_flag = flags;
> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index 27dc7a60693e..8f60e2244740 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -9,7 +9,8 @@
> (O_RDONLY | O_WRONLY | O_RDWR | O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC | \
> O_APPEND | O_NDELAY | O_NONBLOCK | O_NDELAY | __O_SYNC | O_DSYNC | \
> FASYNC | O_DIRECT | O_LARGEFILE | O_DIRECTORY | O_NOFOLLOW | \
> - O_NOATIME | O_CLOEXEC | O_PATH | __O_TMPFILE)
> + O_NOATIME | O_CLOEXEC | O_PATH | __O_TMPFILE | \
> + O_CLONE_MOUNT | O_NON_RECURSIVE)
>
> #ifndef force_o_largefile
> #define force_o_largefile() (BITS_PER_LONG != 32)
> diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
> index 0b1c7e35090c..f533e35ea19b 100644
> --- a/include/uapi/asm-generic/fcntl.h
> +++ b/include/uapi/asm-generic/fcntl.h
> @@ -88,6 +88,14 @@
> #define __O_TMPFILE 020000000
> #endif
>
> +#ifndef O_CLONE_MOUNT
> +#define O_CLONE_MOUNT 040000000 /* Used with O_PATH to clone the mount subtree at path */
> +#endif
> +
> +#ifndef O_NON_RECURSIVE
> +#define O_NON_RECURSIVE 0100000000 /* Used with O_CLONE_MOUNT to only clone one mount */
> +#endif
> +
> /* a horrid kludge trying to make sure that this will fail on old kernels */
> #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
> #define O_TMPFILE_MASK (__O_TMPFILE | O_DIRECTORY | O_CREAT)
>
I am not sure what are the consequences of opening O_PATH with old kernel
and getting an open file, can't think of anything bad.
Can the same be claimed for O_PATH|O_CLONE_MOUNT?
Wouldn't it be better to apply the O_TMPFILE kludge to the new
open flag, so that apps can check if O_CLONE_MOUNT feature is supported
by kernel?
Thanks,
Amir.
^ permalink raw reply
* Re: [PATCH RFC v5] pidns: introduce syscall translate_pid
From: Konstantin Khlebnikov @ 2018-06-01 6:58 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Nagarathnam Muthusamy, Konstantin Khlebnikov, Linux API,
Linux Kernel Mailing List, Jann Horn, Serge Hallyn, Oleg Nesterov,
Andy Lutomirski, Prakash Sangappa, Andrew Morton
In-Reply-To: <87po1bd7ky.fsf@xmission.com>
On Thu, May 31, 2018 at 9:05 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> writes:
>
>> Ping? Any additional comments on this patch?
>
> Konstantin's v5 no.
>
> I am uncomfortable with unnecessary flexibility. I don't want to
> encourage the increased usage of pids to identify namespaces. I saw
> no arguments in favor of pids to identify namespaces from Konstantin.
>
> Your v4 updated to reflect Andrew Morton's concerns in the changelog
> yes.
Ok, whatever. If I the only blocker then let it be v4 design.
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]
From: Al Viro @ 2018-06-01 6:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Howells, linux-fsdevel, linux-afs, linux-kernel, linux-api
In-Reply-To: <20180601062654.GA32397@infradead.org>
On Thu, May 31, 2018 at 11:26:54PM -0700, Christoph Hellwig wrote:
> On Fri, May 25, 2018 at 01:08:38AM +0100, David Howells wrote:
> > Make it possible to clone a mount tree with a new pair of open flags that
> > are used in conjunction with O_PATH:
> >
> > (1) O_CLONE_MOUNT - Clone the mount or mount tree at the path.
> >
> > (2) O_NON_RECURSIVE - Don't clone recursively.
>
> Err. I don't think we should use up two O_* flags for something
> only useful for your new mount API. Don't we have a better place
> to for these flags?
>
> Instead of overloading this on open having a specific syscalls just
> seems like a much saner idea.
It's not just mount API; these can be used independently of that.
Think of the uses where you pass those to ...at() and you'll see
a bunch of applications of that thing.
^ permalink raw reply
* Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]
From: Christoph Hellwig @ 2018-06-01 6:26 UTC (permalink / raw)
To: David Howells; +Cc: viro, linux-fsdevel, linux-afs, linux-kernel, linux-api
In-Reply-To: <152720691829.9073.10564431140980997005.stgit@warthog.procyon.org.uk>
On Fri, May 25, 2018 at 01:08:38AM +0100, David Howells wrote:
> Make it possible to clone a mount tree with a new pair of open flags that
> are used in conjunction with O_PATH:
>
> (1) O_CLONE_MOUNT - Clone the mount or mount tree at the path.
>
> (2) O_NON_RECURSIVE - Don't clone recursively.
Err. I don't think we should use up two O_* flags for something
only useful for your new mount API. Don't we have a better place
to for these flags?
Instead of overloading this on open having a specific syscalls just
seems like a much saner idea.
^ permalink raw reply
* Re: [PATCH RFC v5] pidns: introduce syscall translate_pid
From: Eric W. Biederman @ 2018-05-31 18:05 UTC (permalink / raw)
To: Nagarathnam Muthusamy
Cc: Konstantin Khlebnikov, linux-api, linux-kernel, Jann Horn,
Serge Hallyn, Oleg Nesterov, Andy Lutomirski, Prakash Sangappa,
Andrew Morton
In-Reply-To: <3bdd6b27-0a46-5802-8671-07268cecc1c7@oracle.com>
Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> writes:
> Ping? Any additional comments on this patch?
Konstantin's v5 no.
I am uncomfortable with unnecessary flexibility. I don't want to
encourage the increased usage of pids to identify namespaces. I saw
no arguments in favor of pids to identify namespaces from Konstantin.
Your v4 updated to reflect Andrew Morton's concerns in the changelog
yes.
Eric
^ permalink raw reply
* Re: [PATCH RFC v5] pidns: introduce syscall translate_pid
From: Eric W. Biederman @ 2018-05-31 18:02 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Konstantin Khlebnikov, Nagarathnam Muthusamy, linux-api,
linux-kernel, Jann Horn, Serge Hallyn, Oleg Nesterov,
Andy Lutomirski, Prakash Sangappa, Andrew Morton
In-Reply-To: <71d8d32b-0f59-d418-0ee4-fcc7782646ae@gmail.com>
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> On 04/05/2018 09:02 AM, Konstantin Khlebnikov wrote:
>> On 05.04.2018 01:29, Eric W. Biederman wrote:
>>> Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> 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 single pid-ns translation isn't required.
>>>>> More complicated scenarios needs special handling.
>>>>>
>>>>> For example:
>>>>> - reading pid-files or logs written inside container with pid namespace
>>>>> - attaching with ptrace to tasks from different pid namespace
>>>>> - passing pids across pid namespaces in any kind of API
>>>>>
>>>>> Currently there are several interfaces that could be used here:
>>>>>
>>>>> Pid namespaces are identified by inode number of /proc/[pid]/ns/pid.
>>>
>>> Using the inode number in interfaces is not an option. Especially not
>>> withou referencing the device number for the filesystem as well.
>>
>> This is supposed to be single-instance fs,
>> not part of proc but referenced but its magic "symlinks".
>>
>> Device numbers are not mentioned in "man namespaces".
>
> Thanks for the heads-up!
>
> That was a bug in the man-page. ioctl_ns(2) already says the right thing.
> Now I patches namespaces(7), as below.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
For the changes to namespaces.7. I suspect you have already applied
them by now, but if not.
Eric
> Cheers,
>
> Michael
>
> diff --git a/man7/namespaces.7 b/man7/namespaces.7
> index 725ebaff6..3c155de7e 100644
> --- a/man7/namespaces.7
> +++ b/man7/namespaces.7
> @@ -154,11 +154,14 @@ In Linux 3.7 and earlier, these files were visible as hard links.
> Since Linux 3.8,
> .\" commit bf056bfa80596a5d14b26b17276a56a0dcb080e5
> they appear as symbolic links.
> -If two processes are in the same namespace, then the inode numbers of their
> +If two processes are in the same namespace,
> +then the device IDs and inode numbers of their
> .IR /proc/[pid]/ns/xxx
> symbolic links will be the same; an application can check this using the
> +.I stat.st_dev
> +and
> .I stat.st_ino
> -field returned by
> +fields returned by
> .BR stat (2).
> The content of this symbolic link is a string containing
> the namespace type and inode number as in the following example:
^ permalink raw reply
* Re: [PATCH RFC v5] pidns: introduce syscall translate_pid
From: Eric W. Biederman @ 2018-05-31 17:52 UTC (permalink / raw)
To: Nagarathnam Muthusamy
Cc: Konstantin Khlebnikov, linux-api, linux-kernel, Jann Horn,
Serge Hallyn, Oleg Nesterov, Andy Lutomirski, Prakash Sangappa,
Andrew Morton
In-Reply-To: <3bdd6b27-0a46-5802-8671-07268cecc1c7@oracle.com>
Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> writes:
> 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 W. Biederman wrote:
>>>>>>> Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> 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 single pid-ns translation
>>>>>>>>> isn't required.
>>>>>>>>> More complicated scenarios needs special handling.
>>>>>>>>>
>>>>>>>>> For example:
>>>>>>>>> - reading pid-files or logs written inside container with pid
>>>>>>>>> namespace
>>>>>>>>> - attaching with ptrace to tasks from different pid namespace
>>>>>>>>> - passing pids across pid namespaces in any kind of API
>>>>>>>>>
>>>>>>>>> Currently there are several interfaces that could be used here:
>>>>>>>>>
>>>>>>>>> Pid namespaces are identified by inode number of
>>>>>>>>> /proc/[pid]/ns/pid.
>>>>>>>
>>>>>>> Using the inode number in interfaces is not an
>>>>>>> option. Especially not
>>>>>>> withou referencing the device number for the filesystem as well.
>>>>>>
>>>>>> This is supposed to be single-instance fs,
>>>>>> not part of proc but referenced but its magic "symlinks".
>>>>>>
>>>>>> Device numbers are not mentioned in "man namespaces".
>>>>>>
>>>>>>>
>>>>>>>>> Pids for nested Pid namespaces are shown in file
>>>>>>>>> /proc/[pid]/status.
>>>>>>>>> In some cases conversion pid -> vpid could be easily done
>>>>>>>>> using this
>>>>>>>>> information, but backward translation requires scanning all tasks.
>>>>>>>>>
>>>>>>>>> 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 could be insecure.
>>>>>>>>>
>>>>>>>>> This patch adds new syscall for converting pids between pid
>>>>>>>>> namespaces:
>>>>>>>>>
>>>>>>>>> pid_t translate_pid(pid_t pid, int source_type, int source,
>>>>>>>>> int target_type, int target);
>>>>>>>>>
>>>>>>>>> @source_type and @target_type defines type of following arguments:
>>>>>>>>>
>>>>>>>>> TRANSLATE_PID_CURRENT_PIDNS - current pid namespace,
>>>>>>>>> argument is unused
>>>>>>>>> TRANSLATE_PID_TASK_PIDNS - task pid-ns, argument is task pid
>>>>>>>>
>>>>>>>> I believe using pid to represent the namespace has been already
>>>>>>>> discussed in V1 of this patch in
>>>>>>>> https://lkml.org/lkml/2015/9/22/1087
>>>>>>>> after which we moved on to fd based version of this interface.
>>>>>>>
>>>>>>> Or in short why is the case of pids important?
>>>>>>>
>>>>>>> You Konstantin you almost said why they were important in your
>>>>>>> message
>>>>>>> saying you were going to send this one. However you don't
>>>>>>> explain in
>>>>>>> your description why you want to identify pid namespaces by pid.
>>>>>>>
>>>>>>
>>>>>> Open of /proc/[pid]/ns/pid requires same permissions as ptrace,
>>>>>> pid based variant doesn't have such restrictions.
>>>>>
>>>>> Can you provide more information on usecase requiring PID
>>>>> translation but not used for tracing related purposes?
>>>>
>>>> Any introspection for [nested] containers. It's easier to work
>>>> when you have all information when you don't have any.
>>>> For example our CMS https://github.com/yandex/porto allows to
>>>> start nested sub-container (or even deeper) by request from any
>>>> container and have to tell back which pid task is have. And it
>>>> could translate any pid inside into accessible by client and vice
>>>> versa.
>>>>
>>>
>>> I still dont get the exact reason why PID based approach to
>>> identify the namespace during pid translation process is absolutely
>>> required compared to fd based approach.
>>
>> As I told open(/proc/%d/ns/pid) have security restrictions - same
>> uid/CAP_SYS_PTRACE/whatever
>> Pidns-fd holds pid-namespace and without restrictions could be abused.
>> Pid based API is racy but always available without any restrictions.
>>
>>
>>> From your version of TranslatePid in
>>>
>>> https://github.com/yandex/porto/blob/0d7e6e7e1830dcd0038a057b2ab9964cec5b8fab/src/util/unix.cpp
>>>
>>>
>>> I see that you are going through the trouble of forking a process
>>> and sending SMC_CREDENTIALS for pid translation. Even your existing
>>> API could be extremely simplified if translate_pid based on file
>>> descriptors make it to the gate and I believe from the last
>>> discussion it was almost there
>>> https://patchwork.kernel.org/patch/10305439/
>>>
>>>
>>>>> On a side note, can we have the types TRANSLATE_PID_CURRENT_PIDNS
>>>>> and TRANSLATE_PID_FD_PIDNS integrated first and then possibly
>>>>> extend the interface to include TRANSLATE_PID_TASK_PIDNS in
>>>>> future?
>>>>
>>>> I don't see reason for this separation.
>>>> Pids and pid namespaces are part of the API for a long time.
>>>
>>> If you are talking about the translate_pid API proposed, I believe
>>> the V4 proposed under https://patchwork.kernel.org/patch/10003935/
>>> had only fd based API before a mix of PID and fd based is proposed
>>> in V5. Again, I was just wondering if we can get the FD based
>>> approach in first and then extend the API to include PID based
>>> approach later as fd based approach could provide a lot of
>>> immediate benefits?
>>>
>>> Thanks,
>>> Nagarathnam.
>>>>
>>>>>
>>>>> Thanks,
>>>>> Nagarathnam.
>>>>>> Most pid-based syscalls are racy in some cases but they are
>>>>>> here for decades and everybody knowns how to deal with it.
>>>>>> So, I've decided to merge both worlds in one interface which
>>>>>> clearly tells what to expect.
>>>>>
>>>
>
> Ping? Any additional comments on this patch?
I have totally lost the thread. Let me see if I can find enough of the
thread to see what is going on.
The whole let's use pids instead of fds was a major distraction.
Eric
^ permalink raw reply
* Re: [PATCH RFC v5] pidns: introduce syscall translate_pid
From: Nagarathnam Muthusamy @ 2018-05-31 17:41 UTC (permalink / raw)
To: Konstantin Khlebnikov, Eric W. Biederman
Cc: linux-api, linux-kernel, Jann Horn, Serge Hallyn, Oleg Nesterov,
Andy Lutomirski, Prakash Sangappa, Andrew Morton
In-Reply-To: <3e2c285a-1bf8-f71d-1b74-4d6465c29a54@yandex-team.ru>
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 W. Biederman wrote:
>>>>>> Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> 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 single pid-ns translation isn't
>>>>>>>> required.
>>>>>>>> More complicated scenarios needs special handling.
>>>>>>>>
>>>>>>>> For example:
>>>>>>>> - reading pid-files or logs written inside container with pid
>>>>>>>> namespace
>>>>>>>> - attaching with ptrace to tasks from different pid namespace
>>>>>>>> - passing pids across pid namespaces in any kind of API
>>>>>>>>
>>>>>>>> Currently there are several interfaces that could be used here:
>>>>>>>>
>>>>>>>> Pid namespaces are identified by inode number of
>>>>>>>> /proc/[pid]/ns/pid.
>>>>>>
>>>>>> Using the inode number in interfaces is not an option. Especially
>>>>>> not
>>>>>> withou referencing the device number for the filesystem as well.
>>>>>
>>>>> This is supposed to be single-instance fs,
>>>>> not part of proc but referenced but its magic "symlinks".
>>>>>
>>>>> Device numbers are not mentioned in "man namespaces".
>>>>>
>>>>>>
>>>>>>>> Pids for nested Pid namespaces are shown in file
>>>>>>>> /proc/[pid]/status.
>>>>>>>> In some cases conversion pid -> vpid could be easily done using
>>>>>>>> this
>>>>>>>> information, but backward translation requires scanning all tasks.
>>>>>>>>
>>>>>>>> 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 could be insecure.
>>>>>>>>
>>>>>>>> This patch adds new syscall for converting pids between pid
>>>>>>>> namespaces:
>>>>>>>>
>>>>>>>> pid_t translate_pid(pid_t pid, int source_type, int source,
>>>>>>>> int target_type, int target);
>>>>>>>>
>>>>>>>> @source_type and @target_type defines type of following arguments:
>>>>>>>>
>>>>>>>> TRANSLATE_PID_CURRENT_PIDNS - current pid namespace, argument
>>>>>>>> is unused
>>>>>>>> TRANSLATE_PID_TASK_PIDNS - task pid-ns, argument is task pid
>>>>>>>
>>>>>>> I believe using pid to represent the namespace has been already
>>>>>>> discussed in V1 of this patch in
>>>>>>> https://lkml.org/lkml/2015/9/22/1087
>>>>>>> after which we moved on to fd based version of this interface.
>>>>>>
>>>>>> Or in short why is the case of pids important?
>>>>>>
>>>>>> You Konstantin you almost said why they were important in your
>>>>>> message
>>>>>> saying you were going to send this one. However you don't
>>>>>> explain in
>>>>>> your description why you want to identify pid namespaces by pid.
>>>>>>
>>>>>
>>>>> Open of /proc/[pid]/ns/pid requires same permissions as ptrace,
>>>>> pid based variant doesn't have such restrictions.
>>>>
>>>> Can you provide more information on usecase requiring PID
>>>> translation but not used for tracing related purposes?
>>>
>>> Any introspection for [nested] containers. It's easier to work when
>>> you have all information when you don't have any.
>>> For example our CMS https://github.com/yandex/porto allows to start
>>> nested sub-container (or even deeper) by request from any container
>>> and have to tell back which pid task is have. And it could translate
>>> any pid inside into accessible by client and vice versa.
>>>
>>
>> I still dont get the exact reason why PID based approach to identify
>> the namespace during pid translation process is absolutely required
>> compared to fd based approach.
>
> As I told open(/proc/%d/ns/pid) have security restrictions - same
> uid/CAP_SYS_PTRACE/whatever
> Pidns-fd holds pid-namespace and without restrictions could be abused.
> Pid based API is racy but always available without any restrictions.
>
>
>> From your version of TranslatePid in
>>
>> https://github.com/yandex/porto/blob/0d7e6e7e1830dcd0038a057b2ab9964cec5b8fab/src/util/unix.cpp
>>
>>
>> I see that you are going through the trouble of forking a process and
>> sending SMC_CREDENTIALS for pid translation. Even your existing API
>> could be extremely simplified if translate_pid based on file
>> descriptors make it to the gate and I believe from the last
>> discussion it was almost there
>> https://patchwork.kernel.org/patch/10305439/
>>
>>
>>>> On a side note, can we have the types TRANSLATE_PID_CURRENT_PIDNS
>>>> and TRANSLATE_PID_FD_PIDNS integrated first and then possibly
>>>> extend the interface to include TRANSLATE_PID_TASK_PIDNS in future?
>>>
>>> I don't see reason for this separation.
>>> Pids and pid namespaces are part of the API for a long time.
>>
>> If you are talking about the translate_pid API proposed, I believe
>> the V4 proposed under https://patchwork.kernel.org/patch/10003935/
>> had only fd based API before a mix of PID and fd based is proposed in
>> V5. Again, I was just wondering if we can get the FD based approach
>> in first and then extend the API to include PID based approach later
>> as fd based approach could provide a lot of immediate benefits?
>>
>> Thanks,
>> Nagarathnam.
>>>
>>>>
>>>> Thanks,
>>>> Nagarathnam.
>>>>> Most pid-based syscalls are racy in some cases but they are
>>>>> here for decades and everybody knowns how to deal with it.
>>>>> So, I've decided to merge both worlds in one interface which
>>>>> clearly tells what to expect.
>>>>
>>
Ping? Any additional comments on this patch?
Thanks,
Nagarathnam.
^ permalink raw reply
* Re: [PATCH 3/6] lib/bucket_locks: use kvmalloc_array()
From: Michal Hocko @ 2018-05-31 15:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Davidlohr Bueso, Andrew Morton, Thomas Graf, Herbert Xu,
Manfred Spraul, guillaume.knispel, Linux API,
Linux Kernel Mailing List, Davidlohr Bueso
In-Reply-To: <CA+55aFyu9HpoHcn0p6uaADOspTd2DKPYciAgHz+C6zwLBvVSJA@mail.gmail.com>
On Thu 31-05-18 10:01:51, Linus Torvalds wrote:
> On Wed, May 30, 2018 at 2:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > That being sad, if you believe that silently fixing up a code like that
> > is a good idea we can do the following of course:
>
> Ack.
>
> Except for:
>
> > Linus argues that this just motivates people to do even
> > more hacks like
> > if (gfp == GFP_KERNEL)
> > kvmalloc
> > else
> > kmalloc
> >
> > I haven't seen this happening but it is true that we can grow those in
> > future.
>
> This whole discussion came from the fact that YES, THIS IS ACTUALLY HAPPENING.
>
> See lib/bucket_locks.c - it just uses gfpflags_allow_blocking()
> instead of explicitly checking for GFP_KERNEL (probably because the
> only two cases it actually deals with is GFP_ATOMIC and GFP_KERNEL).
OK, I haven't noticed this one and will fix it up. So what about the
following?
>From abc6ac9a690060d5ceda79e747c78d24cc7f2951 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Wed, 30 May 2018 09:34:39 +0200
Subject: [PATCH] mm: kvmalloc does not fallback to vmalloc for incompatible
gfp flags
kvmalloc warned about incompatible gfp_mask to catch abusers (mostly
GFP_NOFS) with an intention that this will motivate authors of the code
to fix those. Linus argues that this just motivates people to do even
more hacks like
if (gfp == GFP_KERNEL)
kvmalloc
else
kmalloc
I haven't seen this happening much (bucket_lock special cases an atomic
allocation) but it is true that we can grow those in future. Therefore
Linus suggested to simply not fallback to vmalloc for incompatible gfp
flags and rather stick with the kmalloc path.
Requested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
lib/bucket_locks.c | 5 +----
mm/util.c | 6 ++++--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/lib/bucket_locks.c b/lib/bucket_locks.c
index 266a97c5708b..ade3ce6c4af6 100644
--- a/lib/bucket_locks.c
+++ b/lib/bucket_locks.c
@@ -30,10 +30,7 @@ int alloc_bucket_spinlocks(spinlock_t **locks, unsigned int *locks_mask,
}
if (sizeof(spinlock_t) != 0) {
- if (gfpflags_allow_blocking(gfp))
- tlocks = kvmalloc(size * sizeof(spinlock_t), gfp);
- else
- tlocks = kmalloc_array(size, sizeof(spinlock_t), gfp);
+ tlocks = kvmalloc_array(size, sizeof(spinlock_t), gfp);
if (!tlocks)
return -ENOMEM;
for (i = 0; i < size; i++)
diff --git a/mm/util.c b/mm/util.c
index 45fc3169e7b0..c6586c146995 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -391,7 +391,8 @@ EXPORT_SYMBOL(vm_mmap);
* __GFP_RETRY_MAYFAIL is supported, and it should be used only if kmalloc is
* preferable to the vmalloc fallback, due to visible performance drawbacks.
*
- * Any use of gfp flags outside of GFP_KERNEL should be consulted with mm people.
+ * Please note that any use of gfp flags outside of GFP_KERNEL is careful to not
+ * fall back to vmalloc.
*/
void *kvmalloc_node(size_t size, gfp_t flags, int node)
{
@@ -402,7 +403,8 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
* vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
* so the given set of flags has to be compatible.
*/
- WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
+ if ((flags & GFP_KERNEL) != GFP_KERNEL)
+ return kmalloc_node(size, flags, node);
/*
* We want to attempt a large physically contiguous block first because
--
2.17.0
--
Michal Hocko
SUSE Labs
^ permalink raw reply related
* Re: [PATCH 3/6] lib/bucket_locks: use kvmalloc_array()
From: Linus Torvalds @ 2018-05-31 15:01 UTC (permalink / raw)
To: Michal Hocko
Cc: Davidlohr Bueso, Andrew Morton, Thomas Graf, Herbert Xu,
Manfred Spraul, guillaume.knispel, Linux API,
Linux Kernel Mailing List, Davidlohr Bueso
In-Reply-To: <20180530074216.GZ27180@dhcp22.suse.cz>
On Wed, May 30, 2018 at 2:42 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> That being sad, if you believe that silently fixing up a code like that
> is a good idea we can do the following of course:
Ack.
Except for:
> Linus argues that this just motivates people to do even
> more hacks like
> if (gfp == GFP_KERNEL)
> kvmalloc
> else
> kmalloc
>
> I haven't seen this happening but it is true that we can grow those in
> future.
This whole discussion came from the fact that YES, THIS IS ACTUALLY HAPPENING.
See lib/bucket_locks.c - it just uses gfpflags_allow_blocking()
instead of explicitly checking for GFP_KERNEL (probably because the
only two cases it actually deals with is GFP_ATOMIC and GFP_KERNEL).
Linus
^ permalink raw reply
* Re: [RFC PATCH ghak32 V2 00/13] audit: implement container id
From: Richard Guy Briggs @ 2018-05-30 17:33 UTC (permalink / raw)
To: Steve Grubb
Cc: simo, jlayton, carlos, linux-api, containers, LKML, eparis,
dhowells, linux-audit, ebiederm, luto, netdev, linux-fsdevel,
cgroups, serge, viro
In-Reply-To: <23151436.iBN3rkXKiY@x2>
On 2018-05-30 09:20, Steve Grubb wrote:
> On Friday, March 16, 2018 5:00:27 AM EDT Richard Guy Briggs wrote:
> > Implement audit kernel container ID.
> >
> > This patchset is a second RFC based on the proposal document (V3)
> > posted:
> > https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html
>
> So, if you work on a container orchestrator, how exactly is this set of
> interfaces to be used and in what order?
It was designed keeping in mind the Virtuallization Manager Guest
Lifecycle Events document.
https://github.com/linux-audit/audit-documentation/wiki/SPEC-Virtualization-Manager-Guest-Lifecycle-Events
The orchestrator would start setting things up and when it knows the PID
of the conainer task but before that task has had a chance to thread or
spawn children it registers the audit container ID via the /proc
interface. After that, it consults audit for any events maching that
ID.
> Thanks,
> -Steve
>
> > The first patch implements the proc fs write to set the audit container
> > ID of a process, emitting an AUDIT_CONTAINER record to announce the
> > registration of that container ID on that process. This patch requires
> > userspace support for record acceptance and proper type display.
> >
> > The second checks for children or co-threads and refuses to set the
> > container ID if either are present. (This policy could be changed to
> > set both with the same container ID provided they meet the rest of the
> > requirements.)
> >
> > The third implements the auxiliary record AUDIT_CONTAINER_INFO if a
> > container ID is identifiable with an event. This patch requires
> > userspace support for proper type display.
> >
> > The fourth adds container ID filtering to the exit, exclude and user
> > lists. This patch requires auditctil userspace support for the
> > --containerid option.
> >
> > The 5th adds signal and ptrace support.
> >
> > The 6th creates a local audit context to be able to bind a standalone
> > record with a locally created auxiliary record.
> >
> > The 7th, 8th, 9th, 10th patches add container ID records to standalone
> > records. Some of these may end up being syscall auxiliary records and
> > won't need this specific support since they'll be supported via
> > syscalls.
> >
> > The 11th adds network namespace container ID labelling based on member
> > tasks' container ID labels.
> >
> > The 12th adds container ID support to standalone netfilter records that
> > don't have a task context and lists each container to which that net
> > namespace belongs.
> >
> > The 13th implements reading the container ID from the proc filesystem
> > for debugging. This patch isn't planned for upstream inclusion.
> >
> > Feedback please!
> >
> > Example: Set a container ID of 123456 to the "sleep" task:
> > sleep 2&
> > child=$!
> > echo 123456 > /proc/$child/containerid; echo $?
> > ausearch -ts recent -m container
> > echo child:$child contid:$( cat /proc/$child/containerid)
> > This should produce a record such as:
> > type=CONTAINER msg=audit(1521122590.315:222): op=set pid=689 uid=0
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 auid=0 tty=pts0
> > ses=3 opid=707 old-contid=18446744073709551615 contid=123456 res=1
> >
> > Example: Set a filter on a container ID 123459 on /tmp/tmpcontainerid:
> > containerid=123459
> > key=tmpcontainerid
> > auditctl -a exit,always -F dir=/tmp -F perm=wa -F containerid=$containerid
> > -F key=$key perl -e "sleep 1; open(my \$tmpfile, '>', \"/tmp/$key\");
> > close(\$tmpfile);" & child=$!
> > echo $containerid > /proc/$child/containerid
> > sleep 2
> > ausearch -i -ts recent -k $key
> > auditctl -d exit,always -F dir=/tmp -F perm=wa -F containerid=$containerid
> > -F key=$key rm -f /tmp/$key
> > This should produce an event such as:
> > type=CONTAINER_INFO msg=audit(1521122591.614:227): op=task contid=123459
> > type=PROCTITLE msg=audit(1521122591.614:227):
> > proctitle=7065726C002D6500736C65657020313B206F70656E286D792024746D7066696C
> > 652C20273E272C20222F746D702F746D70636F6E7461696E6572696422293B20636C6F73652
> > 824746D7066696C65293B type=PATH msg=audit(1521122591.614:227): item=1
> > name="/tmp/tmpcontainerid" inode=18427 dev=00:26 mode=0100644 ouid=0
> > ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE
> > cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> > type=PATH msg=audit(1521122591.614:227): item=0 name="/tmp/" inode=13513
> > dev=00:26 mode=041777 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=0000000000000000
> > cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD
> > msg=audit(1521122591.614:227): cwd="/root"
> > type=SYSCALL msg=audit(1521122591.614:227): arch=c000003e syscall=257
> > success=yes exit=3 a0=ffffffffffffff9c a1=55db90a28900 a2=241 a3=1b6
> > items=2 ppid=689 pid=724 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > sgid=0 fsgid=0 tty=pts0 ses=3 comm="perl" exe="/usr/bin/perl"
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > key="tmpcontainerid"
> >
> > See:
> > https://github.com/linux-audit/audit-kernel/issues/32
> > https://github.com/linux-audit/audit-userspace/issues/40
> > https://github.com/linux-audit/audit-testsuite/issues/64
> >
> > Richard Guy Briggs (13):
> > audit: add container id
> > audit: check children and threading before allowing containerid
> > audit: log container info of syscalls
> > audit: add containerid filtering
> > audit: add containerid support for ptrace and signals
> > audit: add support for non-syscall auxiliary records
> > audit: add container aux record to watch/tree/mark
> > audit: add containerid support for tty_audit
> > audit: add containerid support for config/feature/user records
> > audit: add containerid support for seccomp and anom_abend records
> > audit: add support for containerid to network namespaces
> > audit: NETFILTER_PKT: record each container ID associated with a netNS
> > debug audit: read container ID of a process
> >
> > drivers/tty/tty_audit.c | 5 +-
> > fs/proc/base.c | 53 ++++++++++++++++
> > include/linux/audit.h | 43 +++++++++++++
> > include/linux/init_task.h | 4 +-
> > include/linux/sched.h | 1 +
> > include/net/net_namespace.h | 12 ++++
> > include/uapi/linux/audit.h | 8 ++-
> > kernel/audit.c | 75 ++++++++++++++++++++---
> > kernel/audit.h | 3 +
> > kernel/audit_fsnotify.c | 5 +-
> > kernel/audit_tree.c | 5 +-
> > kernel/audit_watch.c | 33 +++++-----
> > kernel/auditfilter.c | 52 +++++++++++++++-
> > kernel/auditsc.c | 145
> > ++++++++++++++++++++++++++++++++++++++++++-- kernel/nsproxy.c |
> > 6 ++
> > net/core/net_namespace.c | 45 ++++++++++++++
> > net/netfilter/xt_AUDIT.c | 15 ++++-
> > 17 files changed, 473 insertions(+), 37 deletions(-)
>
>
>
>
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH 2/6] lib/rhashtable: guarantee initial hashtable allocation
From: Davidlohr Bueso @ 2018-05-30 14:29 UTC (permalink / raw)
To: Herbert Xu
Cc: akpm, torvalds, tgraf, manfred, guillaume.knispel, linux-api,
linux-kernel, Davidlohr Bueso
In-Reply-To: <20180529182746.t4b7tsnfma7dupom@gondor.apana.org.au>
On Wed, 30 May 2018, Herbert Xu wrote:
>On Tue, May 29, 2018 at 10:59:27AM -0700, Davidlohr Bueso wrote:
>That's exactly what you need to explain in the patch or the commit
>message. In fact you still haven't explained it fully. Why do we
>need a second attempt without the GFP_NOFAIL? How does it help the
>allocator?
It helps in that we have two fastpath attempts before going in to
__alloc_pages_slowpath() and looping in __GFP_NOFAIL. But yeah, I
see your point. We can just apply KISS and avoid the extra alloc.
That actually makes more sense to me now than ignoring min_size
based on simplicity.
Thanks for the review.
Thanks,
Davidlohr
^ permalink raw reply
* Re: [RFC PATCH ghak32 V2 00/13] audit: implement container id
From: Steve Grubb @ 2018-05-30 13:20 UTC (permalink / raw)
To: linux-audit-H+wXaHxf7aLQT0dZR+AlfA
Cc: simo-H+wXaHxf7aLQT0dZR+AlfA, jlayton-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
eparis-FjpueFixGhCM4zKIHC2jIg, dhowells-H+wXaHxf7aLQT0dZR+AlfA,
carlos-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
luto-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn
In-Reply-To: <cover.1521179281.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Friday, March 16, 2018 5:00:27 AM EDT Richard Guy Briggs wrote:
> Implement audit kernel container ID.
>
> This patchset is a second RFC based on the proposal document (V3)
> posted:
> https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html
So, if you work on a container orchestrator, how exactly is this set of
interfaces to be used and in what order?
Thanks,
-Steve
> The first patch implements the proc fs write to set the audit container
> ID of a process, emitting an AUDIT_CONTAINER record to announce the
> registration of that container ID on that process. This patch requires
> userspace support for record acceptance and proper type display.
>
> The second checks for children or co-threads and refuses to set the
> container ID if either are present. (This policy could be changed to
> set both with the same container ID provided they meet the rest of the
> requirements.)
>
> The third implements the auxiliary record AUDIT_CONTAINER_INFO if a
> container ID is identifiable with an event. This patch requires
> userspace support for proper type display.
>
> The fourth adds container ID filtering to the exit, exclude and user
> lists. This patch requires auditctil userspace support for the
> --containerid option.
>
> The 5th adds signal and ptrace support.
>
> The 6th creates a local audit context to be able to bind a standalone
> record with a locally created auxiliary record.
>
> The 7th, 8th, 9th, 10th patches add container ID records to standalone
> records. Some of these may end up being syscall auxiliary records and
> won't need this specific support since they'll be supported via
> syscalls.
>
> The 11th adds network namespace container ID labelling based on member
> tasks' container ID labels.
>
> The 12th adds container ID support to standalone netfilter records that
> don't have a task context and lists each container to which that net
> namespace belongs.
>
> The 13th implements reading the container ID from the proc filesystem
> for debugging. This patch isn't planned for upstream inclusion.
>
> Feedback please!
>
> Example: Set a container ID of 123456 to the "sleep" task:
> sleep 2&
> child=$!
> echo 123456 > /proc/$child/containerid; echo $?
> ausearch -ts recent -m container
> echo child:$child contid:$( cat /proc/$child/containerid)
> This should produce a record such as:
> type=CONTAINER msg=audit(1521122590.315:222): op=set pid=689 uid=0
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 auid=0 tty=pts0
> ses=3 opid=707 old-contid=18446744073709551615 contid=123456 res=1
>
> Example: Set a filter on a container ID 123459 on /tmp/tmpcontainerid:
> containerid=123459
> key=tmpcontainerid
> auditctl -a exit,always -F dir=/tmp -F perm=wa -F containerid=$containerid
> -F key=$key perl -e "sleep 1; open(my \$tmpfile, '>', \"/tmp/$key\");
> close(\$tmpfile);" & child=$!
> echo $containerid > /proc/$child/containerid
> sleep 2
> ausearch -i -ts recent -k $key
> auditctl -d exit,always -F dir=/tmp -F perm=wa -F containerid=$containerid
> -F key=$key rm -f /tmp/$key
> This should produce an event such as:
> type=CONTAINER_INFO msg=audit(1521122591.614:227): op=task contid=123459
> type=PROCTITLE msg=audit(1521122591.614:227):
> proctitle=7065726C002D6500736C65657020313B206F70656E286D792024746D7066696C
> 652C20273E272C20222F746D702F746D70636F6E7461696E6572696422293B20636C6F73652
> 824746D7066696C65293B type=PATH msg=audit(1521122591.614:227): item=1
> name="/tmp/tmpcontainerid" inode=18427 dev=00:26 mode=0100644 ouid=0
> ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE
> cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> type=PATH msg=audit(1521122591.614:227): item=0 name="/tmp/" inode=13513
> dev=00:26 mode=041777 ouid=0 ogid=0 rdev=00:00
> obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=0000000000000000
> cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD
> msg=audit(1521122591.614:227): cwd="/root"
> type=SYSCALL msg=audit(1521122591.614:227): arch=c000003e syscall=257
> success=yes exit=3 a0=ffffffffffffff9c a1=55db90a28900 a2=241 a3=1b6
> items=2 ppid=689 pid=724 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts0 ses=3 comm="perl" exe="/usr/bin/perl"
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> key="tmpcontainerid"
>
> See:
> https://github.com/linux-audit/audit-kernel/issues/32
> https://github.com/linux-audit/audit-userspace/issues/40
> https://github.com/linux-audit/audit-testsuite/issues/64
>
> Richard Guy Briggs (13):
> audit: add container id
> audit: check children and threading before allowing containerid
> audit: log container info of syscalls
> audit: add containerid filtering
> audit: add containerid support for ptrace and signals
> audit: add support for non-syscall auxiliary records
> audit: add container aux record to watch/tree/mark
> audit: add containerid support for tty_audit
> audit: add containerid support for config/feature/user records
> audit: add containerid support for seccomp and anom_abend records
> audit: add support for containerid to network namespaces
> audit: NETFILTER_PKT: record each container ID associated with a netNS
> debug audit: read container ID of a process
>
> drivers/tty/tty_audit.c | 5 +-
> fs/proc/base.c | 53 ++++++++++++++++
> include/linux/audit.h | 43 +++++++++++++
> include/linux/init_task.h | 4 +-
> include/linux/sched.h | 1 +
> include/net/net_namespace.h | 12 ++++
> include/uapi/linux/audit.h | 8 ++-
> kernel/audit.c | 75 ++++++++++++++++++++---
> kernel/audit.h | 3 +
> kernel/audit_fsnotify.c | 5 +-
> kernel/audit_tree.c | 5 +-
> kernel/audit_watch.c | 33 +++++-----
> kernel/auditfilter.c | 52 +++++++++++++++-
> kernel/auditsc.c | 145
> ++++++++++++++++++++++++++++++++++++++++++-- kernel/nsproxy.c |
> 6 ++
> net/core/net_namespace.c | 45 ++++++++++++++
> net/netfilter/xt_AUDIT.c | 15 ++++-
> 17 files changed, 473 insertions(+), 37 deletions(-)
^ permalink raw reply
* Re: [PATCH 3/6] lib/bucket_locks: use kvmalloc_array()
From: Michal Hocko @ 2018-05-30 7:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Davidlohr Bueso, Andrew Morton, Thomas Graf, Herbert Xu,
Manfred Spraul, guillaume.knispel, Linux API,
Linux Kernel Mailing List, Davidlohr Bueso
In-Reply-To: <CA+55aFxoC0+hKBQ_TmbXM_X60fnP8JKC3aVvGc=8bKh2oxL12g@mail.gmail.com>
On Tue 29-05-18 15:46:25, Linus Torvalds wrote:
[...]
> The whole and ONLY point of "kvmalloc()" and friends is to make it easy to
> write code and _not_ have those idiotic "let's do kmalloc or kvmalloc
> depending on the phase of the moon" garbage. So the warning has literally
> destroyed the only value that function has!
Well, I do agree but I've also seen terrible things while doing the
conversion when introducing kvmalloc.
So I admit that the defensive mode here is mostly inspired by existing
users of vmalloc(GFP_NOFS). They are simply wrong and not really
eager to be fixed from my experience. Now with kvmalloc fixing them
up silently it would get even less likely to get fixed because there
won't be any deadlock possible (compared to open coded kvmalloc like
ext4_kvmalloc for example).
My experience also tells me that most of those vmalloc NOFS users
simply do not need NOFS at all because there is no risk of the reclaim
recursion deadlocks. They are just used because of cargo cult which is
sad and it causes some subtle problems for the direct reclaim. I would
really like to eliminate those (e.g. see [1]). It is sad reality that
people tend to be more sensitive to WARN splats than "look this is wrong
albeit not critical in most cases).
[1] http://lkml.kernel.org/r/20180424162712.GL17484@dhcp22.suse.cz
That being sad, if you believe that silently fixing up a code like that
is a good idea we can do the following of course:
>From c1a098e809a109800f9cfa63cb27fe9a78f3f316 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Wed, 30 May 2018 09:34:39 +0200
Subject: [PATCH] mm: kvmalloc does not fallback to vmalloc for incompatible
gfp flags
kvmalloc warned about incompatible gfp_mask to catch abusers (mostly
GFP_NOFS) with an intention that this will motivate authors of the code
to fix those. Linus argues that this just motivates people to do even
more hacks like
if (gfp == GFP_KERNEL)
kvmalloc
else
kmalloc
I haven't seen this happening but it is true that we can grow those in
future. Therefore Linus suggested to simply not fallback to vmalloc for
incompatible gfp flags and rather stick with the kmalloc path.
Requested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
mm/util.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/util.c b/mm/util.c
index 45fc3169e7b0..c6586c146995 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -391,7 +391,8 @@ EXPORT_SYMBOL(vm_mmap);
* __GFP_RETRY_MAYFAIL is supported, and it should be used only if kmalloc is
* preferable to the vmalloc fallback, due to visible performance drawbacks.
*
- * Any use of gfp flags outside of GFP_KERNEL should be consulted with mm people.
+ * Please note that any use of gfp flags outside of GFP_KERNEL is careful to not
+ * fall back to vmalloc.
*/
void *kvmalloc_node(size_t size, gfp_t flags, int node)
{
@@ -402,7 +403,8 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
* vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
* so the given set of flags has to be compatible.
*/
- WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
+ if ((flags & GFP_KERNEL) != GFP_KERNEL)
+ return kmalloc_node(size, flags, node);
/*
* We want to attempt a large physically contiguous block first because
--
2.17.0
--
Michal Hocko
SUSE Labs
^ permalink raw reply related
* Re: [PATCH 3/6] lib/bucket_locks: use kvmalloc_array()
From: Linus Torvalds @ 2018-05-29 20:46 UTC (permalink / raw)
To: Michal Hocko
Cc: Davidlohr Bueso, Andrew Morton, Thomas Graf, Herbert Xu,
Manfred Spraul, guillaume.knispel, Linux API,
Linux Kernel Mailing List, Davidlohr Bueso
In-Reply-To: <20180529145106.GV27180@dhcp22.suse.cz>
On Tue, May 29, 2018 at 9:51 AM Michal Hocko <mhocko@kernel.org> wrote:
> In other words, what about the following?
> + WARN_ON_ONCE((flags & (__GFP_FS|__GFP_IO)) !=
(__GFP_FS|__GFP_IO));
I still don't understand the point of this warning.
It's only stupid. It basically says "this function is garbage, so let me
warn about the fact that I'm a moron".
If we all needed to warn about ourselves being morons, there would be a
hell of a lot of big blinking signs everywhere.
And the *ONLY* thing that warning has ever caused is just stupid code that
does
if (flags == GFP_KERNEL)
.. do kvmalloc ..
else
.. do kmalloc() ..
which is a *STUPID* pattern.
In other words, the WARN_ON() is bogus garbage. It's bogus exactly because
NOBODY CARES and all everybody will ever do is to just avoid it by writing
worse code.
The whole and ONLY point of "kvmalloc()" and friends is to make it easy to
write code and _not_ have those idiotic "let's do kmalloc or kvmalloc
depending on the phase of the moon" garbage. So the warning has literally
destroyed the only value that function has!
> + if (!gfpflags_allow_blocking(flags))
> + return NULL;
> +
And no. Now all the code *above* this check is just wrong. All the code
that modifies the gfp_flags with the intention of falling back on vmalloc()
is just wrong, since we're not falling back on vmalloc any more.
So I really think the semantics should be simple:
- if we don't allow GFP_KERNEL, then the code becomes just "kmalloc()",
since there is no valid fallback to vmalloc. vmalloc does GFP_KERNEL.
- otherwise, we do what we used to do (except now the warning is gone,
because we already handled the case it warned about).
Nothing else. No stupid other cases. The *only* thing that function should
ask itself is "can I fall back on vmalloc or not", and if it can't then it
should just be a kmalloc.
Because otherwise we'll continue to have people that just check in the
caller instead.
Linus
^ permalink raw reply
* Re: [patch v25 0/4] JTAG driver introduction
From: Andy Shevchenko @ 2018-05-29 20:40 UTC (permalink / raw)
To: Oleksandr Shamray
Cc: Greg Kroah-Hartman, Arnd Bergmann, Linux Kernel Mailing List,
linux-arm Mailing List, devicetree, openbmc, Joel Stanley,
Jiří Pírko, Tobias Klauser,
open list:SERIAL DRIVERS, Vadim Pasternak, system-sw-low-level,
Rob Herring, openocd-devel-owner, linux-api, David S. Miller,
Mauro Carvalho Chehab
In-Reply-To: <1527605618-15705-1-git-send-email-oleksandrs@mellanox.com>
On Tue, May 29, 2018 at 5:53 PM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
Please, STOP spamming mailing lists. Give (potential) reviewers time
to look at this.
In any case you already missed a next cycle, so, calm down and better
collect reports and address comments thoroughly.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [patch v22 1/4] drivers: jtag: Add JTAG core driver
From: kbuild test robot @ 2018-05-29 20:08 UTC (permalink / raw)
Cc: kbuild-all, gregkh, arnd, linux-kernel, linux-arm-kernel,
devicetree, openbmc, joel, jiri, tklauser, linux-serial, vadimp,
system-sw-low-level, robh+dt, openocd-devel-owner, linux-api,
davem, mchehab, Oleksandr Shamray
In-Reply-To: <1527503652-21975-2-git-send-email-oleksandrs@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]
Hi Oleksandr,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc7 next-20180529]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Oleksandr-Shamray/JTAG-driver-introduction/20180529-195609
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh
All errors (new ones prefixed by >>):
>> drivers/jtag/jtag.c:288:13: error: static declaration of 'devm_jtag_unregister' follows non-static declaration
static void devm_jtag_unregister(struct device *dev, void *res)
^~~~~~~~~~~~~~~~~~~~
In file included from drivers/jtag/jtag.c:9:0:
include/linux/jtag.h:38:6: note: previous declaration of 'devm_jtag_unregister' was here
void devm_jtag_unregister(struct device *dev, void *res);
^~~~~~~~~~~~~~~~~~~~
vim +/devm_jtag_unregister +288 drivers/jtag/jtag.c
287
> 288 static void devm_jtag_unregister(struct device *dev, void *res)
289 {
290 jtag_unregister(*(struct jtag **)res);
291 }
292
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47739 bytes --]
^ permalink raw reply
* Re: [patch v25 4/4] Documentation: jtag: Add ABI documentation
From: Randy Dunlap @ 2018-05-29 18:54 UTC (permalink / raw)
To: Oleksandr Shamray, gregkh, arnd
Cc: system-sw-low-level, devicetree, jiri, vadimp, linux-api, openbmc,
linux-kernel, openocd-devel-owner, robh+dt, joel, linux-serial,
tklauser, mchehab, davem, linux-arm-kernel
In-Reply-To: <1527605618-15705-5-git-send-email-oleksandrs@mellanox.com>
On 05/29/2018 07:53 AM, Oleksandr Shamray wrote:
> Added document that describe the ABI for JTAG class drivrer
Sorry, there are still a few typos. Please see below.
> ---
> Documentation/ABI/testing/gpio-cdev | 1 -
> Documentation/ABI/testing/jtag-dev | 23 +++++++
> Documentation/jtag/overview | 27 +++++++++
> Documentation/jtag/transactions | 109 +++++++++++++++++++++++++++++++++++
> MAINTAINERS | 1 +
> 5 files changed, 160 insertions(+), 1 deletions(-)
> create mode 100644 Documentation/ABI/testing/jtag-dev
> create mode 100644 Documentation/jtag/overview
> create mode 100644 Documentation/jtag/transactions
>
> diff --git a/Documentation/jtag/overview b/Documentation/jtag/overview
> new file mode 100644
> index 0000000..f179095
> --- /dev/null
> +++ b/Documentation/jtag/overview
> @@ -0,0 +1,27 @@
> +Linux kernel JTAG support
> +=========================
> +
> +JTAG is an industry standard for verifying hardware.JTAG provides access to
needs space:
hardware. JTAG provides
> +many logic signals of a complex integrated circuit, including the device pins.
> +
> +A JTAG interface is a special interface added to a chip.
> +Depending on the version of JTAG, two, four, or five pins are added.
> +
> +The connector pins are:
> + TDI (Test Data In)
> + TDO (Test Data Out)
> + TCK (Test Clock)
> + TMS (Test Mode Select)
> + TRST (Test Reset) optional
> +
> +JTAG interface is designed to have two parts - basic core driver and
> +hardware specific driver. The basic driver introduces a general interface
> +which is not dependent of specific hardware. It provides communication
> +between user space and hardware specific driver.
> +Each JTAG device is represented as a char device from (jtag0, jtag1, ...).
> +Access to a JTAG device is performed through IOCTL calls.
> +
> +Call flow example:
> +User: open -> /dev/jatgX
> +User: ioctl -> /dev/jtagX -> JTAG core driver -> JTAG hardware specific driver
> +User: close -> /dev/jatgX
> diff --git a/Documentation/jtag/transactions b/Documentation/jtag/transactions
> new file mode 100644
> index 0000000..c5176a7
> --- /dev/null
> +++ b/Documentation/jtag/transactions
> @@ -0,0 +1,109 @@
> +The JTAG API
> +=============
> +
> +JTAG master devices can be accessed through a character misc-device.
> +Each JTAG master interface can be accessed by using /dev/jtagN.
> +
> +JTAG system calls set:
> +- SIR (Scan Instruction Register, IEEE 1149.1 Instruction Register scan);
> +- SDR (Scan Data Register, IEEE 1149.1 Data Register scan);
> +- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
> +number of clocks.
> +
> +open(), close()
> +-------
> +open() opens JTAG device.
> +
> +Open/Close device:
> +- jtag_fd = open("/dev/jtag0", O_RDWR);
> +- close(jtag_fd);
> +
> +ioctl()
> +-------
> +All access operations to JTAG devices are erformed through ioctl interface.
performed
> +The IOCTL interface supports these requests:
> + JTAG_IOCRUNTEST - Force JTAG state machine to RUN_TEST/IDLE state
> + JTAG_SIOCFREQ - Set JTAG TCK frequency
> + JTAG_GIOCFREQ - Get JTAG TCK frequency
> + JTAG_IOCXFER - send JTAG data Xfer
> + JTAG_GIOCSTATUS - get current JTAG TAP status
> + JTAG_SIOCMODE - set JTAG mode flags.
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/6] lib/rhashtable: guarantee initial hashtable allocation
From: Herbert Xu @ 2018-05-29 18:27 UTC (permalink / raw)
To: Davidlohr Bueso
Cc: akpm, torvalds, tgraf, manfred, guillaume.knispel, linux-api,
linux-kernel, Davidlohr Bueso
In-Reply-To: <20180529175927.iyea653hpgnow6p2@linux-n805>
On Tue, May 29, 2018 at 10:59:27AM -0700, Davidlohr Bueso wrote:
> On Wed, 30 May 2018, Herbert Xu wrote:
>
> > It doesn't explain it at all. In fact I don't see why we neeed
> > three attempts, just do the GFP_NOFAIL as the second and final step.
>
> Second attempt is reduced size only as we don't want to GFP_NOFAIL
> if we can avoid it helping the allocator. We go from an arbitrary
> allocation to the smallest possible allocation, if all that fails
> ok lets use GFP_NOFAIL. I don't know how this is not clear...
That's exactly what you need to explain in the patch or the commit
message. In fact you still haven't explained it fully. Why do we
need a second attempt without the GFP_NOFAIL? How does it help the
allocator?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox