[rsbac] 2 problems with 1.3.7

[E. de Ruiter]

Hi,

I just tried out the new enhanced kernel with rsbac 1.3.7 and it seems 
that 2 problems that we had with the previous version (enhanced 2.6.21 
kernel with rsbac 1.3.4) are still present (note: I never reported these 
problems up until now because we didn't have time to report these 
problems ..)

1)
On our test-cluster we boot from network (nfs-root filesystem), but this 
gives a problem with rsbac:
we get tons of "rsbac_get_parent(): oops - d_parent == dentry_p!" on the 
console rendering the system unusable.
For that reason we comment out the rsbac_printk call in rsbac_get_parent 
and then everything works fine (I have no idea was this message means 
and if it could do any harm .. but the system is completely usable after 
this edit).

2)
On our production cluster we saw lots of kernel-oopses in originating 
from the do_sock_read function. After some investigation it was clear 
that most of the time postfix was triggering the oops. We ran some tests 
on our test-cluster with smtp-source/smtp-sink (postfix benchmark tools) 
and it turned out we could trigger the oops reliable when using 1 
smtp-sink instance and 2 smtp-source instances each delivering 200 
messages which are quite large.
We also tested this without hyperthreading enabled on the machines 
(effectively making it a non-smp kernel) without hyperthreading we 
couldn't reproduce the problem. Also on a vanilla kernel this problem 
doesnot occur.
Futhermore we tried disabling the rsbac code in __sock_recvmsg (in 
net/socket.c) (this function is inlined in do_sock_read) this fixes the 
problem (running fine now for more than 3 months on our production 
cluster) , but I don't know what rsbac functionality is lost ..

Kind regards,

  Eric de Ruiter
  Amplixs Interaction Management