[apparmor] [PATCH 9/9] Require matched mode strings to terminate

[John Johansen]

On 12/28/2011 03:28 PM, Seth Arnold wrote:
>> yes it would be, whether we want to change this, so that abstractions can
>> end their file on the same line as a MODE I am unsure.
>
> It's a definite corner case -- not too many people are going to be using
> echo -n to append lines to abstractions...
>
yeah, atm its one I am willing to break, I think

>> For various reasons I favor not having the include be just a text dump,
>> but perhaps that isn't what other people want.
>
> I've still got a moderate hope that we can improve parsing speeds for some
> of our long run times by scanning each included file at most once --
> though the variables definitely complicate this.
>
Well yes we certainly will, but at what level is still an open question.
Eg.  Currently includes are just pulled in, resulting in a lot of duplicate
rules which we rely on tree factoring to partly undo.

We can and will get this earlier once I get the parser context patches done.
That way within a given profile we will only have to parse and compile an
include once.  This will reduce a lot of the current duplication, reducing
the need for the duplicate elimination pass, reducing the work in tree
factoring and possibly also the amount of redundant states that need to
be eliminated in minimization.

As to whether we will get to using includes as precompiled chunks I am unsure.
They need to be larger enough that it will be worth it.  Basically with out playing
more with it I am unsure that includes are the right boundry for determining
precompiled chunks

>>> Also, be very careful with the variable-length trailing context: flex
>>> runtime goes to hell in a hurry when trailing context isn't a fixed, known
>>> length: http://flex.sourceforge.net/manual/Performance.html
>>>
>> yes, but this case is a fixed length with a fixed number of characters.
>
> It _looks_ that way, but I think flex is being annoying here:
>
>       For some trailing context rules, parts which  are  actually  fixed-length
>       are  not  recognized  as  such, leading to the abovementioned performance
>       loss.  In particular, parts using '|'  or  {n}  (such  as  "foo{3}")  are
>       always considered variable-length.
>
> I think /[[:blank:]\n,] would be sufficient to replace the three
> alternating rules. It's unfortunate that this duplicates all three
> patterns but it does remove the alternation.

hrmmm, I will have to try that, we should be able to see a difference in the flex
state dump