* [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.