linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: michael.christie@oracle.com
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, mst@redhat.com,
	sgarzare@redhat.com, jasowang@redhat.com, stefanha@redhat.com,
	christian@brauner.io, akpm@linux-foundation.org,
	peterz@infradead.org
Subject: Re: [PATCH 2/3] kernel/fork, cred.c: allow copy_process to take user
Date: Thu, 1 Jul 2021 18:59:13 -0500	[thread overview]
Message-ID: <2cbbebab-e9cf-0833-c0de-31eb3ba6cd5e@oracle.com> (raw)
In-Reply-To: <6927dc85-6f8d-c1f5-f92d-9bcd36cce2bb@oracle.com>

On 6/29/21 11:53 AM, Mike Christie wrote:
> On 6/29/21 8:04 AM, Christian Brauner wrote:
>> On Wed, Jun 23, 2021 at 10:08:03PM -0500, Mike Christie wrote:
>>> This allows kthread to pass copy_process the user we want to check for the
>>> RLIMIT_NPROC limit for and also charge for the new process. It will be used
>>> by vhost where userspace has that driver create threads but the kthreadd
>>> thread is checked/charged.
>>>
>>> Signed-off-by: Mike Christie <michael.christie@oracle.com>
>>> ---
>>>  include/linux/cred.h |  3 ++-
>>>  kernel/cred.c        |  7 ++++---
>>>  kernel/fork.c        | 12 +++++++-----
>>>  3 files changed, 13 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/include/linux/cred.h b/include/linux/cred.h
>>> index 14971322e1a0..9a2c1398cdd4 100644
>>> --- a/include/linux/cred.h
>>> +++ b/include/linux/cred.h
>>> @@ -153,7 +153,8 @@ struct cred {
>>>  
>>>  extern void __put_cred(struct cred *);
>>>  extern void exit_creds(struct task_struct *);
>>> -extern int copy_creds(struct task_struct *, unsigned long);
>>> +extern int copy_creds(struct task_struct *, unsigned long,
>>> +		      struct user_struct *);
>>>  extern const struct cred *get_task_cred(struct task_struct *);
>>>  extern struct cred *cred_alloc_blank(void);
>>>  extern struct cred *prepare_creds(void);
>>> diff --git a/kernel/cred.c b/kernel/cred.c
>>> index e1d274cd741b..e006aafa8f05 100644
>>> --- a/kernel/cred.c
>>> +++ b/kernel/cred.c
>>> @@ -330,7 +330,8 @@ struct cred *prepare_exec_creds(void)
>>>   * The new process gets the current process's subjective credentials as its
>>>   * objective and subjective credentials
>>>   */
>>> -int copy_creds(struct task_struct *p, unsigned long clone_flags)
>>> +int copy_creds(struct task_struct *p, unsigned long clone_flags,
>>> +	       struct user_struct *user)
>>>  {
>>>  	struct cred *new;
>>>  	int ret;
>>> @@ -351,7 +352,7 @@ int copy_creds(struct task_struct *p, unsigned long clone_flags)
>>>  		kdebug("share_creds(%p{%d,%d})",
>>>  		       p->cred, atomic_read(&p->cred->usage),
>>>  		       read_cred_subscribers(p->cred));
>>> -		atomic_inc(&p->cred->user->processes);
>>> +		atomic_inc(&user->processes);
>>
>> Hey Mike,
>>
>> This won't work anymore since this has moved into ucounts. So in v5.14
>> atomic_inc(&p->cred->user->processes);
>> will have been replaced by
>> inc_rlimit_ucounts(task_ucounts(p), UCOUNT_RLIMIT_NPROC, 1);
>>
> Will do.
> 
>> From what I can see from your code vhost will always create this kthread
>> for current. So you could e.g. add an internal flag/bitfield entry to
>> struct kernel_clone_args that you can use to tell copy_creds() that you
>> want to charge this thread against current's process limit.
> 
> If I understood you, I don't think a flag/bit will work. When vhost does
> a kthread call we do kthread_create -> __kthread_create_on_node. This creates
> a tmp kthread_create_info struct and adds it to the kthread_create_list list.
> It then wakes up the kthreadd thread. kthreadd will then loop over the list,
> and do the:
> 
> kernel_thread -> kernel_clone -> copy_process ->  copy_creds
> 
> So copy_creds sees current == kthreadd.
> 
> I think I would have to add a task_struct pointer to kernel_clone_args
> and kthread_create_info. If copy_creds sees kernel_clone_args->user_task
> then it would use that.

One question/clarification. For 5.14, I could pass in the struct task_struct
or struct ucounts (in a previous mail I wrote user_struct).

I could also just have vhost.c do inc_rlimit_ucounts and is_ucounts_overlimit
directly.



  reply	other threads:[~2021-07-01 23:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24  3:08 [PATCH 0/3] kthread: pass in user and check RLIMIT_NPROC Mike Christie
2021-06-24  3:08 ` [PATCH 1/3] kthread: allow caller to pass in user_struct Mike Christie
2021-06-24  4:34   ` kernel test robot
2021-06-24 16:19     ` Mike Christie
2021-06-24  3:08 ` [PATCH 2/3] kernel/fork, cred.c: allow copy_process to take user Mike Christie
2021-06-29 13:04   ` Christian Brauner
2021-06-29 16:53     ` Mike Christie
2021-07-01 23:59       ` michael.christie [this message]
2021-06-24  3:08 ` [PATCH 3/3] vhost: pass kthread user to check RLIMIT_NPROC Mike Christie
2021-06-24  8:26   ` kernel test robot
2021-06-24 16:18     ` Mike Christie
2021-06-24  7:34 ` [PATCH 0/3] kthread: pass in user and " Michael S. Tsirkin
2021-06-24  9:40 ` Stefan Hajnoczi

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=2cbbebab-e9cf-0833-c0de-31eb3ba6cd5e@oracle.com \
    --to=michael.christie@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=christian@brauner.io \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.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;
as well as URLs for NNTP newsgroup(s).