Re: RSBAC version 1.1.1 released

From: Bencsath Boldizsar <boldi@datacontact.hu>
Subject: Re: RSBAC version 1.1.1 released
Date: Fri, 23 Mar 2001 16:21:33 +0100 (CET)

Next Article (by Date): Re: RSBAC version 1.1.1 released - no more Amon Ott
Previous Article (by Date): RSBAC version 1.1.1 released Amon Ott
Top of Thread: RSBAC version 1.1.1 released Amon Ott
Next in Thread: Re: RSBAC version 1.1.1 released Amon Ott
Articles sorted by: [Date] [Author] [Subject]

After current 'unable to handle kernel paging request' stuff I checked the
thread's stack, and it was about 4-5k free. (some seconds delayed of
course from the panic;-))

I tried to change kmalloc to vmalloc, the problem disappeared from that IP
to another ;-) all IP is in the read_fd_list. Every kmalloc in the
aci_... .c has been changed. The panic tells an IP in that function. Is it
possible that some macro or something gets further kmalloces in that
routine, or the vmalloc dies?

Btw I put a debug message to the first part of the read_fd_list. The first
version (without modification, pre7) showed only 1 try to kmalloc 256
bytes. After changing to vmalloc there were about 8-9 kmalloc'es, and
after that somewhere died.

I'll put some other error messages to get the right point of the failure.
I think kmalloc can be a problem, read_fd_list uses read_lock and such
functions. Maybe not in the rsbac code itself but in other code
(reiserfs,smb, etc) there are kmalloces that grow up too much?

other thing You wrote that you count sizes and change to vmalloc if it's
too much. But I think You not always do this, at some places You don't add
these numbers. 

And again, I am a pretty bad coder and hardly ever seen a kernel code so
sorry if I say dumb things;-)

b

-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.