Subject: Disk IO / UVM and Crypt FS..
To: tech-kern <firstname.lastname@example.org>
From: Jorgen Lundman <email@example.com>
Date: 05/08/2002 10:56:02
Sorry to bring this up again, but I wrote some modifications to 'ccd' to
do a simple encrypted FS. This has been fine and working for me for
about 6 months now, in 1.5, 1.5.2, 1.5.2-release and a couple of
-current's after that.
But I recently acquired a 160g HD, so I fetched the very latest -current
(as of yesterday), the patches went in fine as there had been no
modifications to ccd.c, a little bit of clean up in
crypto/blowfish/bf_cdc.c but otherwise fine.
However, it now is fairly keen on panicing. I can create directories on
an crypted-ccd fine (using XOR method with key of ' ' (space) for
debugging) shows it is working, master disklabel is untouched, the ccd
disklabel is 'encrypted' and so is the directory:
May 2 03:23:29 fjord /netbsd: ccd_decode(0xd0451000, 8192, 128)
May 2 03:23:29 fjord /netbsd: ccd_decode(0xc8511000, 1024, 2912)
May 2 03:23:29 fjord /netbsd: ccd_decode(0xc7681000, 8192, 44154992)
[cut] memory address, size, block-num )
dd if=/dev/rwd1d of=disk count=2048 bs=1024
001EC020: 74484953 0E69530E 610E6449 52454354 |tHIS.iS.a.dIRECT|
001EC030: 4F525920 20202020 20202020 20202020 |ORY |
That is fine, however, when I eventually go to write a small file to
disk, the initial process works, but if you enter 'sync' to flush it (or
just wait) it'll die when it actually goes to write the data.
fjord# cp ccdvar.h /mnt/
May 2 03:27:39 fjord /netbsd: ccd_decode(0xce521000, 8192, 112)
May 2 03:27:39 fjord /netbsd: ccd_encode(0xd0451000, 8192, 128)
May 2 03:27:39 fjord /netbsd: ccd_decode(0xd0451000, 8192, 128)
May 2 03:27:39 fjord /netbsd: ccd_encode(0xc8511000, 1024, 2912)
May 2 03:27:39 fjord /netbsd: ccd_decode(0xc8511000, 1024, 2912)
May 2 03:27:43 fjord /netbsd: ccd_encode(0xc4b33000, 8192, 2928)
uvm_fault(0xc063ef00, 0xcb33000, 0, 2) -> e
kernel: page fault trap, code=0
Stopped in pid 819 (sync) at ccd_encode+0x83: xorb %al, 0(%edx)
Obviously something has changed, and I have to fix it. I was hoping
someone perhaps had an idea of what is going wrong to shorten the time
required to debug it. Are those memory-pages now protected (I can't
modify them), do I now need to lock them perhaps incase there are
concurrant references or am I barking up the wrong tree.
 - Some clean up done, removed M_CLEAR from most malloc calls etc.
"Shouldn't" affect it?
Jorgen "Lord" Lundman <firstname.lastname@example.org>
Technology Manager, Unix Administrator
Phone: +44 (0)20-86591860 Mobile: +44 (0)79-58642918
"Rare is the person who can weigh the faults of others
without putting his thumb on the scales": Byron J. Langenfeld