All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] KEYS: reaching the keys quotas correctly when instanttiating
@ 2020-02-27 10:25 Yang Xu
  2020-02-27 16:26 ` Jarkko Sakkinen
  0 siblings, 1 reply; 16+ messages in thread
From: Yang Xu @ 2020-02-27 10:25 UTC (permalink / raw)
  To: dhowells

I wrote a regression test[1]to test commit a08bf91ce28ed
("KEYS: allow reaching the keys quotas exactly"), but it
failed even I used lastest kernel. It looks like the previous
patch doesn't remove "=" when we instantiate the key.

[1]http://lists.linux.it/pipermail/ltp/2020-February/015331.html

Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
---
 security/keys/key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/keys/key.c b/security/keys/key.c
index 718bf7217420..e959b3c96b48 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -382,7 +382,7 @@ int key_payload_reserve(struct key *key, size_t datalen)
 		spin_lock(&key->user->lock);
 
 		if (delta > 0 &&
-		    (key->user->qnbytes + delta >= maxbytes ||
+		    (key->user->qnbytes + delta > maxbytes ||
 		     key->user->qnbytes + delta < key->user->qnbytes)) {
 			ret = -EDQUOT;
 		}
-- 
2.18.0

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH] KEYS: reaching the keys quotas correctly when instanttiating
  2020-02-27 10:25 [PATCH] KEYS: reaching the keys quotas correctly when instanttiating Yang Xu
@ 2020-02-27 16:26 ` Jarkko Sakkinen
  2020-02-28  2:32   ` [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly Yang Xu
  0 siblings, 1 reply; 16+ messages in thread
From: Jarkko Sakkinen @ 2020-02-27 16:26 UTC (permalink / raw)
  To: keyrings

On Thu, Feb 27, 2020 at 06:25:45PM +0800, Yang Xu wrote:
> I wrote a regression test[1]to test commit a08bf91ce28ed
> ("KEYS: allow reaching the keys quotas exactly"), but it
> failed even I used lastest kernel. It looks like the previous
> patch doesn't remove "=" when we instantiate the key.
> 
> [1]http://lists.linux.it/pipermail/ltp/2020-February/015331.html
> 
> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>

1. Describe the failure and how this patch fixes in the commit
   message.
2. Add a fixes tag.

/Jarkko

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly
  2020-02-27 16:26 ` Jarkko Sakkinen
@ 2020-02-28  2:32   ` Yang Xu
  2020-02-28  3:30     ` Eric Biggers
                       ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Yang Xu @ 2020-02-28  2:32 UTC (permalink / raw)
  To: jarkko.sakkinen

Currently, when we add a new user key, the calltrace as below:

add_key()
  key_create_or_update()
    key_alloc()
    __key_instantiate_and_link
      generic_key_instantiate
        key_payload_reserve
          ......

Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
we can reach max bytes/keys in key_alloc, but we forget to remove this
limit when we reserver space for payload in key_payload_reserve. So we
can only reach max keys but not max bytes when having delta between plen
and type->def_datalen. Remove this limit when instantiating the key, so we
can keep consistent with key_alloc.

Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
Cc: Eric Biggers <ebiggers@google.com>
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
---
 security/keys/key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/keys/key.c b/security/keys/key.c
