Latest working kernel version: 2.6.23.15-137.fc8 Earliest failing kernel version: 2.6.24.3-12.fc8 Distribution: Fedora 8 Hardware Environment: VIA C7, gPC, Everex TC2502, PCI eSATA card: sil 3114 (Addonics), x4 Seagate external sata HDDs in RAID5. Software Environment: Problem Description: CIFS/Samba mount fails, neither the mount or modprobe cifs completes Cut from ps auxww: root 4467 0.0 0.1 1904 680 pts/0 D 20:50 0:00 /sbin/mount.cifs //winxp/share /share -o rw,username=user,uid=500,gid=500 root 4469 0.0 0.1 1812 452 ? D 20:50 0:00 /sbin/modprobe -q -- cifs Steps to reproduce: type the following: sudo mount -t cifs -o username=user,uid=500,gid=500 //winxp/share /share hit return, then I get the kernel bug message below: (This works just fine under 2.6.23.15-137.fc8) /proc/cpuinfo: processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 10 model name : VIA Esther processor 1500MHz stepping : 9 cpu MHz : 1500.011 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx up pni rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en bogomips : 3002.45 clflush size : 64 ------------[ cut here ]------------ kernel BUG at arch/x86/mm/highmem_32.c:70! invalid opcode: 0000 [#1] SMP Modules linked in: padlock_sha sha256_generic geode_aes padlock_aes aes_i586 aes_generic cbc blkcipher dm_crypt ipt_MASQUERADE iptable_nat nf_nat bridge autofs4 fuse sunrpc nf_conntrack_ipv4 ipt_REJECT iptable_filter ip_tables nf_conntrack_ipv6 xt_state nf_conntrack xt_tcpudp ip6t_ipv6header ip6t_REJECT ip6table_filter ip6_tables x_tables ipv6 ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi scsi_transport_iscsi dm_multipath raid456 async_xor async_memcpy async_tx xor snd_via82xx gameport snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss parport_pc parport snd_mixer_oss snd_pcm snd_timer 8139too snd_page_alloc snd_mpu401_uart floppy snd_rawmidi serio_raw pcspkr i2c_viapro 8139cp snd_seq_device snd i2c_core mii soundcore usb_storage button sg sr_mod cdrom sata_via sata_sil dm_snapshot dm_zero dm_mirror dm_mod ata_generic pata_acpi pata_via libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd Pid: 4434, comm: modprobe Not tainted (2.6.24.3-34.fc8 #1) EIP: 0060:[<c0423feb>] EFLAGS: 00010206 CPU: 0 EIP is at kunmap_atomic+0x77/0xad EAX: fffb2000 EBX: dcd5c000 ECX: 00000000 EDX: 0004d000 ESI: 00000058 EDI: 00000007 EBP: dcd5c058 ESP: c5457d50 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 4434, ti=c5457000 task=d23593b0 task.ti=c5457000) Stack: 00000000 c0723d00 00000058 0001e8f4 dcd5c058 c04e6556 00000000 c5457db0 c3d51bf4 c3e1d780 00000003 c139ab80 00000fa8 dcd5c000 c3e1d780 00000058 c5457dc0 c3d51bc0 dccff212 c5457db0 c5457db0 0001e8f4 0000005b c3d51bf4 Call Trace: [<c04e6556>] update2+0xf2/0x144 [<dccff212>] padlock_sha_update+0x133/0x15e [padlock_sha] [<c04e6723>] update_kernel+0xf/0x1f [<c044e434>] module_verify_signature+0x4a8/0x564 [<c04421bb>] hrtimer_interrupt+0x192/0x1bb [<c044d939>] module_verify+0x4d/0x6c [<c04334a0>] irq_exit+0x53/0x6b [<c044be04>] sys_init_module+0xd6/0x15f9 [<c0488e3b>] do_sync_read+0xc7/0x10a [<c0484d05>] __slab_free+0x5e/0x204 [<c043f0a1>] autoremove_wake_function+0x0/0x35 [<c0478b2e>] do_munmap+0x193/0x1ac [<c045e06a>] audit_syscall_exit+0x2c7/0x2e3 [<c045dd79>] audit_syscall_entry+0x10d/0x137 [<c04080dc>] do_syscall_trace+0xd7/0xde [<c04051da>] syscall_call+0x7/0xb ======================= Code: 89 da 55 e8 34 e7 ff ff 90 8d 64 24 04 89 d8 e8 6b e1 ff ff 90 eb 18 81 fb ff ff ff bf 77 04 0f 0b eb fe 3b 1d 0c a7 83 c0 72 04 <0f> 0b eb fe e8 4f e1 ff ff 48 75 0c 8d b6 00 00 00 00 8d b6 00 EIP: [<c0423feb>] kunmap_atomic+0x77/0xad SS:ESP 0068:c5457d50 ---[ end trace 30fd7e378b630fff ]---
This regression looks like your stuff, Herbert. kmap debugging thinks that update2() is passing a garbage address into kunmap_atomic(). I can't see how this can happen :(
On Wed, Mar 19, 2008 at 10:42:38PM -0700, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10287 > > > akpm@osdl.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |akpm@osdl.org > AssignedTo|other_modules@kernel- |herbert@gondor.apana.org.au > |bugs.osdl.org | > Regression|0 |1 > > > > > ------- Comment #1 from akpm@osdl.org 2008-03-19 22:42 ------- > This regression looks like your stuff, Herbert. > > kmap debugging thinks that update2() is passing a garbage address into > kunmap_atomic(). > > I can't see how this can happen :( Actually this is caused by the module signature checking patch using the crypto layer in a way that's not intended. This stuff isn't mainline so has never been reveiewed properly. Cheers,
So I suggest that this bug be reported in the Fedora bugzilla instead as they're the one carrying the module signature patch. Thanks!
Sorry to bother, I will take it up with the Fedora crew. Thanks :^) --James