From: Eric Paris <eparis@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: russell@coker.com.au, SE-Linux <selinux@tycho.nsa.gov>,
Eric Paris <eparis@parisplace.org>,
James Morris <jmorris@namei.org>
Subject: Re: strange policy loading problem
Date: Thu, 11 Mar 2010 14:47:25 -0500 [thread overview]
Message-ID: <1268336845.2941.64.camel@localhost> (raw)
In-Reply-To: <1268334980.16780.101.camel@moss-pluto.epoch.ncsc.mil>
On Thu, 2010-03-11 at 14:16 -0500, Stephen Smalley wrote:
> On Wed, 2010-03-03 at 10:18 +1100, Russell Coker wrote:
> > I'm running a 2.6.32 system under KVM and it keeps OOMing when I try to run
> > semodule.
> >
> > # free
> > total used free shared buffers cached
> > Mem: 507532 475320 32212 0 4168 11148
> > -/+ buffers/cache: 460004 47528
> > Swap: 524280 19848 504432
> >
> > The policy.24 file is just under 900K in size, the output of free is above, it
> > doesn't seem particularly short of RAM. The dmesg output is below. Any
> > suggestions for what I should investigate?
> >
> > I could just give the VM a gig of RAM, but I run lots of real systems with
> > less than 512M so I would like this to work.
> >
> >
> > [10750.523296] load_policy: page allocation failure. order:4, mode:0xc0d0
> > [10750.524503] Pid: 13383, comm: load_policy Not tainted 2.6.32-trunk-amd64 #1
>
> This has been reproduced by others, and in looking further at it, I
> think it is due to switching the avtab from using vmalloc() to using
> kmalloc() as part of commit 3232c110b56bd01c5f0fdfd16b4d695f2e05b0a9
> without reducing MAX_AVTAB_SIZE sufficiently to ensure that we don't put
> too much pressure on the slab allocator. Options seem to be:
> 1) Reduce MAX_AVTAB_SIZE further so that the max avtab allocation is a
> lower order allocation that isn't likely to fail on kcalloc, and keep
> using that always.
> 2) Change the avtab code to dynamically select use of vmalloc/vfree or
> kcalloc/kfree depending on the selected avtab size.
lib/flex_array.c also looks like it could be a solution. Probably the
best solution since we don't have to worry about future changes and
people forgetting about the limitation and reasons for either 1 or 2.
-Eric
>
--
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.
next prev parent reply other threads:[~2010-03-11 19:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 23:18 strange policy loading problem Russell Coker
2010-03-03 13:06 ` Stephen Smalley
2010-03-03 14:28 ` Stephen Smalley
2010-03-04 1:00 ` Russell Coker
2010-03-04 15:05 ` Stephen Smalley
2010-03-11 19:16 ` Stephen Smalley
2010-03-11 19:47 ` Eric Paris [this message]
2010-03-11 19:59 ` Stephen Smalley
2010-03-15 14:31 ` Stephen Smalley
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=1268336845.2941.64.camel@localhost \
--to=eparis@redhat.com \
--cc=eparis@parisplace.org \
--cc=jmorris@namei.org \
--cc=russell@coker.com.au \
--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.