index 718bf7217420..e959b3c96b48 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -382,7 +382,7 @@ int key_payload_reserve(struct key *key, size_t datalen)
 		spin_lock(&key->user->lock);
 
 		if (delta > 0 &&
-		    (key->user->qnbytes + delta >= maxbytes ||
+		    (key->user->qnbytes + delta > maxbytes ||
 		     key->user->qnbytes + delta < key->user->qnbytes)) {
 			ret = -EDQUOT;
 		}
-- 
2.18.0

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly
  2020-02-28  2:32   ` [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly Yang Xu
@ 2020-02-28  3:30     ` Eric Biggers
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
  2020-02-28  3:37     ` [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly Yang Xu
  2020-03-02 12:51     ` Jarkko Sakkinen
  2 siblings, 1 reply; 16+ messages in thread
From: Eric Biggers @ 2020-02-28  3:30 UTC (permalink / raw)
  To: keyrings

On Fri, Feb 28, 2020 at 10:32:57AM +0800, Yang Xu wrote:
> Currently, when we add a new user key, the calltrace as below:
> 
> add_key()
>   key_create_or_update()
>     key_alloc()
>     __key_instantiate_and_link
>       generic_key_instantiate
>         key_payload_reserve
>           ......
> 
> Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
> we can reach max bytes/keys in key_alloc, but we forget to remove this
> limit when we reserver space for payload in key_payload_reserve. So we
> can only reach max keys but not max bytes when having delta between plen
> and type->def_datalen. Remove this limit when instantiating the key, so we
> can keep consistent with key_alloc.
> 
> Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
> Cc: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
> ---
>  security/keys/key.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/keys/key.c b/security/keys/key.c
> index 718bf7217420..e959b3c96b48 100644
> --- a/security/keys/key.c
> +++ b/security/keys/key.c
> @@ -382,7 +382,7 @@ int key_payload_reserve(struct key *key, size_t datalen)
>  		spin_lock(&key->user->lock);
>  
>  		if (delta > 0 &&
> -		    (key->user->qnbytes + delta >= maxbytes ||
> +		    (key->user->qnbytes + delta > maxbytes ||
>  		     key->user->qnbytes + delta < key->user->qnbytes)) {
>  			ret = -EDQUOT;
>  		}

This looks good, but I see that both of us forgot to update keyctl_chown_key().
Can you handle that too?

You could also use two Fixes tags:

    Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
    Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")

... to make it clearer that this is fixing an incomplete fix for the original
bug, as opposed to fixing a regression.

- Eric

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly
  2020-02-28  2:32   ` [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly Yang Xu
  2020-02-28  3:30     ` Eric Biggers
@ 2020-02-28  3:37     ` Yang Xu
  2020-03-02 12:51     ` Jarkko Sakkinen
  2 siblings, 0 replies; 16+ messages in thread
From: Yang Xu @ 2020-02-28  3:37 UTC (permalink / raw)
  To: keyrings



on 2020/02/28 11:30, Eric Biggers wrote:
> On Fri, Feb 28, 2020 at 10:32:57AM +0800, Yang Xu wrote:
>> Currently, when we add a new user key, the calltrace as below:
>>
>> add_key()
>>    key_create_or_update()
>>      key_alloc()
>>      __key_instantiate_and_link
>>        generic_key_instantiate
>>          key_payload_reserve
>>            ......
>>
>> Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
>> we can reach max bytes/keys in key_alloc, but we forget to remove this
>> limit when we reserver space for payload in key_payload_reserve. So we
>> can only reach max keys but not max bytes when having delta between plen
>> and type->def_datalen. Remove this limit when instantiating the key, so we
>> can keep consistent with key_alloc.
>>
>> Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
>> Cc: Eric Biggers <ebiggers@google.com>
>> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
>> ---
>>   security/keys/key.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/security/keys/key.c b/security/keys/key.c
>> index 718bf7217420..e959b3c96b48 100644
>> --- a/security/keys/key.c
>> +++ b/security/keys/key.c
>> @@ -382,7 +382,7 @@ int key_payload_reserve(struct key *key, size_t datalen)
>>   		spin_lock(&key->user->lock);
>>   
>>   		if (delta > 0 &&
>> -		    (key->user->qnbytes + delta >= maxbytes ||
>> +		    (key->user->qnbytes + delta > maxbytes ||
>>   		     key->user->qnbytes + delta < key->user->qnbytes)) {
>>   			ret = -EDQUOT;
>>   		}
> 
> This looks good, but I see that both of us forgot to update keyctl_chown_key().
> Can you handle that too?
> 
Of course. I will handle this together.
> You could also use two Fixes tags:
> 
>      Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
>      Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
> 
> ... to make it clearer that this is fixing an incomplete fix for the original
> bug, as opposed to fixing a regression.
OK. This is more clearer.
Thanks for your comment.

Best Reagrds
Yang Xu
> 
> - Eric
> 
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  3:30     ` Eric Biggers
@ 2020-02-28  4:41       ` Yang Xu
  2020-03-02 12:52         ` Jarkko Sakkinen
                           ` (8 more replies)
  0 siblings, 9 replies; 16+ messages in thread
From: Yang Xu @ 2020-02-28  4:41 UTC (permalink / raw)
  To: jarkko.sakkinen

Currently, when we add a new user key, the calltrace as below:

add_key()
  key_create_or_update()
    key_alloc()
    __key_instantiate_and_link
      generic_key_instantiate
        key_payload_reserve
          ......

Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
we can reach max bytes/keys in key_alloc, but we forget to remove this
limit when we reserver space for payload in key_payload_reserve. So we
can only reach max keys but not max bytes when having delta between plen
and type->def_datalen. Remove this limit when instantiating the key, so we
can keep consistent with key_alloc.

Also, fix the similar problem in keyctl_chown_key().

Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
Cc: Eric Biggers <ebiggers@google.com>
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
---
 security/keys/key.c    | 2 +-
 security/keys/keyctl.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/security/keys/key.c b/security/keys/key.c
index 718bf7217420..e959b3c96b48 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -382,7 +382,7 @@ int key_payload_reserve(struct key *key, size_t datalen)
 		spin_lock(&key->user->lock);
 
 		if (delta > 0 &&
-		    (key->user->qnbytes + delta >= maxbytes ||
+		    (key->user->qnbytes + delta > maxbytes ||
 		     key->user->qnbytes + delta < key->user->qnbytes)) {
 			ret = -EDQUOT;
 		}
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index 9b898c969558..d1a3dea58dee 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -937,8 +937,8 @@ long keyctl_chown_key(key_serial_t id, uid_t user, gid_t group)
 				key_quota_root_maxbytes : key_quota_maxbytes;
 
 			spin_lock(&newowner->lock);
-			if (newowner->qnkeys + 1 >= maxkeys ||
-			    newowner->qnbytes + key->quotalen >= maxbytes ||
+			if (newowner->qnkeys + 1 > maxkeys ||
+			    newowner->qnbytes + key->quotalen > maxbytes ||
 			    newowner->qnbytes + key->quotalen <
 			    newowner->qnbytes)
 				goto quota_overrun;
-- 
2.18.0

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly
  2020-02-28  2:32   ` [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly Yang Xu
  2020-02-28  3:30     ` Eric Biggers
  2020-02-28  3:37     ` [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly Yang Xu
@ 2020-03-02 12:51     ` Jarkko Sakkinen
  2 siblings, 0 replies; 16+ messages in thread
From: Jarkko Sakkinen @ 2020-03-02 12:51 UTC (permalink / raw)
  To: keyrings

On Fri, 2020-02-28 at 10:32 +0800, Yang Xu wrote:
> Currently, when we add a new user key, the calltrace as below:
> 
> add_key()
>   key_create_or_update()
>     key_alloc()
>     __key_instantiate_and_link
>       generic_key_instantiate
>         key_payload_reserve
>           ......
> 
> Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
> we can reach max bytes/keys in key_alloc, but we forget to remove this
> limit when we reserver space for payload in key_payload_reserve. So we
> can only reach max keys but not max bytes when having delta between plen
> and type->def_datalen. Remove this limit when instantiating the key, so we
> can keep consistent with key_alloc.
> 
> Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
> Cc: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>

Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

/Jarkko

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
@ 2020-03-02 12:52         ` Jarkko Sakkinen
  2020-03-03  4:17         ` Eric Biggers
                           ` (7 subsequent siblings)
  8 siblings, 0 replies; 16+ messages in thread
From: Jarkko Sakkinen @ 2020-03-02 12:52 UTC (permalink / raw)
  To: keyrings

On Fri, 2020-02-28 at 12:41 +0800, Yang Xu wrote:
> Currently, when we add a new user key, the calltrace as below:
> 
> add_key()
>   key_create_or_update()
>     key_alloc()
>     __key_instantiate_and_link
>       generic_key_instantiate
>         key_payload_reserve
>           ......
> 
> Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
> we can reach max bytes/keys in key_alloc, but we forget to remove this
> limit when we reserver space for payload in key_payload_reserve. So we
> can only reach max keys but not max bytes when having delta between plen
> and type->def_datalen. Remove this limit when instantiating the key, so we
> can keep consistent with key_alloc.
> 
> Also, fix the similar problem in keyctl_chown_key().
> 
> Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
> Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
> Cc: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>

Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

/Jarkko

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
  2020-03-02 12:52         ` Jarkko Sakkinen
@ 2020-03-03  4:17         ` Eric Biggers
  2020-03-03  4:33         ` Yang Xu
                           ` (6 subsequent siblings)
  8 siblings, 0 replies; 16+ messages in thread
From: Eric Biggers @ 2020-03-03  4:17 UTC (permalink / raw)
  To: keyrings

On Fri, Feb 28, 2020 at 12:41:51PM +0800, Yang Xu wrote:
>
> Subject: Re: [PATCH v3] KEYS: reaching the keys quotas correctly

The subject should be in imperative tense, like
"KEYS: reach the keys quotas correctly"

> Currently, when we add a new user key, the calltrace as below:
> 
> add_key()
>   key_create_or_update()
>     key_alloc()
>     __key_instantiate_and_link
>       generic_key_instantiate
>         key_payload_reserve
>           ......
> 
> Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
> we can reach max bytes/keys in key_alloc, but we forget to remove this
> limit when we reserver space for payload in key_payload_reserve. So we
> can only reach max keys but not max bytes when having delta between plen
> and type->def_datalen. Remove this limit when instantiating the key, so we
> can keep consistent with key_alloc.
> 
> Also, fix the similar problem in keyctl_chown_key().
> 
> Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
> Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
> Cc: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>

Otherwise this looks fine.  Thanks!

Reviewed-by: Eric Biggers <ebiggers@google.com>

- Eric

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
  2020-03-02 12:52         ` Jarkko Sakkinen
  2020-03-03  4:17         ` Eric Biggers
@ 2020-03-03  4:33         ` Yang Xu
  2020-03-03 20:18         ` Jarkko Sakkinen
                           ` (5 subsequent siblings)
  8 siblings, 0 replies; 16+ messages in thread
From: Yang Xu @ 2020-03-03  4:33 UTC (permalink / raw)
  To: keyrings



on 2020/03/03 12:17, Eric Biggers wrote:
> On Fri, Feb 28, 2020 at 12:41:51PM +0800, Yang Xu wrote:
>>
>> Subject: Re: [PATCH v3] KEYS: reaching the keys quotas correctly
> 
> The subject should be in imperative tense, like
> "KEYS: reach the keys quotas correctly"
Sound reasonable, I think maintainer can change this when merged this patch.

Best Regards
Yang Xu
> 
>> Currently, when we add a new user key, the calltrace as below:
>>
>> add_key()
>>    key_create_or_update()
>>      key_alloc()
>>      __key_instantiate_and_link
>>        generic_key_instantiate
>>          key_payload_reserve
>>            ......
>>
>> Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
>> we can reach max bytes/keys in key_alloc, but we forget to remove this
>> limit when we reserver space for payload in key_payload_reserve. So we
>> can only reach max keys but not max bytes when having delta between plen
>> and type->def_datalen. Remove this limit when instantiating the key, so we
>> can keep consistent with key_alloc.
>>
>> Also, fix the similar problem in keyctl_chown_key().
>>
>> Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
>> Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
>> Cc: Eric Biggers <ebiggers@google.com>
>> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
> 
> Otherwise this looks fine.  Thanks!
> 
> Reviewed-by: Eric Biggers <ebiggers@google.com>
> 
> - Eric
> 
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
                           ` (2 preceding siblings ...)
  2020-03-03  4:33         ` Yang Xu
@ 2020-03-03 20:18         ` Jarkko Sakkinen
  2020-03-19 15:08         ` David Howells
                           ` (4 subsequent siblings)
  8 siblings, 0 replies; 16+ messages in thread
From: Jarkko Sakkinen @ 2020-03-03 20:18 UTC (permalink / raw)
  To: keyrings

On Mon, Mar 02, 2020 at 08:17:32PM -0800, Eric Biggers wrote:
> On Fri, Feb 28, 2020 at 12:41:51PM +0800, Yang Xu wrote:
> >
> > Subject: Re: [PATCH v3] KEYS: reaching the keys quotas correctly
> 
> The subject should be in imperative tense, like
> "KEYS: reach the keys quotas correctly"

Preferably with a capital letter .

> 
> > Currently, when we add a new user key, the calltrace as below:
> > 
> > add_key()
> >   key_create_or_update()
> >     key_alloc()
> >     __key_instantiate_and_link
> >       generic_key_instantiate
> >         key_payload_reserve
> >           ......
> > 
> > Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
> > we can reach max bytes/keys in key_alloc, but we forget to remove this
> > limit when we reserver space for payload in key_payload_reserve. So we
> > can only reach max keys but not max bytes when having delta between plen
> > and type->def_datalen. Remove this limit when instantiating the key, so we
> > can keep consistent with key_alloc.
> > 
> > Also, fix the similar problem in keyctl_chown_key().
> > 
> > Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
> > Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
> > Cc: Eric Biggers <ebiggers@google.com>
> > Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
> 
> Otherwise this looks fine.  Thanks!
> 
> Reviewed-by: Eric Biggers <ebiggers@google.com>

David, should I pick this is up to my tree?

/Jarkko

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
                           ` (3 preceding siblings ...)
  2020-03-03 20:18         ` Jarkko Sakkinen
@ 2020-03-19 15:08         ` David Howells
  2020-03-19 21:15         ` Jarkko Sakkinen
                           ` (3 subsequent siblings)
  8 siblings, 0 replies; 16+ messages in thread
From: David Howells @ 2020-03-19 15:08 UTC (permalink / raw)
  To: keyrings

How about:

	keys: Fix the keys quotas limit check

It's a bit unfortunate that "key" is also usable as an adjective.

David

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
                           ` (4 preceding siblings ...)
  2020-03-19 15:08         ` David Howells
@ 2020-03-19 21:15         ` Jarkko Sakkinen
  2020-03-19 21:30         ` David Howells
                           ` (2 subsequent siblings)
  8 siblings, 0 replies; 16+ messages in thread
From: Jarkko Sakkinen @ 2020-03-19 21:15 UTC (permalink / raw)
  To: keyrings

On Thu, Mar 19, 2020 at 03:08:21PM +0000, David Howells wrote:
> How about:
> 
> 	keys: Fix the keys quotas limit check
> 
> It's a bit unfortunate that "key" is also usable as an adjective.
> 
> David

Unfortunately it is already hanging here:

https://www.lkml.org/lkml/2020/3/15/314

/Jarkko

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
                           ` (5 preceding siblings ...)
  2020-03-19 21:15         ` Jarkko Sakkinen
@ 2020-03-19 21:30         ` David Howells
  2020-03-20  1:45         ` Jarkko Sakkinen
  2020-03-20  8:59         ` David Howells
  8 siblings, 0 replies; 16+ messages in thread
From: David Howells @ 2020-03-19 21:30 UTC (permalink / raw)
  To: keyrings

Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:

> Unfortunately it is already hanging here:
> 
> https://www.lkml.org/lkml/2020/3/15/314

Hanging? Or queued?

David

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
                           ` (6 preceding siblings ...)
  2020-03-19 21:30         ` David Howells
@ 2020-03-20  1:45         ` Jarkko Sakkinen
  2020-03-20  8:59         ` David Howells
  8 siblings, 0 replies; 16+ messages in thread
From: Jarkko Sakkinen @ 2020-03-20  1:45 UTC (permalink / raw)
  To: keyrings

On Thu, Mar 19, 2020 at 09:30:13PM +0000, David Howells wrote:
> Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> 
> > Unfortunately it is already hanging here:
> > 
> > https://www.lkml.org/lkml/2020/3/15/314
> 
> Hanging? Or queued?

Not yet queued.

Should I request to withdraw it? There is still time to do that.

/Jarkko

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] KEYS: reaching the keys quotas correctly
  2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
                           ` (7 preceding siblings ...)
  2020-03-20  1:45         ` Jarkko Sakkinen
@ 2020-03-20  8:59         ` David Howells
  8 siblings, 0 replies; 16+ messages in thread
From: David Howells @ 2020-03-20  8:59 UTC (permalink / raw)
  To: keyrings

Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:

> > > Unfortunately it is already hanging here:
> > > 
> > > https://www.lkml.org/lkml/2020/3/15/314
> > 
> > Hanging? Or queued?
> 
> Not yet queued.
> 
> Should I request to withdraw it? There is still time to do that.

I was making up a series of fix patches to send to Linus.  If you want to send
your queue instead, you can stick my Acked-by on this patch.

David

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2020-03-20  8:59 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-27 10:25 [PATCH] KEYS: reaching the keys quotas correctly when instanttiating Yang Xu
2020-02-27 16:26 ` Jarkko Sakkinen
2020-02-28  2:32   ` [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly Yang Xu
2020-02-28  3:30     ` Eric Biggers
2020-02-28  4:41       ` [PATCH v3] KEYS: reaching the keys quotas correctly Yang Xu
2020-03-02 12:52         ` Jarkko Sakkinen
2020-03-03  4:17         ` Eric Biggers
2020-03-03  4:33         ` Yang Xu
2020-03-03 20:18         ` Jarkko Sakkinen
2020-03-19 15:08         ` David Howells
2020-03-19 21:15         ` Jarkko Sakkinen
2020-03-19 21:30         ` David Howells
2020-03-20  1:45         ` Jarkko Sakkinen
2020-03-20  8:59         ` David Howells
2020-02-28  3:37     ` [PATCH v2] KEYS: reaching the keys quotas(max_bytes) correctly Yang Xu
2020-03-02 12:51     ` Jarkko Sakkinen

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.