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