From: John Johansen <[email protected]>
To: Matthew Wilcox <[email protected]>
Cc: Linus Torvalds <[email protected]>,
"Eric W. Biederman" <[email protected]>,
Ammar Faizi <[email protected]>,
James Morris <[email protected]>,
LSM List <[email protected]>,
Linux Kernel Mailing List <[email protected]>,
Al Viro <[email protected]>,
Kees Cook <[email protected]>,
[email protected], Linux-MM <[email protected]>,
[email protected]
Subject: Re: Linux 5.18-rc4
Date: Mon, 6 Jun 2022 14:00:33 -0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 6/6/22 13:23, Matthew Wilcox wrote:
> On Mon, Jun 06, 2022 at 12:19:36PM -0700, John Johansen wrote:
>>> I suspect that part is that both Apparmor and IPC use the idr local lock.
>>>
>> bingo,
>>
>> apparmor moved its secids allocation from a custom radix tree to idr in
>>
>> 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids
>>
>> and ipc is using the idr for its id allocation as well
>>
>> I can easily lift the secid() allocation out of the ctx->lock but that
>> would still leave it happening under the file_lock and not fix the problem.
>> I think the quick solution would be for apparmor to stop using idr, reverting
>> back at least temporarily to the custom radix tree.
>
> How about moving forward to the XArray that doesn't use that horrid
> prealloc gunk? Compile tested only.
>
I'm not very familiar with XArray but it does seem like a good fit. We do try
to keep the secid allocation dense, ideally no holes. Wrt the current locking
issue I want to hear what Thomas has to say. Regardless I am looking into
whether we should just switch to XArrays going forward.
>
> diff --git a/security/apparmor/include/secid.h b/security/apparmor/include/secid.h
> index 48ff1ddecad5..278dff5ecd1f 100644
> --- a/security/apparmor/include/secid.h
> +++ b/security/apparmor/include/secid.h
> @@ -31,6 +31,4 @@ int aa_alloc_secid(struct aa_label *label, gfp_t gfp);
> void aa_free_secid(u32 secid);
> void aa_secid_update(u32 secid, struct aa_label *label);
>
> -void aa_secids_init(void);
> -
> #endif /* __AA_SECID_H */
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 900bc540656a..9dfb4e4631da 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1857,8 +1857,6 @@ static int __init apparmor_init(void)
> {
> int error;
>
> - aa_secids_init();
> -
> error = aa_setup_dfa_engine();
> if (error) {
> AA_ERROR("Unable to setup dfa engine\n");
> diff --git a/security/apparmor/secid.c b/security/apparmor/secid.c
> index ce545f99259e..3b08942db1f6 100644
> --- a/security/apparmor/secid.c
> +++ b/security/apparmor/secid.c
> @@ -13,9 +13,9 @@
> #include <linux/errno.h>
> #include <linux/err.h>
> #include <linux/gfp.h>
> -#include <linux/idr.h>
> #include <linux/slab.h>
> #include <linux/spinlock.h>
> +#include <linux/xarray.h>
>
> #include "include/cred.h"
> #include "include/lib.h"
> @@ -29,8 +29,7 @@
> */
> #define AA_FIRST_SECID 2
>
> -static DEFINE_IDR(aa_secids);
> -static DEFINE_SPINLOCK(secid_lock);
> +static DEFINE_XARRAY_FLAGS(aa_secids, XA_FLAGS_LOCK_IRQ | XA_FLAGS_TRACK_FREE);
>
> /*
> * TODO: allow policy to reserve a secid range?
> @@ -47,9 +46,9 @@ void aa_secid_update(u32 secid, struct aa_label *label)
> {
> unsigned long flags;
>
> - spin_lock_irqsave(&secid_lock, flags);
> - idr_replace(&aa_secids, label, secid);
> - spin_unlock_irqrestore(&secid_lock, flags);
> + xa_lock_irqsave(&aa_secids, flags);
> + __xa_store(&aa_secids, secid, label, 0);
> + xa_unlock_irqrestore(&aa_secids, flags);
> }
>
> /**
> @@ -58,13 +57,7 @@ void aa_secid_update(u32 secid, struct aa_label *label)
> */
> struct aa_label *aa_secid_to_label(u32 secid)
> {
> - struct aa_label *label;
> -
> - rcu_read_lock();
> - label = idr_find(&aa_secids, secid);
> - rcu_read_unlock();
> -
> - return label;
> + return xa_load(&aa_secids, secid);
> }
>
> int apparmor_secid_to_secctx(u32 secid, char **secdata, u32 *seclen)
> @@ -126,19 +119,16 @@ int aa_alloc_secid(struct aa_label *label, gfp_t gfp)
> unsigned long flags;
> int ret;
>
> - idr_preload(gfp);
> - spin_lock_irqsave(&secid_lock, flags);
> - ret = idr_alloc(&aa_secids, label, AA_FIRST_SECID, 0, GFP_ATOMIC);
> - spin_unlock_irqrestore(&secid_lock, flags);
> - idr_preload_end();
> + xa_lock_irqsave(&aa_secids, flags);
> + ret = __xa_alloc(&aa_secids, &label->secid, label,
> + XA_LIMIT(AA_FIRST_SECID, INT_MAX), gfp);
> + xa_unlock_irqrestore(&aa_secids, flags);
>
> if (ret < 0) {
> label->secid = AA_SECID_INVALID;
> return ret;
> }
>
> - AA_BUG(ret == AA_SECID_INVALID);
> - label->secid = ret;
> return 0;
> }
>
> @@ -150,12 +140,7 @@ void aa_free_secid(u32 secid)
> {
> unsigned long flags;
>
> - spin_lock_irqsave(&secid_lock, flags);
> - idr_remove(&aa_secids, secid);
> - spin_unlock_irqrestore(&secid_lock, flags);
> -}
> -
> -void aa_secids_init(void)
> -{
> - idr_init_base(&aa_secids, AA_FIRST_SECID);
> + xa_lock_irqsave(&aa_secids, flags);
> + __xa_erase(&aa_secids, secid);
> + xa_unlock_irqrestore(&aa_secids, flags);
> }
next prev parent reply other threads:[~2022-06-06 21:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHk-=whmtHMzjaVUF9bS+7vE_rrRctcCTvsAeB8fuLYcyYLN-g@mail.gmail.com>
2022-04-27 17:59 ` Linux 5.18-rc4 Ammar Faizi
2022-04-27 18:31 ` Linus Torvalds
2022-06-06 15:19 ` Eric W. Biederman
2022-06-06 18:28 ` Linus Torvalds
2022-06-06 19:19 ` John Johansen
2022-06-06 19:47 ` Linus Torvalds
2022-06-06 20:23 ` Matthew Wilcox
2022-06-06 21:00 ` John Johansen [this message]
2022-06-13 22:48 ` Matthew Wilcox
2022-06-21 20:27 ` John Johansen
2022-07-13 9:37 ` Ammar Faizi
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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