[rsbac] A few comments/questions on RSBAC
Amon Ott
ao at rsbac.org
Wed Jul 6 19:58:15 CEST 2005
On Mittwoch 06 Juli 2005 19:37, tvrtko.ursulin at sophos.com wrote:
> >Why do you think that requests must not sleep? They may and do, as
you
> >show yourself under 2.
>
> Because if I use kmalloc instead of rsbac_kmalloc, I trigger
"sleeping
> function called from invalid context". Call trace is
> adf_request->adf_request_int->adf_request_reg->my_hook->kmalloc.
>
> Looking at the code shows that in adf_request_reg you are taking a
> read_lock, traversing the list of registered modules and invoking
their
> callbacks. Therefore, REG modules are not allowed to sleep in their
> request hooks.
Ah, right: Forgot about REG in this case. Yes, you are right for REG
registered stuff: I guess we should use a semaphore there. It can
take too long for a spinlock anyway.
Reflecting about it, there might also be some cases where
rsbac_adf_request is called from within a spinlock - must check that
to be sure.
> >Only list operations with spinlocks held must not sleep.
rsbac_kmalloc
> >is mostly called from list functions, which hold a spinlock when
> >adding or removing items. In 2.6 memory allocations with spinlocks
> >held must be with ATOMIC. In 2.4 it works very will with normal
> >GFP_KERNEL.
>
> Why the difference between 2.4 and 2.6? Did you experience lock-ups?
> Because, GFP_KERNEL allocations while holding a lock are not fine
under
> 2.4 as well. You were probably just very lucky to get away with
them.
I never had such lockups with 2.4. Maybe I was really lucky, maybe it
does not matter that much.
> >> 4. RSBAC source code is full of enums, unions and structures
named
> >like
> >> struct rsbac_something_t. They are not typedef-ed, so why they
have
> >_t
> >> suffix? I thought that it is a convention that typedef-ed type
> >should have
> >> _t added to them and this is confusing.
> >
> >Conventions differ between coders. I guess I broke several
conventions
> >of Linux kernel hacking, because using my own coding style lets me
> >code significantly faster. This may lead to some confusion for
> >others, but on the other hand many people said they liked my style
> >better. :)
>
> I don't think that _t is a convention of Linux kernel hacking but a
more
> general one. I might be wrong though.
Adding the _t for all types is what I learned when I started coding. I
just got used to that, but could live with a patch removing all these
suffixes. Coding style is something which should probably be
discussed among RSBAC developers. So far nobody really complained.
Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
More information about the rsbac
mailing list