crash in write support

Rob Latham <[email protected]> Sun, 11 May 2003 15:16:14 -0500
Newsgroups gmane.linux.file-systems.hfsplus.devel
Message-ID <[email protected]>
I've been trying out roman zippel's write support in the linux hfsplus
driver.  I've run into some problems.  I hope he's on this mailing
list ...

I have a testcase which can reliably cause a kernel oops under linux.

. linux kernel 2.4.20-ben10 on powerpc
Under mac os X (10.2.6):
. created a 1 GB hfs image in with this command:
     hdiutil create -megabytes 1024 -fs HFS+ -layout NONE hdibig.img 
Under Linux: 
. mount -o loop -t hfsplus hdibig.img.dmg /mnt/macosX
. created one directory and ran bonnie in that directory with this
command
 bonnie++ -s 750 -u rob -r 325

Here's the output:
 Using uid:1000, gid:1000.
 Writing with putc()...done
 Writing intelligently...done
 Rewriting...done
 Reading with getc()...done
 Reading intelligently...done
 start 'em...done...done...done...
 Create files in sequential order...zsh: segmentation fault  bonnie++ -s 750 -u rob -r 325

here is the oops and the backtrace:

MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c4e1e000[11423] 'bonnie++' Last syscall: 8
last math d9964000 last altivec d9964000
GPR00: 00000000 C4E1FB00 C4E1E000 E64101DC 2C000000 00000FFE 00000002 00000000
GPR08: BAE34D2C C0280000 BA2E8BA3 00000002 24008882 10020624 00000000 00000000
GPR16: 00000000 C4E1FC08 000000F8 0000000E 00000000 DADDF000 00000022 0000107C
GPR24: C4E1FBD8 0000011A C02831A4 E641020C 0000BAE3 C4E1FB38 00000002 00000002
Call backtrace:        
0000000D E9C07B00 E9C08470 E9C08AF0 E9C05E9C E9C069D4 C004B834
C004BDD8 C003D7E0 C003DBB4 C003DC34 C000627C 80030D40 10004604
100024CC 10001B6C 0FD1BD04 00000000
Warning (Oops_read): Code line not seen, dumping what data is available
                       
                       
>>NIP; e9c07a24 <[hfsplus]hfsplus_bnode_readbytes+50/110>   <=====
                       
>>GPR1; c4e1fb00 <_end+4b76f04/295ec464>
>>GPR2; c4e1e000 <_end+4b75404/295ec464>
>>GPR3; e64101dc <_end+261675e0/295ec464>
>>GPR9; c0280000 <log_buf+26cc/4000>
>>GPR17; c4e1fc08 <_end+4b7700c/295ec464>
>>GPR21; daddf000 <_end+1ab36404/295ec464>
>>GPR24; c4e1fbd8 <_end+4b76fdc/295ec464>
>>GPR26; c02831a4 <zone_table+0/c>
>>GPR27; e641020c <_end+26167610/295ec464>
>>GPR29; c4e1fb38 <_end+4b76f3c/295ec464>
                       
Trace; 0000000d Before first symbol
Trace; e9c07b00 <[hfsplus]hfsplus_bnode_read_u16+1c/30>
Trace; e9c08470 <[hfsplus]hfsplus_bnode_dump+54/bc>
Trace; e9c08af0 <[hfsplus]hfsplus_bnode_insert_rec+180/2b4>
Trace; e9c05e9c <[hfsplus]hfsplus_create_cat+128/15c>
Trace; e9c069d4 <[hfsplus]hfsplus_create+48/a4>
Trace; c004b834 <vfs_create+10c/130>
Trace; c004bdd8 <open_namei+580/608>
Trace; c003d7e0 <filp_open+3c/6c>
Trace; c003dbb4 <sys_open+68/d0>
Trace; c003dc34 <sys_creat+18/28>
Trace; c000627c <ret_from_syscall_1+0/b4>
Trace; 80030d40 Before first symbol
Trace; 10004604 Before first symbol
Trace; 100024cc Before first symbol
Trace; 10001b6c Before first symbol
Trace; 0fd1bd04 Before first symbol
Trace; 00000000 Before first symbol

Then i recompiled with 
   #define DBG_MASK (DBG_BNODE_MOD|DBG_CAT_MOD), but it ended up being
quite a bit of information.  I can send it along, or try again w/ any
other debug flags you think might be helpful.  

==rob

-- 
Rob Latham                                        Chicago, IL USA             


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com