[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 
> >show yourself under 2.
> Because if I use kmalloc instead of rsbac_kmalloc, I trigger 
> 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 
> 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. 
> >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
> 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 
> 2.4 as well. You were probably just very lucky to get away with 

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 
> >like
> >> struct rsbac_something_t. They are not typedef-ed, so why they 
> >_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 
> >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 
> 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.

http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

More information about the rsbac mailing list