Comment 5 for bug 1499544

Another potential limit is the possible failure in pre audit to generate a stacked labels name. This would happen when the name allocation kmalloc fails because it is too large (under GFP_KERNEL conditions likely larger than a page, GFP_ATOMIC smaller) resulting in the audit being failed and access being denied based on that failure. The name generation could be moved to the merge phase, but that would just result in the failure being pushed earlier and into a GFP_ATOMIC context which has much tighter memory allocation constraints.

The generated name code could be reworked so that it will not allocate but just push the subnames into the audit buffer one at a time. This would work around this limitation, however it still leaves the limitation that a really long name could overwhelm the audit buffer.

Note: due to how auditing is done the stacked name for the task label will usually be audited as individual profiles but the label name of the object MAY be audited as a compound label. This could be reworked as well so that compound names are never audited