I think we (FreeS/WAN) have stumbled upon structure locking issues.
They manifest themselves while processing packets using information
from kernel structures and having userspace daemons change that
information at the same time (uni-processor, but expect more issues
with SMP).
I have been looking at code from other parts of the kernel for a few
days, trying to figure out the best way to do this.
I started with start_bh_atomic(); and end_bh_atomic(); around bits of
code called from userspace that change kernel tables to prevent them
from changing something while another part of the bottom half uses the
information while processing incoming or outgoing packets. This
simply results in a hard crash, pointing to an address that seems to
be in "way-out-woop-woop", to borrow an expression from our friends
down under...
An example of this that got mangled by the slow serial console is:
Sep 29 00:32:53 gonzales kernel: pty: 256 UnixUnable to handle kernel
paging req
uest98 ptys configur at virtual address 40099ce0
ed
Sep 29 00:3current->tss.cr3 = 00e66000, %cr3 = 00e66000
2:53 gonzales ke*pde = 00ea6067
rnel: sym53c8xx:*pte = 00000000
setting PCI_COMOops: 0004
CPU: 0
EIP: 0023:[<40099ce0>]
EFLAGS: 00010202
eax: 40099ce0 ebx: 4000a3c8 ecx: 400a8414 edx: 0000000d
esi: 4000ab70 edi: 00000000 ebp: bffffcfc esp: bffffcf0
ds: 002b es: 002b ss: 002b
Process eroute (pid: 432, process nr: 8, stackpage=c0e71000)
MAND_PARITY...(fAiee, killing interrupt handler
ix-up)
Sep 29 Scheduling in interrupt
00:32:53 gonzaleUnable to handle kernel NULL pointer dereferences
kernel: sym53c
at virtual address 00000000
875-0: resettingcurrent->tss.cr3 = 00101000, %cr3 = 00101000
, command proces*pde = 00000000
sing suspended fOops: 0002
(which brings up another question: how can I change the serial
console speed from its default of 9600? I have tried with lilo
options, but it lasts only as long as loading the kernel, then reverts
to 9600?!?)
The address of interest is 0x40099ce0, which keeps surfacing, no
matter what I change. kdb doesn't seem to be able to help me here...
kdb> id 40099ce0
0x9ca3: kdb: Bad user address 0x9ca3
addb %al,(%eax)
0x9ca5: addb %al,(%eax)
0x9ca7: addb %al,(%eax)
0x9ca9: addb %al,(%eax)
0x9cab: addb %al,(%eax)
0x9cad: addb %al,(%eax)
0x9caf: addb %al,(%eax)
0x9cb1: addb %al,(%eax)
0x9cb3: addb %al,(%eax)
0x9cb5: addb %al,(%eax)
0x9cb7: addb %al,(%eax)
0x9cb9: addb %al,(%eax)
0x9cbb: addb %al,(%eax)
0x9cbd: addb %al,(%eax)
0x9cbf: addb %al,(%eax)
0x9cc1: addb %al,(%eax)
kdb> bt
Cannot determine function for eip = 0x40099ce0
I am suspecting that I may be missing some crucial header files.
Which ones are necessary for us to use the *_bh_atomic() functions?
Another technique I have seen is to wrap the code in cli() sti() pairs
to protect it from being used while being modified, but I understand
this is a uniprocessor technique which should be deprecated? Also, I
have most often seen it used in conjunction with saving and restoring
flags. Details? Opinions?
The third that I have used in the past is mutexes. I have seen some
examples of atomic locks, but don't see what happens on the other end.
If something sets a lock, what is to prevent another part of the code
from reading it? I was not able to find the latter.
Any hints would be great. Is there an FAQ on kernel structure
locking?
slainte mhath, RGB
- --
Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada
<http://www.conscoop.ottawa.on.ca/rgb/> </www.flora.org/afo/>
Prevent Internet Wiretapping! -- FreeS/WAN:<www.xs4all.nl/~freeswan>
Thanks for voting Green! -- <green.ca> Marillion:<www.marillion.co.uk>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBN/Oue9+sBuIhFagtAQG8TAP/ZbFat5hGGLKBo5uGp6KtJjVqgTqKo3KJ
kjOUzSBrx8u25DvBJtg5dn2yuKTGZyL1sB/HX+4j+UILfGBRf4ovbjhvREJd8Pxe
C2mpeuUPWyGhi7d+bR7Iv+qapKTT7wbwZvDlgaA0sltEEDvKyjIo1rY2oWuHjUII
4/Vf8WylXUw=
=zDRW
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/