Hi Ben,
Ben Clifford <benc@hawaga.org.uk> writes:
> I've just applied this to 2.5.46, and I'm building accessfs as modules.
>
> During boot (my scripts do a probe for the accessfs modules), I get:
>
> ====
>
> Debug: sleeping function called from illegal context at mm/slab.c:1304
> Call Trace:
[stack dump]
thanks for this report. Unfortunately, I can't reproduce this
stack dump. I just built and booted a kernel with accessfs enabled as
a module. Both insmod and modprobe work here, so there must be some
additional condition, patch or config option to cause this.
> The proc/access/net/ip/bind ports appear ok and I can change permissions
> on them. (although I haven't tested to see if their permissions actually
> have effect).
At least this is working. Good to hear :-)
> I also get
>
> Debug: sleeping function called from illegal context at mm/slab.c:1304
> Call Trace:
[stack dump]
>
> followed by:
>
> Debug: sleeping function called from illegal context at mm/slab.c:1304
> Call Trace:
[stack dump]
>
> There is already a security framework initialized, register_security
> failed.
You must build CONFIG_SECURITY_CAPABILITIES as a module or disable it
for usercaps to work. Usercaps employ LSM and is built as a security
module. This means, until there's a way to stack lsm security modules,
there must be no other security module loaded.
I append my .config as a reference below.
> The directory /proc/access/capabilities appears, but it has no contents.
Since usercaps cannot be loaded, this is expected and does no harm.
There might be problems with SMP. I have added spin_locks recently and
it works here on UP, but I have no SMP for testing. So there might be
some bugs in my locking code.
Regards, Olaf.
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:19 EST