From: Paul Moore <paul@paul-moore.com>
To: Dave Jones <davej@redhat.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
Linux Kernel <linux-kernel@vger.kernel.org>,
eparis@redhat.com, james.l.morris@oracle.com,
selinux@tycho.nsa.gov
Subject: Re: [PATCH] conditionally reschedule while loading selinux policy.
Date: Thu, 03 Oct 2013 16:36:10 -0400 [thread overview]
Message-ID: <2297933.rECKfqAcWT@sifl> (raw)
In-Reply-To: <20130930211342.GA24001@redhat.com>
On Monday, September 30, 2013 05:13:42 PM Dave Jones wrote:
> On Mon, Sep 30, 2013 at 01:37:53PM -0400, Stephen Smalley wrote:
> > > With that patch applied, the problem seems to have moved elsewhere..
> > >
> > > BUG: soft lockup - CPU#3 stuck for 22s! [load_policy:8119]
> > >
> > > irq event stamp: 1590886
> > > hardirqs last enabled at (1590885): [<ffffffff8152c3dd>]
> > > __slab_alloc.constprop.78+0x4c0/0x4d7 hardirqs last disabled at
> > > (1590886): [<ffffffff8153e06a>] apic_timer_interrupt+0x6a/0x80
> > > softirqs last enabled at (1590336): [<ffffffff810480d9>]
> > > __do_softirq+0x169/0x200 softirqs last disabled at (1590331):
> > > [<ffffffff8104839d>] irq_exit+0x11d/0x140 RIP:
> > > 0010:[<ffffffff81223182>] [<ffffffff81223182>]
> > > hashtab_insert+0x62/0x110 > >
> > > Call Trace:
> > > [<ffffffff812283b5>] policydb_read+0xc25/0x1200
> >
> > ...
> >
> > > We're holding a bunch of locks here, so we can't just cond_resched.
> > > Thoughts ?
> >
> > Sorry, what locks are we holding there? You ought to be able to do a
> > cond_resched() anywhere during policydb_read() AFAIK; it is loading the
> > policy into a new structure that isn't being accessed by anything else
> > yet and the policy_rwlock is only held by security_load_policy after
> > calling policydb_read and only to switch it into place as the active
> > policydb.
>
> Hmm, I thought I had tried this already, and got a lot of spew, but it turns
> out for some reason I had previously patched hashtab_search instead.
>
> I'll try running with this for a while..
Hi Dave,
Just checking to see if this patch solved your problem ... ?
> diff --git a/security/selinux/ss/hashtab.c b/security/selinux/ss/hashtab.c
> index 933e735..2cc4961 100644
> --- a/security/selinux/ss/hashtab.c
> +++ b/security/selinux/ss/hashtab.c
> @@ -6,6 +6,7 @@
> #include <linux/kernel.h>
> #include <linux/slab.h>
> #include <linux/errno.h>
> +#include <linux/sched.h>
> #include "hashtab.h"
>
> struct hashtab *hashtab_create(u32 (*hash_value)(struct hashtab *h, const
> void *key), @@ -40,6 +41,8 @@ int hashtab_insert(struct hashtab *h, void
> *key, void *datum) u32 hvalue;
> struct hashtab_node *prev, *cur, *newnode;
>
> + cond_resched();
> +
> if (!h || h->nel == HASHTAB_MAX_NODES)
> return -EINVAL;
--
paul moore
www.paul-moore.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul@paul-moore.com>
To: Dave Jones <davej@redhat.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
Linux Kernel <linux-kernel@vger.kernel.org>,
eparis@redhat.com, james.l.morris@oracle.com,
selinux@tycho.nsa.gov
Subject: Re: [PATCH] conditionally reschedule while loading selinux policy.
Date: Thu, 03 Oct 2013 16:36:10 -0400 [thread overview]
Message-ID: <2297933.rECKfqAcWT@sifl> (raw)
In-Reply-To: <20130930211342.GA24001@redhat.com>
On Monday, September 30, 2013 05:13:42 PM Dave Jones wrote:
> On Mon, Sep 30, 2013 at 01:37:53PM -0400, Stephen Smalley wrote:
> > > With that patch applied, the problem seems to have moved elsewhere..
> > >
> > > BUG: soft lockup - CPU#3 stuck for 22s! [load_policy:8119]
> > >
> > > irq event stamp: 1590886
> > > hardirqs last enabled at (1590885): [<ffffffff8152c3dd>]
> > > __slab_alloc.constprop.78+0x4c0/0x4d7 hardirqs last disabled at
> > > (1590886): [<ffffffff8153e06a>] apic_timer_interrupt+0x6a/0x80
> > > softirqs last enabled at (1590336): [<ffffffff810480d9>]
> > > __do_softirq+0x169/0x200 softirqs last disabled at (1590331):
> > > [<ffffffff8104839d>] irq_exit+0x11d/0x140 RIP:
> > > 0010:[<ffffffff81223182>] [<ffffffff81223182>]
> > > hashtab_insert+0x62/0x110 > >
> > > Call Trace:
> > > [<ffffffff812283b5>] policydb_read+0xc25/0x1200
> >
> > ...
> >
> > > We're holding a bunch of locks here, so we can't just cond_resched.
> > > Thoughts ?
> >
> > Sorry, what locks are we holding there? You ought to be able to do a
> > cond_resched() anywhere during policydb_read() AFAIK; it is loading the
> > policy into a new structure that isn't being accessed by anything else
> > yet and the policy_rwlock is only held by security_load_policy after
> > calling policydb_read and only to switch it into place as the active
> > policydb.
>
> Hmm, I thought I had tried this already, and got a lot of spew, but it turns
> out for some reason I had previously patched hashtab_search instead.
>
> I'll try running with this for a while..
Hi Dave,
Just checking to see if this patch solved your problem ... ?
> diff --git a/security/selinux/ss/hashtab.c b/security/selinux/ss/hashtab.c
> index 933e735..2cc4961 100644
> --- a/security/selinux/ss/hashtab.c
> +++ b/security/selinux/ss/hashtab.c
> @@ -6,6 +6,7 @@
> #include <linux/kernel.h>
> #include <linux/slab.h>
> #include <linux/errno.h>
> +#include <linux/sched.h>
> #include "hashtab.h"
>
> struct hashtab *hashtab_create(u32 (*hash_value)(struct hashtab *h, const
> void *key), @@ -40,6 +41,8 @@ int hashtab_insert(struct hashtab *h, void
> *key, void *datum) u32 hvalue;
> struct hashtab_node *prev, *cur, *newnode;
>
> + cond_resched();
> +
> if (!h || h->nel == HASHTAB_MAX_NODES)
> return -EINVAL;
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2013-10-03 20:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-16 17:30 lockup during selinux policy load Dave Jones
2013-09-16 17:43 ` Stephen Smalley
2013-09-16 18:40 ` [PATCH] conditionally reschedule while loading selinux policy Dave Jones
2013-09-16 18:51 ` Stephen Smalley
2013-09-30 17:24 ` Dave Jones
2013-09-30 17:37 ` Stephen Smalley
2013-09-30 21:13 ` Dave Jones
2013-10-03 20:36 ` Paul Moore [this message]
2013-10-03 20:36 ` Paul Moore
2013-10-03 20:40 ` Dave Jones
2013-10-03 20:49 ` Paul Moore
2013-10-03 20:49 ` Paul Moore
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=2297933.rECKfqAcWT@sifl \
--to=paul@paul-moore.com \
--cc=davej@redhat.com \
--cc=eparis@redhat.com \
--cc=james.l.morris@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/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 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.