Hi guys,

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[1], 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:

mkdir /mnt/This.Is.A.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)
fjord#
fjord# sync
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)
db>

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.


Lundy


[1] - Some clean up done, removed M_CLEAR from most malloc calls etc. 
"Shouldn't" affect it?

-- 
Jorgen "Lord" Lundman <lundman@lundman.net>
Technology Manager, Unix Administrator
Phone: +44 (0)20-86591860  Mobile: +44 (0)79-58642918
Pager: 07958642918@one2one.net
"Rare is the person who can weigh the faults of others
  without putting his thumb on the scales": Byron J. Langenfeld