On 9/5/20 11:13 AM, Casey Schaufler wrote:

On 9/5/2020 6:25 AM, Paul Moore wrote:

quoted

On Fri, Sep 4, 2020 at 7:58 PM Casey Schaufler [off-list ref] wrote:

quoted

On 9/4/2020 2:53 PM, Paul Moore wrote:

quoted

On Fri, Sep 4, 2020 at 5:35 PM Casey Schaufler [off-list ref] wrote:

quoted

On 9/4/2020 1:08 PM, Paul Moore wrote:

...

quoted

quoted

I understand the concerns you mention, they are all valid as far as
I'm concerned, but I think we are going to get burned by this code as
it currently stands.

Yes, I can see that. We're getting burned by the non-extensibility
of secids. It will take someone smarter than me to figure out how to
fit N secids into 32bits without danger of either failure or memory
allocation.

Sooo what are the next steps here?  It sounds like there is some
agreement that the currently proposed unix_skb_params approach is a
problem, but it also sounds like you just want to merge it anyway?

There are real problems with all the approaches. This is by far the
least invasive of the lot. If this is acceptable for now I will commit
to including the dynamic allocation version in the full stacking
(e.g. Smack + SELinux) stage. If it isn't, well, this stage is going
to take even longer than it already has. Sigh.

quoted

I was sorta hoping for something a bit better.

I will be looking at alternatives. I am very much open to suggestions.
I'm not even 100% convinced that Stephen's objections to my separate
allocation strategy outweigh its advantages. If you have an opinion on
that, I'd love to hear it.

fwiw I prefer the separate allocation strategy, but as you have already
said it trading off one set of problems for another. I would rather see
this move forward and one set of trade offs isn't significantly worse
than the other to me so, either wfm.