On Fri, 2012-12-07 at 09:48 +0100, Rik Theys wrote: > Hi, > > On 12/06/2012 02:51 PM, Ben Hutchings wrote: > > On Thu, 2012-12-06 at 13:58 +0100, Rik Theys wrote: > >> On 12/06/2012 01:29 PM, Ben Hutchings wrote: > >>>>> It is not too difficult to fix up the conflicts. But this is a fairly > >>>>> big change, so I think this bug should now be 'wontfix' for wheezy. > >>>>> Sorry we didn't get it fixed earlier. > >>>> > >>>> Sorry to hear that. Would a patch that simply increases the static > >>>> number of entries in the names array be an acceptable workaround? It > >>>> would decrease the change of hitting this bug. > >>> > >>> Perhaps; do you have any idea what the limit should be? > >> > >> Not really. I'm currently building a test kernel with the limit set to > >> 25 (instead of 20). I'll see if I can boot that kernel one of these days > >> to see if 25 is enough. > >> > >> The 25 might be enough for my situation, but other users could of course > >> need an even bigger number... > >> > >>> We do need to consider that this costs 76 bytes per name per task for > >>> which auditing is enabled, and there are normally hundreds or thousands > >>> of tasks running, so extra names aren't cheap. > >> > >> What would you consider the upper limit to which we could increase the > >> number? Just so I know at which limit I can stop building test kernels. > > > > Since you're asking me to make a somewhat arbitrary decision, I'll > > arbitrarily decide on double the current limit, i.e. 40. > > I've booted a kernel which has the AUDIT_NAMES set to 30. It's been > running for about 12 hours now without any messages (with the Debian > 3.2.32 kernel it already logged the first message after 57s uptime). > > For now, it seems 30 is enough for my use case. If you're willing to > bump it up to 40, I would go for that. > > Thank you for considering. As I said, every increase costs memory for all audit users. I've set it to 30 until the next person finds a reason to increase it further! Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way.
Attachment:
signature.asc
Description: This is a digitally signed message part