public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Luciano Chavez <lnx1138@linux.vnet.ibm.com>
To: linux-audit@redhat.com
Subject: libaudit large stack requirement in audit_send()
Date: Mon, 29 Apr 2013 11:15:16 -0500	[thread overview]
Message-ID: <1367252116.6765.50.camel@chavez-laptop> (raw)

Hello,

I am working with a development team developing a J2EE application. They
reported a problem with a crash in audit_send(). The crash occurred in a
ppc64 architecture environment early on in the invocation to audit send.

The crash occurs in this instruction which is establishing the size of
the local stack:

=> 0xfff73237994 <audit_send+52>:	stdu    r1,-27232(r1)

I found one large struct defined to a local variable

(gdb) print sizeof(struct audit_message)
$4 = 8988

but you will note that it asks for much more than that and after looking
at the audit_send() routine, it calls a function called check_ack()
which appears to be inlined and it contains two even larger definitions
on the stack for the following structure:

struct audit_reply

(gdb) print sizeof(struct audit_reply)
$3 = 9016

So, the combination of the three is what requires almost 26.5K of local
stack usage in this frame alone.

Is there a requirement for libaudit to have the structs on the stack
versus allocated from heap? Is so, is this requirement documented
somewhere?

To be fair, the Java application has some heavy stack usage as it is
since it is deployed in a web application server and there is a JNI
function that is somewhere in the call stack as well. However, the stack
usage in the audit_send() function seems ... excessive.

Originally the thread stacksize size was set to 256K and that did not
help but once we raised it to 1MB it did but I think that is probably
more than we really need.

I have looked at the source for the audit 2.2.3 release from March and
don't see a difference in how the structs are allocated. So once again,
if there is not a requirement that the structs be on the stack, should
they not be allocated off the heap?

regards,
-- 
Luciano Chavez <lnx1138@linux.vnet.ibm.com>

             reply	other threads:[~2013-04-29 16:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-29 16:15 Luciano Chavez [this message]
2013-04-29 16:48 ` libaudit large stack requirement in audit_send() Steve Grubb
2013-04-29 18:35   ` Steve Grubb
2013-04-29 21:02   ` Luciano Chavez

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=1367252116.6765.50.camel@chavez-laptop \
    --to=lnx1138@linux.vnet.ibm.com \
    --cc=linux-audit@redhat.com \
    /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