David Laight wrote:
On Sat, Jun 23, 2007 at 06:23:44PM +0300, Elad Efrat wrote:
does "compat code with one less malloc" weighs more than "opaque and
abstract interface allowing various pluggable secmodels"?
Actually the malloc/free was on every call to sys_set/getgroups,
not just those in the compat code.
how common are calls to syscalls? can you show performance tests that
indicate a clear measurable system performance improvement as a result
of removing the malloc/free?
One benefit of my changes is that the NGROUPS constant is no
longer in the sys_setgroups() functions, possibly allowing it
to be dynamically changable (etc) without changing the interface
to LKM compat code.
your changes may introduce this benefit, but are overshadowed by the
simple fact that you broke a critical kernel interface and exposed its
internals, eliminating one of its key design goals of opacity -- and
you did so without any prior discussion.
while the changes to get/setgroups syscall internals and compat calls
will not change the user experience in any way, breaking kauth's opacity
have direct and immediate implications in the form of not allowing much
flexibility when implementing new security models that expand beyond
what is currently allowed by bsd44.
additionally, it is well worth pointing out that the benefit you
introduced is orthogonal to breaking the interface's opacity, and could
have been introduced either way.
-e.