oops with 2.4.30

Hello,

I've been running a a 2.4.30 kernel with the 0.8.73 ACL patch on an ext3 
filesystem for quite a while now, however I haven't used actual ACLs 
very much.  This is for a home server, so I'm the only one who uses it 
most of the time.

The other day I tried adding an ACL to a home directory, which worked 
fine, but then a subsequent chmod of the directory (to change the 
"group" and "other" permissions) caused a kernel oops.  Worse than that, 
I couldn't do anything with the directory afterwards, including remove 
it, without an oops.  When the oops happens, the process that was making 
the change would be put into an uninteruptable sleep until I rebooted 
(cut the power).

I was finally able to remove the directory completely by booting with a 
rescue cd which didn't understand ACLs.  After that I had to fsck the 
filesystem to get things back to normal.  I don't think the filesystem 
was damaged before the oops, as it just got a routine check a couple 
weeks ago, and it's on a software RAID-1, with no disk errors reported.

Any ideas on what might be causing this, and how I can fix it?  Is 
anyone else running a 2.4.30 kernel without problems?

Thanks,

Nathan

---

My system:

Distro: Debian Sarge
chmod version: chmod (coreutils) 5.2.1
glibc version: 2.3.2.ds1-22
Kernel: self-compiled 2.4.30, with no other patches applied

The oops message:

Unable to handle kernel NULL pointer dereference at virtual address 00000014
c0152d44
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0152d44>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 008d0b20   ebx: db46d030   ecx: 0000001f   edx: 00000000
esi: 00000fdc   edi: 00000906   ebp: 00000000   esp: c7467e2c
ds: 0018   es: 0018   ss: 0018
Process chmod (pid: 30806, stackpage=c7467000)
Stack: db46d030 00000fdc ffffffe4 db46d020 c444bf20 c024f94d c3b3b0e0 
c0137618
        00000906 008d021a 00001000 c0a923c0 c01640f8 00000000 00000906 
008d021a
        d59ab220 c444bf20 00000001 c3b3b0e0 c3b3b274 00000013 0000001f 
d25d16c0
Call Trace:    [<c0137618>] [<c01640f8>] [<c0164b31>] [<c0164e0d>] 
[<c0165235>]
   [<c015e617>] [<c0149002>] [<c01350c9>] [<c01085f3>]
Code: f7 75 14 8b 45 1c 8b 0c d0 8d 04 d0 39 c1 0f 84 78 01 00 00


 >>EIP; c0152d44 <mb_cache_entry_get+18/1b0>   <=====

 >>ebx; db46d030 <_end+1b146c78/204f3ca8>
 >>esp; c7467e2c <_end+7141a74/204f3ca8>

Trace; c0137618 <bread+18/70>
Trace; c01640f8 <ext3_xattr_set_handle+324/798>
Trace; c0164b31 <ext3_acl_to_disk+39/bc>
Trace; c0164e0d <ext3_do_set_acl+105/19c>
Trace; c0165235 <ext3_acl_chmod+a9/c8>
Trace; c015e617 <ext3_setattr+297/314>
Trace; c0149002 <notify_change+52/150>
Trace; c01350c9 <sys_chmod+79/90>
Trace; c01085f3 <system_call+33/38>

Code;  c0152d44 <mb_cache_entry_get+18/1b0>
00000000 <_EIP>:
Code;  c0152d44 <mb_cache_entry_get+18/1b0>   <=====
    0:   f7 75 14                  divl   0x14(%ebp)   <=====
Code;  c0152d47 <mb_cache_entry_get+1b/1b0>
    3:   8b 45 1c                  mov    0x1c(%ebp),%eax
Code;  c0152d4a <mb_cache_entry_get+1e/1b0>
    6:   8b 0c d0                  mov    (%eax,%edx,8),%ecx
Code;  c0152d4d <mb_cache_entry_get+21/1b0>
    9:   8d 04 d0                  lea    (%eax,%edx,8),%eax
Code;  c0152d50 <mb_cache_entry_get+24/1b0>
    c:   39 c1                     cmp    %eax,%ecx
Code;  c0152d52 <mb_cache_entry_get+26/1b0>
    e:   0f 84 78 01 00 00         je     18c <_EIP+0x18c>
_______________________________________________
acl-devel mailing list
[email protected]
http://acl.bestbits.at/mailman/listinfo/acl-devel