* [OOPS] 3.0-rc1 cifs
@ 2011-06-09 20:15 Martijn Uffing
2011-06-09 22:30 ` Jeff Layton
2011-06-15 19:55 ` Maciej Rutecki
0 siblings, 2 replies; 18+ messages in thread
From: Martijn Uffing @ 2011-06-09 20:15 UTC (permalink / raw)
To: linux-cifs; +Cc: linux-kernel
Ave People
I've got an oops with 3.0-rc1. (The same Oops also occurs with 3.0-rc2 and
the git snapshot of today linux-2.6-06e8684.)
The Oops occurs at boot time while the boot scripts try to automount a samba
share.
Last (tested) working kernel : 2.6.39
First (tested) oopsing kernel : 3.0-rc1
I'm willing to try patches, and if it's needed, I can try to
git-bisect the kernel. However, I'm short on time and thought maybe somebody
already has some idea. I did a diff between 2.6.39/3.0-rc1 and there seems
to be a lot of code churn in cifs.
Details of client/server and the Oops attached. If there are any questions
please ask and CC: to my mail address. I'm not subscribed to
linux-cifs/linux-kernel
Martijn Uffing
CLIENT:
-Debian squeeze (64 bits)
-kernel vanilla 2.6.39 working (core 2 duo)
-kernel vanilla 3.0-rc1 crashing (core 2 duo)
-fstab
X.X.X.X/sysadmin /home/XXXX/docs_sysadmin cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0 0
-cat kernelconfig|grep CIFS
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
CONFIG_CIFS_DFS_UPCALL=y
# CONFIG_CIFS_FSCACHE is not set
CONFIG_CIFS_NFSD_EXPORT=y
SERVER:
-Debian etch (32 bits)
-kernel vanilla 2.6.27.59
-samba 3.0.24-6etch10
-samba share:
[sysadmin]
path = /root/sysadmin/docs
guest ok = yes
guest only = yes
force user = root
writable = yes
printable = no
browseable = yes
hosts deny = ALL
hosts allow = X.X.X.X
OOPS:
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
svc: failed to register lockdv1 RPC service (errno 97).
Registering the dns_resolver key type
CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
IP: [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
PGD 12a9a1067 PUD 1270ef067 PMD 0
Oops: 0000 [#1] SMP
CPU 1
Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 sr_mod cdrom usbhid hid pata_marvell sky2 skge evdev snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi intel_agp intel_gtt snd_seq_midi_event snd_seq tpm_tis tpm snd_timer snd_seq_device i2c_i801 snd i2c_core uhci_hcd soundcore snd_page_alloc ehci_hcd tpm_bios pcspkr
Pid: 2065, comm: mount.cifs Not tainted 3.0.0-rc1 #1 System manufacturer P5Q-E/P5Q-E
RIP: 0010:[<ffffffffa0413286>] [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
RSP: 0018:ffff880127d17b48 EFLAGS: 00010282
RAX: ffff88012a905400 RBX: ffff880129dc4200 RCX: 0000000000000000
RDX: 0000000000000811 RSI: ffff88012a9055ea RDI: ffff88012a905578
RBP: ffff880127d17ba8 R08: 0000000000000005 R09: 0000000000000001
R10: ffff88012638d600 R11: ffffffffa00600c0 R12: ffff880128bd0140
R13: 0000000000000000 R14: ffff880128bd016f R15: 0000000000000000
FS: 00007f4cbf033700(0000) GS:ffff88012fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000000a0 CR3: 000000012a9f1000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mount.cifs (pid: 2065, threadinfo ffff880127d16000, task ffff880127b26880)
Stack:
ffff8801273a5900 ffff88012638d600 ffffffffa00600c0 0000000300000001
ffff880127d17b78 ffff88012a905560 ffff880127d17ba8 ffff880127d17c74
ffff880127d17c68 ffff880129dc4200 00000000fffffff4 ffff8801279b7f01
Call Trace:
[<ffffffffa041479e>] get_dfs_path+0x11e/0x190 [cifs]
[<ffffffffa041492c>] expand_dfs_referral+0x11c/0x220 [cifs]
[<ffffffffa0425b55>] ? cifs_buf_release+0x15/0x20 [cifs]
[<ffffffffa040d211>] ? CIFSSMBQFSAttributeInfo+0x1b1/0x260 [cifs]
[<ffffffffa0415dc5>] cifs_mount+0x2c5/0x5d0 [cifs]
[<ffffffff810b2c7d>] ? bdi_setup_and_register+0x7d/0xa0
[<ffffffffa0408311>] cifs_do_mount+0x1f1/0x3b0 [cifs]
[<ffffffff810db35b>] mount_fs+0x1b/0xd0
[<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0
[<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110
[<ffffffff810f732b>] do_mount+0x2cb/0x7d0
[<ffffffff810f78c3>] sys_mount+0x93/0xe0
[<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b
Code: b4 02 00 10 0f 84 e7 02 00 00 48 8b 73 40 8b be cc 01 00 00 85 ff 0f 84 de 02 00 00 4c 89 55 a8 4c 89 5d b0 48 81 c6 ea 01 00 00
8b bd a0 00 00 00 4c 89 f2 e8 3b 37 01 00 4c 8b 5d b0 4c 8b
RIP [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
RSP <ffff880127d17b48>
CR2: 00000000000000a0
---[ end trace 64d92145e3df4829 ]---
-----------------------------------------
Ceterum censeo Carthaginem esse delendam
When it comes to procrastination, casting the first stone is definitely on
my TO DO list.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [OOPS] 3.0-rc1 cifs 2011-06-09 20:15 [OOPS] 3.0-rc1 cifs Martijn Uffing @ 2011-06-09 22:30 ` Jeff Layton 2011-06-09 22:50 ` Connor Hansen 2011-06-15 19:55 ` Maciej Rutecki 1 sibling, 1 reply; 18+ messages in thread From: Jeff Layton @ 2011-06-09 22:30 UTC (permalink / raw) To: Martijn Uffing; +Cc: linux-cifs, linux-kernel On Thu, 9 Jun 2011 22:15:05 +0200 (CEST) Martijn Uffing <mp3project@sarijopen.student.utwente.nl> wrote: > > Ave People > > > I've got an oops with 3.0-rc1. (The same Oops also occurs with 3.0-rc2 and > the git snapshot of today linux-2.6-06e8684.) > The Oops occurs at boot time while the boot scripts try to automount a samba > share. > > Last (tested) working kernel : 2.6.39 > First (tested) oopsing kernel : 3.0-rc1 > > I'm willing to try patches, and if it's needed, I can try to > git-bisect the kernel. However, I'm short on time and thought maybe somebody > already has some idea. I did a diff between 2.6.39/3.0-rc1 and there seems > to be a lot of code churn in cifs. > > Details of client/server and the Oops attached. If there are any questions > please ask and CC: to my mail address. I'm not subscribed to > linux-cifs/linux-kernel > > Martijn Uffing > > > > CLIENT: > > -Debian squeeze (64 bits) > -kernel vanilla 2.6.39 working (core 2 duo) > -kernel vanilla 3.0-rc1 crashing (core 2 duo) > -fstab > X.X.X.X/sysadmin /home/XXXX/docs_sysadmin cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0 0 > -cat kernelconfig|grep CIFS > CONFIG_CIFS=m > CONFIG_CIFS_STATS=y > # CONFIG_CIFS_STATS2 is not set > CONFIG_CIFS_WEAK_PW_HASH=y > CONFIG_CIFS_UPCALL=y > # CONFIG_CIFS_XATTR is not set > # CONFIG_CIFS_DEBUG2 is not set > CONFIG_CIFS_DFS_UPCALL=y > # CONFIG_CIFS_FSCACHE is not set > CONFIG_CIFS_NFSD_EXPORT=y > > > SERVER: > -Debian etch (32 bits) > -kernel vanilla 2.6.27.59 > -samba 3.0.24-6etch10 > -samba share: > [sysadmin] > path = /root/sysadmin/docs > guest ok = yes > guest only = yes > force user = root > writable = yes > printable = no > browseable = yes > hosts deny = ALL > hosts allow = X.X.X.X > > OOPS: > Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > svc: failed to register lockdv1 RPC service (errno 97). > Registering the dns_resolver key type > CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 > BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 > IP: [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs] > PGD 12a9a1067 PUD 1270ef067 PMD 0 > Oops: 0000 [#1] SMP > CPU 1 > Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 sr_mod cdrom usbhid hid pata_marvell sky2 skge evdev snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi intel_agp intel_gtt snd_seq_midi_event snd_seq tpm_tis tpm snd_timer snd_seq_device i2c_i801 snd i2c_core uhci_hcd soundcore snd_page_alloc ehci_hcd tpm_bios pcspkr > > Pid: 2065, comm: mount.cifs Not tainted 3.0.0-rc1 #1 System manufacturer P5Q-E/P5Q-E > RIP: 0010:[<ffffffffa0413286>] [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs] > RSP: 0018:ffff880127d17b48 EFLAGS: 00010282 > RAX: ffff88012a905400 RBX: ffff880129dc4200 RCX: 0000000000000000 > RDX: 0000000000000811 RSI: ffff88012a9055ea RDI: ffff88012a905578 > RBP: ffff880127d17ba8 R08: 0000000000000005 R09: 0000000000000001 > R10: ffff88012638d600 R11: ffffffffa00600c0 R12: ffff880128bd0140 > R13: 0000000000000000 R14: ffff880128bd016f R15: 0000000000000000 > FS: 00007f4cbf033700(0000) GS:ffff88012fd00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 00000000000000a0 CR3: 000000012a9f1000 CR4: 00000000000406e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process mount.cifs (pid: 2065, threadinfo ffff880127d16000, task ffff880127b26880) > Stack: > ffff8801273a5900 ffff88012638d600 ffffffffa00600c0 0000000300000001 > ffff880127d17b78 ffff88012a905560 ffff880127d17ba8 ffff880127d17c74 > ffff880127d17c68 ffff880129dc4200 00000000fffffff4 ffff8801279b7f01 > Call Trace: > [<ffffffffa041479e>] get_dfs_path+0x11e/0x190 [cifs] > [<ffffffffa041492c>] expand_dfs_referral+0x11c/0x220 [cifs] > [<ffffffffa0425b55>] ? cifs_buf_release+0x15/0x20 [cifs] > [<ffffffffa040d211>] ? CIFSSMBQFSAttributeInfo+0x1b1/0x260 [cifs] > [<ffffffffa0415dc5>] cifs_mount+0x2c5/0x5d0 [cifs] > [<ffffffff810b2c7d>] ? bdi_setup_and_register+0x7d/0xa0 > [<ffffffffa0408311>] cifs_do_mount+0x1f1/0x3b0 [cifs] > [<ffffffff810db35b>] mount_fs+0x1b/0xd0 > [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0 > [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110 > [<ffffffff810f732b>] do_mount+0x2cb/0x7d0 > [<ffffffff810f78c3>] sys_mount+0x93/0xe0 > [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b > Code: b4 02 00 10 0f 84 e7 02 00 00 48 8b 73 40 8b be cc 01 00 00 85 ff 0f 84 de 02 00 00 4c 89 55 a8 4c 89 5d b0 48 81 c6 ea 01 00 00 > 8b bd a0 00 00 00 4c 89 f2 e8 3b 37 01 00 4c 8b 5d b0 4c 8b > RIP [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs] > RSP <ffff880127d17b48> > CR2: 00000000000000a0 > ---[ end trace 64d92145e3df4829 ]--- > Thanks for the bug report, Martin. Can you do the following to get us a listing of the place where it fell down? http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses That should give us a better idea of what went wrong. Thanks, -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-09 22:30 ` Jeff Layton @ 2011-06-09 22:50 ` Connor Hansen 2011-06-09 22:53 ` Connor Hansen 2011-06-10 0:57 ` Martijn Uffing 0 siblings, 2 replies; 18+ messages in thread From: Connor Hansen @ 2011-06-09 22:50 UTC (permalink / raw) To: Jeff Layton; +Cc: Martijn Uffing, linux-cifs, linux-kernel On Thu, Jun 9, 2011 at 3:30 PM, Jeff Layton <jlayton@redhat.com> wrote: > On Thu, 9 Jun 2011 22:15:05 +0200 (CEST) > Martijn Uffing <mp3project@sarijopen.student.utwente.nl> wrote: > >> >> Ave People >> >> >> I've got an oops with 3.0-rc1. (The same Oops also occurs with 3.0-rc2 and >> the git snapshot of today linux-2.6-06e8684.) >> The Oops occurs at boot time while the boot scripts try to automount a samba >> share. >> >> Last (tested) working kernel : 2.6.39 >> First (tested) oopsing kernel : 3.0-rc1 >> >> I'm willing to try patches, and if it's needed, I can try to >> git-bisect the kernel. However, I'm short on time and thought maybe somebody >> already has some idea. I did a diff between 2.6.39/3.0-rc1 and there seems >> to be a lot of code churn in cifs. >> >> Details of client/server and the Oops attached. If there are any questions >> please ask and CC: to my mail address. I'm not subscribed to >> linux-cifs/linux-kernel >> >> Martijn Uffing >> >> >> >> CLIENT: >> >> -Debian squeeze (64 bits) >> -kernel vanilla 2.6.39 working (core 2 duo) >> -kernel vanilla 3.0-rc1 crashing (core 2 duo) >> -fstab >> X.X.X.X/sysadmin /home/XXXX/docs_sysadmin cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0 0 >> -cat kernelconfig|grep CIFS >> CONFIG_CIFS=m >> CONFIG_CIFS_STATS=y >> # CONFIG_CIFS_STATS2 is not set >> CONFIG_CIFS_WEAK_PW_HASH=y >> CONFIG_CIFS_UPCALL=y >> # CONFIG_CIFS_XATTR is not set >> # CONFIG_CIFS_DEBUG2 is not set >> CONFIG_CIFS_DFS_UPCALL=y >> # CONFIG_CIFS_FSCACHE is not set >> CONFIG_CIFS_NFSD_EXPORT=y >> >> >> SERVER: >> -Debian etch (32 bits) >> -kernel vanilla 2.6.27.59 >> -samba 3.0.24-6etch10 >> -samba share: >> [sysadmin] >> path = /root/sysadmin/docs >> guest ok = yes >> guest only = yes >> force user = root >> writable = yes >> printable = no >> browseable = yes >> hosts deny = ALL >> hosts allow = X.X.X.X >> >> OOPS: >> Installing knfsd (copyright (C) 1996 okir@monad.swb.de). >> svc: failed to register lockdv1 RPC service (errno 97). >> Registering the dns_resolver key type >> CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 >> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 >> IP: [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs] >> PGD 12a9a1067 PUD 1270ef067 PMD 0 >> Oops: 0000 [#1] SMP >> CPU 1 >> Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 sr_mod cdrom usbhid hid pata_marvell sky2 skge evdev snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi intel_agp intel_gtt snd_seq_midi_event snd_seq tpm_tis tpm snd_timer snd_seq_device i2c_i801 snd i2c_core uhci_hcd soundcore snd_page_alloc ehci_hcd tpm_bios pcspkr >> >> Pid: 2065, comm: mount.cifs Not tainted 3.0.0-rc1 #1 System manufacturer P5Q-E/P5Q-E call in get_dfs_path() rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); function header for CIFSTCon int CIFSTCon(unsigned int xid, struct cifs_ses *ses, const char *tree, struct cifs_tcon *tcon, const struct nls_table *nls_codepage) get_dfs_path() is passing struct cifs_tcon *tcon as NULL from config: CONFIG_CIFS_WEAK_PW_HASH=y in CIFSTCon #ifdef CONFIG_CIFS_WEAK_PW_HASH 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && 3223 (ses->server->secType == LANMAN)) 3224 calc_lanman_hash(tcon->password, ses->server->cryptkey, in calc_lanman_hash tcon is dereferenced(tcon->password) without being checked if null 3225 ses->server->sec_mode & 3226 SECMODE_PW_ENCRYPT ? true : false, 3227 bcc_ptr); 3228 else 3229 #endif /* CIFS_WEAK_PW_HASH */ Connor >> RIP: 0010:[<ffffffffa0413286>] [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs] >> RSP: 0018:ffff880127d17b48 EFLAGS: 00010282 >> RAX: ffff88012a905400 RBX: ffff880129dc4200 RCX: 0000000000000000 >> RDX: 0000000000000811 RSI: ffff88012a9055ea RDI: ffff88012a905578 >> RBP: ffff880127d17ba8 R08: 0000000000000005 R09: 0000000000000001 >> R10: ffff88012638d600 R11: ffffffffa00600c0 R12: ffff880128bd0140 >> R13: 0000000000000000 R14: ffff880128bd016f R15: 0000000000000000 >> FS: 00007f4cbf033700(0000) GS:ffff88012fd00000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >> CR2: 00000000000000a0 CR3: 000000012a9f1000 CR4: 00000000000406e0 >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >> Process mount.cifs (pid: 2065, threadinfo ffff880127d16000, task ffff880127b26880) >> Stack: >> ffff8801273a5900 ffff88012638d600 ffffffffa00600c0 0000000300000001 >> ffff880127d17b78 ffff88012a905560 ffff880127d17ba8 ffff880127d17c74 >> ffff880127d17c68 ffff880129dc4200 00000000fffffff4 ffff8801279b7f01 >> Call Trace: >> [<ffffffffa041479e>] get_dfs_path+0x11e/0x190 [cifs] >> [<ffffffffa041492c>] expand_dfs_referral+0x11c/0x220 [cifs] >> [<ffffffffa0425b55>] ? cifs_buf_release+0x15/0x20 [cifs] >> [<ffffffffa040d211>] ? CIFSSMBQFSAttributeInfo+0x1b1/0x260 [cifs] >> [<ffffffffa0415dc5>] cifs_mount+0x2c5/0x5d0 [cifs] >> [<ffffffff810b2c7d>] ? bdi_setup_and_register+0x7d/0xa0 >> [<ffffffffa0408311>] cifs_do_mount+0x1f1/0x3b0 [cifs] >> [<ffffffff810db35b>] mount_fs+0x1b/0xd0 >> [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0 >> [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110 >> [<ffffffff810f732b>] do_mount+0x2cb/0x7d0 >> [<ffffffff810f78c3>] sys_mount+0x93/0xe0 >> [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b >> Code: b4 02 00 10 0f 84 e7 02 00 00 48 8b 73 40 8b be cc 01 00 00 85 ff 0f 84 de 02 00 00 4c 89 55 a8 4c 89 5d b0 48 81 c6 ea 01 00 00 >> 8b bd a0 00 00 00 4c 89 f2 e8 3b 37 01 00 4c 8b 5d b0 4c 8b >> RIP [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs] >> RSP <ffff880127d17b48> >> CR2: 00000000000000a0 >> ---[ end trace 64d92145e3df4829 ]--- >> > > Thanks for the bug report, Martin. Can you do the following to get us a > listing of the place where it fell down? > > http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses > > That should give us a better idea of what went wrong. > > Thanks, > -- > Jeff Layton <jlayton@redhat.com> > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-09 22:50 ` Connor Hansen @ 2011-06-09 22:53 ` Connor Hansen 2011-06-10 0:57 ` Martijn Uffing 1 sibling, 0 replies; 18+ messages in thread From: Connor Hansen @ 2011-06-09 22:53 UTC (permalink / raw) To: Jeff Layton; +Cc: Martijn Uffing, linux-cifs, linux-kernel On Thu, Jun 9, 2011 at 3:50 PM, Connor Hansen <cmdkhh@gmail.com> wrote: > On Thu, Jun 9, 2011 at 3:30 PM, Jeff Layton <jlayton@redhat.com> wrote: >> On Thu, 9 Jun 2011 22:15:05 +0200 (CEST) >> Martijn Uffing <mp3project@sarijopen.student.utwente.nl> wrote: >> >>> >>> Ave People >>> >>> >>> I've got an oops with 3.0-rc1. (The same Oops also occurs with 3.0-rc2 and >>> the git snapshot of today linux-2.6-06e8684.) >>> The Oops occurs at boot time while the boot scripts try to automount a samba >>> share. >>> >>> Last (tested) working kernel : 2.6.39 >>> First (tested) oopsing kernel : 3.0-rc1 >>> >>> I'm willing to try patches, and if it's needed, I can try to >>> git-bisect the kernel. However, I'm short on time and thought maybe somebody >>> already has some idea. I did a diff between 2.6.39/3.0-rc1 and there seems >>> to be a lot of code churn in cifs. >>> >>> Details of client/server and the Oops attached. If there are any questions >>> please ask and CC: to my mail address. I'm not subscribed to >>> linux-cifs/linux-kernel >>> >>> Martijn Uffing >>> >>> >>> >>> CLIENT: >>> >>> -Debian squeeze (64 bits) >>> -kernel vanilla 2.6.39 working (core 2 duo) >>> -kernel vanilla 3.0-rc1 crashing (core 2 duo) >>> -fstab >>> X.X.X.X/sysadmin /home/XXXX/docs_sysadmin cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0 0 >>> -cat kernelconfig|grep CIFS >>> CONFIG_CIFS=m >>> CONFIG_CIFS_STATS=y >>> # CONFIG_CIFS_STATS2 is not set >>> CONFIG_CIFS_WEAK_PW_HASH=y >>> CONFIG_CIFS_UPCALL=y >>> # CONFIG_CIFS_XATTR is not set >>> # CONFIG_CIFS_DEBUG2 is not set >>> CONFIG_CIFS_DFS_UPCALL=y >>> # CONFIG_CIFS_FSCACHE is not set >>> CONFIG_CIFS_NFSD_EXPORT=y >>> >>> >>> SERVER: >>> -Debian etch (32 bits) >>> -kernel vanilla 2.6.27.59 >>> -samba 3.0.24-6etch10 >>> -samba share: >>> [sysadmin] >>> path = /root/sysadmin/docs >>> guest ok = yes >>> guest only = yes >>> force user = root >>> writable = yes >>> printable = no >>> browseable = yes >>> hosts deny = ALL >>> hosts allow = X.X.X.X >>> >>> OOPS: >>> Installing knfsd (copyright (C) 1996 okir@monad.swb.de). >>> svc: failed to register lockdv1 RPC service (errno 97). >>> Registering the dns_resolver key type >>> CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 >>> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 >>> IP: [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs] >>> PGD 12a9a1067 PUD 1270ef067 PMD 0 >>> Oops: 0000 [#1] SMP >>> CPU 1 >>> Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 sr_mod cdrom usbhid hid pata_marvell sky2 skge evdev snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi intel_agp intel_gtt snd_seq_midi_event snd_seq tpm_tis tpm snd_timer snd_seq_device i2c_i801 snd i2c_core uhci_hcd soundcore snd_page_alloc ehci_hcd tpm_bios pcspkr >>> >>> Pid: 2065, comm: mount.cifs Not tainted 3.0.0-rc1 #1 System manufacturer P5Q-E/P5Q-E > > call in get_dfs_path() > rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); > > function header for CIFSTCon > int CIFSTCon(unsigned int xid, struct cifs_ses *ses, > const char *tree, struct cifs_tcon *tcon, > const struct nls_table *nls_codepage) > > get_dfs_path() is passing struct cifs_tcon *tcon as NULL > > from config: CONFIG_CIFS_WEAK_PW_HASH=y > > in CIFSTCon > > #ifdef CONFIG_CIFS_WEAK_PW_HASH > 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && > 3223 (ses->server->secType == LANMAN)) > 3224 calc_lanman_hash(tcon->password, > ses->server->cryptkey, > > in calc_lanman_hash tcon is dereferenced(tcon->password) without being > checked if null > > 3225 ses->server->sec_mode & > 3226 SECMODE_PW_ENCRYPT ? > true : false, > 3227 bcc_ptr); > 3228 else > 3229 #endif /* CIFS_WEAK_PW_HASH */ 3230 rc = SMBNTencrypt(tcon->password, ses->server->cryptkey, 3231 bcc_ptr); and again here, so would occur even without CONFIG_CIFS_WEAK_PW_HASH set > > Connor > > >>> RIP: 0010:[<ffffffffa0413286>] [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs] >>> RSP: 0018:ffff880127d17b48 EFLAGS: 00010282 >>> RAX: ffff88012a905400 RBX: ffff880129dc4200 RCX: 0000000000000000 >>> RDX: 0000000000000811 RSI: ffff88012a9055ea RDI: ffff88012a905578 >>> RBP: ffff880127d17ba8 R08: 0000000000000005 R09: 0000000000000001 >>> R10: ffff88012638d600 R11: ffffffffa00600c0 R12: ffff880128bd0140 >>> R13: 0000000000000000 R14: ffff880128bd016f R15: 0000000000000000 >>> FS: 00007f4cbf033700(0000) GS:ffff88012fd00000(0000) knlGS:0000000000000000 >>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >>> CR2: 00000000000000a0 CR3: 000000012a9f1000 CR4: 00000000000406e0 >>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>> Process mount.cifs (pid: 2065, threadinfo ffff880127d16000, task ffff880127b26880) >>> Stack: >>> ffff8801273a5900 ffff88012638d600 ffffffffa00600c0 0000000300000001 >>> ffff880127d17b78 ffff88012a905560 ffff880127d17ba8 ffff880127d17c74 >>> ffff880127d17c68 ffff880129dc4200 00000000fffffff4 ffff8801279b7f01 >>> Call Trace: >>> [<ffffffffa041479e>] get_dfs_path+0x11e/0x190 [cifs] >>> [<ffffffffa041492c>] expand_dfs_referral+0x11c/0x220 [cifs] >>> [<ffffffffa0425b55>] ? cifs_buf_release+0x15/0x20 [cifs] >>> [<ffffffffa040d211>] ? CIFSSMBQFSAttributeInfo+0x1b1/0x260 [cifs] >>> [<ffffffffa0415dc5>] cifs_mount+0x2c5/0x5d0 [cifs] >>> [<ffffffff810b2c7d>] ? bdi_setup_and_register+0x7d/0xa0 >>> [<ffffffffa0408311>] cifs_do_mount+0x1f1/0x3b0 [cifs] >>> [<ffffffff810db35b>] mount_fs+0x1b/0xd0 >>> [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0 >>> [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110 >>> [<ffffffff810f732b>] do_mount+0x2cb/0x7d0 >>> [<ffffffff810f78c3>] sys_mount+0x93/0xe0 >>> [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b >>> Code: b4 02 00 10 0f 84 e7 02 00 00 48 8b 73 40 8b be cc 01 00 00 85 ff 0f 84 de 02 00 00 4c 89 55 a8 4c 89 5d b0 48 81 c6 ea 01 00 00 >>> 8b bd a0 00 00 00 4c 89 f2 e8 3b 37 01 00 4c 8b 5d b0 4c 8b >>> RIP [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs] >>> RSP <ffff880127d17b48> >>> CR2: 00000000000000a0 >>> ---[ end trace 64d92145e3df4829 ]--- >>> >> >> Thanks for the bug report, Martin. Can you do the following to get us a >> listing of the place where it fell down? >> >> http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses >> >> That should give us a better idea of what went wrong. >> >> Thanks, >> -- >> Jeff Layton <jlayton@redhat.com> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-09 22:50 ` Connor Hansen 2011-06-09 22:53 ` Connor Hansen @ 2011-06-10 0:57 ` Martijn Uffing 2011-06-10 11:37 ` Jeff Layton 1 sibling, 1 reply; 18+ messages in thread From: Martijn Uffing @ 2011-06-10 0:57 UTC (permalink / raw) To: Connor Hansen; +Cc: Jeff Layton, linux-cifs, linux-kernel <snip> > call in get_dfs_path() > rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); > > function header for CIFSTCon > int CIFSTCon(unsigned int xid, struct cifs_ses *ses, > const char *tree, struct cifs_tcon *tcon, > const struct nls_table *nls_codepage) > > get_dfs_path() is passing struct cifs_tcon *tcon as NULL > > from config: CONFIG_CIFS_WEAK_PW_HASH=y > > in CIFSTCon > > #ifdef CONFIG_CIFS_WEAK_PW_HASH > 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && > 3223 (ses->server->secType == LANMAN)) > 3224 calc_lanman_hash(tcon->password, > ses->server->cryptkey, > > in calc_lanman_hash tcon is dereferenced(tcon->password) without being > checked if null > > 3225 ses->server->sec_mode & > 3226 SECMODE_PW_ENCRYPT ? > true : false, > 3227 bcc_ptr); > 3228 else > 3229 #endif /* CIFS_WEAK_PW_HASH */ > > Connor Ave all I recompiled kernel 3.0-rc1 (hadn't enabled CONFIG_DEBUG_INFO=y) and put the oops (with the new adresses) through gdb per instruction of Jeff. And Connor was spot on! <qoute oops> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] </qoute oops> <qoute gdb> This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /lib/modules/3.0.0-rc1-debug/kernel/fs/cifs/cifs.ko...done. (gdb) list *(CIFSTCon+0xf6) 0xc2b6 is in CIFSTCon (fs/cifs/connect.c:3230). 3225 ses->server->sec_mode & 3226 SECMODE_PW_ENCRYPT ? true : false, 3227 bcc_ptr); 3228 else 3229 #endif /* CIFS_WEAK_PW_HASH */ 3230 rc = SMBNTencrypt(tcon->password, ses->server->cryptkey, 3231 bcc_ptr); 3232 3233 bcc_ptr += CIFS_AUTH_RESP_SIZE; 3234 if (ses->capabilities & CAP_UNICODE) { (gdb) </qoute gdb> Martijn ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-10 0:57 ` Martijn Uffing @ 2011-06-10 11:37 ` Jeff Layton 2011-06-10 12:03 ` Connor Hansen 2011-06-10 22:03 ` Martijn Uffing 0 siblings, 2 replies; 18+ messages in thread From: Jeff Layton @ 2011-06-10 11:37 UTC (permalink / raw) To: Martijn Uffing; +Cc: Connor Hansen, linux-cifs, linux-kernel, sean finney On Fri, 10 Jun 2011 02:57:21 +0200 (CEST) Uffing <mp3project@sarijopen.student.utwente.nl> wrote: > > <snip> > > call in get_dfs_path() > > rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); > > > > function header for CIFSTCon > > int CIFSTCon(unsigned int xid, struct cifs_ses *ses, > > const char *tree, struct cifs_tcon *tcon, > > const struct nls_table *nls_codepage) > > > > get_dfs_path() is passing struct cifs_tcon *tcon as NULL > > > > from config: CONFIG_CIFS_WEAK_PW_HASH=y > > > > in CIFSTCon > > > > #ifdef CONFIG_CIFS_WEAK_PW_HASH > > 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && > > 3223 (ses->server->secType == LANMAN)) > > 3224 calc_lanman_hash(tcon->password, > > ses->server->cryptkey, > > > > in calc_lanman_hash tcon is dereferenced(tcon->password) without being > > checked if null > > > > 3225 ses->server->sec_mode & > > 3226 SECMODE_PW_ENCRYPT ? > > true : false, > > 3227 bcc_ptr); > > 3228 else > > 3229 #endif /* CIFS_WEAK_PW_HASH */ > > > > Connor > > > Ave all > > I recompiled kernel 3.0-rc1 (hadn't enabled CONFIG_DEBUG_INFO=y) and put > the oops (with the new adresses) through gdb per instruction of Jeff. And > Connor was spot on! > > <qoute oops> > BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 > IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] > </qoute oops> > > <qoute gdb> > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from > /lib/modules/3.0.0-rc1-debug/kernel/fs/cifs/cifs.ko...done. > (gdb) list *(CIFSTCon+0xf6) > 0xc2b6 is in CIFSTCon (fs/cifs/connect.c:3230). > 3225 ses->server->sec_mode & > 3226 SECMODE_PW_ENCRYPT ? > true : false, > 3227 bcc_ptr); > 3228 else > 3229 #endif /* CIFS_WEAK_PW_HASH */ > 3230 rc = SMBNTencrypt(tcon->password, > ses->server->cryptkey, > 3231 bcc_ptr); > 3232 > 3233 bcc_ptr += CIFS_AUTH_RESP_SIZE; > 3234 if (ses->capabilities & CAP_UNICODE) { > (gdb) > </qoute gdb> > (cc'ing Sean F. since I suspect this regression is due to his changes) Thanks for the analysis, Martijn and Connor... What sort of server are you mounting here? It looks like it's using share-level security, so it's either very old or is a samba server configured that way. I suspect that commit c1508ca236 is the culprit. With that, we call into expand_dfs_referral on every mount attempt. Previously we only called into there when we got back an EREMOTE error and that would have been unlikely on a share-level security connection. I think there are several possible solutions, but since Sean was in here most recently I'd like to have his opinion. -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-10 11:37 ` Jeff Layton @ 2011-06-10 12:03 ` Connor Hansen 2011-06-10 12:14 ` Suresh Jayaraman 2011-06-10 22:03 ` Martijn Uffing 1 sibling, 1 reply; 18+ messages in thread From: Connor Hansen @ 2011-06-10 12:03 UTC (permalink / raw) To: Jeff Layton; +Cc: Martijn Uffing, linux-cifs, linux-kernel, sean finney On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <jlayton@redhat.com> wrote: > On Fri, 10 Jun 2011 02:57:21 +0200 (CEST) > Uffing <mp3project@sarijopen.student.utwente.nl> wrote: > >> >> <snip> >> > call in get_dfs_path() >> > rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); >> > >> > function header for CIFSTCon >> > int CIFSTCon(unsigned int xid, struct cifs_ses *ses, >> > const char *tree, struct cifs_tcon *tcon, >> > const struct nls_table *nls_codepage) >> > >> > get_dfs_path() is passing struct cifs_tcon *tcon as NULL >> > >> > from config: CONFIG_CIFS_WEAK_PW_HASH=y >> > >> > in CIFSTCon >> > >> > #ifdef CONFIG_CIFS_WEAK_PW_HASH >> > 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && >> > 3223 (ses->server->secType == LANMAN)) >> > 3224 calc_lanman_hash(tcon->password, >> > ses->server->cryptkey, >> > >> > in calc_lanman_hash tcon is dereferenced(tcon->password) without being >> > checked if null >> > >> > 3225 ses->server->sec_mode & >> > 3226 SECMODE_PW_ENCRYPT ? >> > true : false, >> > 3227 bcc_ptr); >> > 3228 else >> > 3229 #endif /* CIFS_WEAK_PW_HASH */ >> > >> > Connor >> >> >> Ave all >> >> I recompiled kernel 3.0-rc1 (hadn't enabled CONFIG_DEBUG_INFO=y) and put >> the oops (with the new adresses) through gdb per instruction of Jeff. And >> Connor was spot on! >> >> <qoute oops> >> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 >> IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] >> </qoute oops> >> >> <qoute gdb> >> This GDB was configured as "x86_64-linux-gnu". >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>... >> Reading symbols from >> /lib/modules/3.0.0-rc1-debug/kernel/fs/cifs/cifs.ko...done. >> (gdb) list *(CIFSTCon+0xf6) >> 0xc2b6 is in CIFSTCon (fs/cifs/connect.c:3230). >> 3225 ses->server->sec_mode & >> 3226 SECMODE_PW_ENCRYPT ? >> true : false, >> 3227 bcc_ptr); >> 3228 else >> 3229 #endif /* CIFS_WEAK_PW_HASH */ >> 3230 rc = SMBNTencrypt(tcon->password, >> ses->server->cryptkey, >> 3231 bcc_ptr); >> 3232 >> 3233 bcc_ptr += CIFS_AUTH_RESP_SIZE; >> 3234 if (ses->capabilities & CAP_UNICODE) { >> (gdb) >> </qoute gdb> >> > > (cc'ing Sean F. since I suspect this regression is due to his changes) > > Thanks for the analysis, Martijn and Connor... > > What sort of server are you mounting here? It looks like it's using > share-level security, so it's either very old or is a samba server > configured that way. > > I suspect that commit c1508ca236 is the culprit. With that, we call > into expand_dfs_referral on every mount attempt. Previously we only > called into there when we got back an EREMOTE error and that would > have been unlikely on a share-level security connection. > > I think there are several possible solutions, but since Sean was in > here most recently I'd like to have his opinion. I don't know enough about cifs but this call in fs/cifs/connect.c 2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); will always result in a null pointer derefence as CIFSTCon uses the cifs_tcon struct for passwords without verification either we need to check for tcon for null in CIFSTCon before use, or change get_dfs_path to get the cifs_tcon info and pass it to the CIFSTCon function. But again I don't know enough about cifs to know the best approach Connor > > -- > Jeff Layton <jlayton@redhat.com> > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-10 12:03 ` Connor Hansen @ 2011-06-10 12:14 ` Suresh Jayaraman 2011-06-10 12:49 ` Connor Hansen 0 siblings, 1 reply; 18+ messages in thread From: Suresh Jayaraman @ 2011-06-10 12:14 UTC (permalink / raw) To: Connor Hansen Cc: Jeff Layton, Martijn Uffing, linux-cifs, linux-kernel, sean finney On 06/10/2011 05:33 PM, Connor Hansen wrote: > On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <jlayton@redhat.com> wrote: >> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST) >> Uffing <mp3project@sarijopen.student.utwente.nl> wrote: >> >>> >>> <snip> >>>> call in get_dfs_path() >>>> rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); >>>> >>>> function header for CIFSTCon >>>> int CIFSTCon(unsigned int xid, struct cifs_ses *ses, >>>> const char *tree, struct cifs_tcon *tcon, >>>> const struct nls_table *nls_codepage) >>>> >>>> get_dfs_path() is passing struct cifs_tcon *tcon as NULL >>>> >>>> from config: CONFIG_CIFS_WEAK_PW_HASH=y >>>> >>>> in CIFSTCon >>>> >>>> #ifdef CONFIG_CIFS_WEAK_PW_HASH >>>> 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && >>>> 3223 (ses->server->secType == LANMAN)) >>>> 3224 calc_lanman_hash(tcon->password, >>>> ses->server->cryptkey, >>>> >>>> in calc_lanman_hash tcon is dereferenced(tcon->password) without being >>>> checked if null >>>> >>>> 3225 ses->server->sec_mode & >>>> 3226 SECMODE_PW_ENCRYPT ? >>>> true : false, >>>> 3227 bcc_ptr); >>>> 3228 else >>>> 3229 #endif /* CIFS_WEAK_PW_HASH */ >>>> >>>> Connor >>> >>> >>> Ave all >>> >>> I recompiled kernel 3.0-rc1 (hadn't enabled CONFIG_DEBUG_INFO=y) and put >>> the oops (with the new adresses) through gdb per instruction of Jeff. And >>> Connor was spot on! >>> >>> <qoute oops> >>> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 >>> IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] >>> </qoute oops> >>> >>> <qoute gdb> >>> This GDB was configured as "x86_64-linux-gnu". >>> For bug reporting instructions, please see: >>> <http://www.gnu.org/software/gdb/bugs/>... >>> Reading symbols from >>> /lib/modules/3.0.0-rc1-debug/kernel/fs/cifs/cifs.ko...done. >>> (gdb) list *(CIFSTCon+0xf6) >>> 0xc2b6 is in CIFSTCon (fs/cifs/connect.c:3230). >>> 3225 ses->server->sec_mode & >>> 3226 SECMODE_PW_ENCRYPT ? >>> true : false, >>> 3227 bcc_ptr); >>> 3228 else >>> 3229 #endif /* CIFS_WEAK_PW_HASH */ >>> 3230 rc = SMBNTencrypt(tcon->password, >>> ses->server->cryptkey, >>> 3231 bcc_ptr); >>> 3232 >>> 3233 bcc_ptr += CIFS_AUTH_RESP_SIZE; >>> 3234 if (ses->capabilities & CAP_UNICODE) { >>> (gdb) >>> </qoute gdb> >>> >> >> (cc'ing Sean F. since I suspect this regression is due to his changes) >> >> Thanks for the analysis, Martijn and Connor... >> >> What sort of server are you mounting here? It looks like it's using >> share-level security, so it's either very old or is a samba server >> configured that way. >> >> I suspect that commit c1508ca236 is the culprit. With that, we call >> into expand_dfs_referral on every mount attempt. Previously we only >> called into there when we got back an EREMOTE error and that would >> have been unlikely on a share-level security connection. >> >> I think there are several possible solutions, but since Sean was in >> here most recently I'd like to have his opinion. > > I don't know enough about cifs but this call in fs/cifs/connect.c > > 2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); > > will always result in a null pointer derefence as CIFSTCon uses the > cifs_tcon struct for passwords without verification Yes, I too was hovering around this code path today and it doesn't look correct. Specifically, the call from cifs_dfs_path to CIFSTCon with cifs_tcon as NULL seems wrong. I tried to do dig history a bit with `git blame`, but couldn't figure out the commit that introduced this. -- Suresh Jayaraman ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-10 12:14 ` Suresh Jayaraman @ 2011-06-10 12:49 ` Connor Hansen 2011-06-11 11:41 ` Jeff Layton 0 siblings, 1 reply; 18+ messages in thread From: Connor Hansen @ 2011-06-10 12:49 UTC (permalink / raw) To: Suresh Jayaraman Cc: Jeff Layton, Martijn Uffing, linux-cifs, linux-kernel, sean finney On Fri, Jun 10, 2011 at 5:14 AM, Suresh Jayaraman <sjayaraman@suse.de> wrote: > On 06/10/2011 05:33 PM, Connor Hansen wrote: >> On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <jlayton@redhat.com> wrote: >>> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST) >>> Uffing <mp3project@sarijopen.student.utwente.nl> wrote: >>> >>>> >>>> <snip> >>>>> call in get_dfs_path() >>>>> rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); >>>>> >>>>> function header for CIFSTCon >>>>> int CIFSTCon(unsigned int xid, struct cifs_ses *ses, >>>>> const char *tree, struct cifs_tcon *tcon, >>>>> const struct nls_table *nls_codepage) >>>>> >>>>> get_dfs_path() is passing struct cifs_tcon *tcon as NULL >>>>> >>>>> from config: CONFIG_CIFS_WEAK_PW_HASH=y >>>>> >>>>> in CIFSTCon >>>>> >>>>> #ifdef CONFIG_CIFS_WEAK_PW_HASH >>>>> 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && >>>>> 3223 (ses->server->secType == LANMAN)) >>>>> 3224 calc_lanman_hash(tcon->password, >>>>> ses->server->cryptkey, >>>>> >>>>> in calc_lanman_hash tcon is dereferenced(tcon->password) without being >>>>> checked if null >>>>> >>>>> 3225 ses->server->sec_mode & >>>>> 3226 SECMODE_PW_ENCRYPT ? >>>>> true : false, >>>>> 3227 bcc_ptr); >>>>> 3228 else >>>>> 3229 #endif /* CIFS_WEAK_PW_HASH */ >>>>> >>>>> Connor >>>> >>>> >>>> Ave all >>>> >>>> I recompiled kernel 3.0-rc1 (hadn't enabled CONFIG_DEBUG_INFO=y) and put >>>> the oops (with the new adresses) through gdb per instruction of Jeff. And >>>> Connor was spot on! >>>> >>>> <qoute oops> >>>> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 >>>> IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] >>>> </qoute oops> >>>> >>>> <qoute gdb> >>>> This GDB was configured as "x86_64-linux-gnu". >>>> For bug reporting instructions, please see: >>>> <http://www.gnu.org/software/gdb/bugs/>... >>>> Reading symbols from >>>> /lib/modules/3.0.0-rc1-debug/kernel/fs/cifs/cifs.ko...done. >>>> (gdb) list *(CIFSTCon+0xf6) >>>> 0xc2b6 is in CIFSTCon (fs/cifs/connect.c:3230). >>>> 3225 ses->server->sec_mode & >>>> 3226 SECMODE_PW_ENCRYPT ? >>>> true : false, >>>> 3227 bcc_ptr); >>>> 3228 else >>>> 3229 #endif /* CIFS_WEAK_PW_HASH */ >>>> 3230 rc = SMBNTencrypt(tcon->password, >>>> ses->server->cryptkey, >>>> 3231 bcc_ptr); >>>> 3232 >>>> 3233 bcc_ptr += CIFS_AUTH_RESP_SIZE; >>>> 3234 if (ses->capabilities & CAP_UNICODE) { >>>> (gdb) >>>> </qoute gdb> >>>> >>> >>> (cc'ing Sean F. since I suspect this regression is due to his changes) >>> >>> Thanks for the analysis, Martijn and Connor... >>> >>> What sort of server are you mounting here? It looks like it's using >>> share-level security, so it's either very old or is a samba server >>> configured that way. >>> >>> I suspect that commit c1508ca236 is the culprit. With that, we call >>> into expand_dfs_referral on every mount attempt. Previously we only >>> called into there when we got back an EREMOTE error and that would >>> have been unlikely on a share-level security connection. >>> >>> I think there are several possible solutions, but since Sean was in >>> here most recently I'd like to have his opinion. >> >> I don't know enough about cifs but this call in fs/cifs/connect.c >> >> 2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); >> >> will always result in a null pointer derefence as CIFSTCon uses the >> cifs_tcon struct for passwords without verification > > Yes, I too was hovering around this code path today and it doesn't look > correct. Specifically, the call from cifs_dfs_path to CIFSTCon with > cifs_tcon as NULL seems wrong. I tried to do dig history a bit with `git > blame`, but couldn't figure out the commit that introduced this. > > > -- > Suresh Jayaraman > git annotate fs/cifs/connect.c 1da177e4 (Linus Torvalds 2005-04-16 15:20:36 -0700 2268) rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); this was valid at the time to simply get the rc, and the code was checked if ((rc == 0) && (tcon != NULL)) { // first use of tcon in CIFSTCon back then..... after a loooooong look, i found the patch which changed it 00e485b0 commit 00e485b0198ea4f509341373f1d9adb0a5977a2f Author: Jeff Layton <jlayton@redhat.com> Date: Fri Dec 5 20:41:21 2008 -0500 cifs: store password in tcon cifs: store password in tcon Each tcon has its own password for share-level security. Store it in the tcon and wipe it clean and free it when freeing the tcon. When doing the tree connect with share-level security, use the tcon password instead of the session password. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com> ........................ - (ses->server->secType == LANMAN)) - calc_lanman_hash(ses->password, ses->server->cryptKey, + (ses->server->secType == LANMAN)) + calc_lanman_hash(tcon->password, ses->server->cryptKey, ......................... - SMBNTencrypt(ses->password, - ses->server->cryptKey, + SMBNTencrypt(tcon->password, ses->server->cryptKey, So can probably just grab the tcon from the session in get_dfs_path and pass it instead of the null Connor ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-10 12:49 ` Connor Hansen @ 2011-06-11 11:41 ` Jeff Layton 2011-06-11 16:25 ` Connor Hansen 2011-06-11 22:31 ` Martijn Uffing 0 siblings, 2 replies; 18+ messages in thread From: Jeff Layton @ 2011-06-11 11:41 UTC (permalink / raw) To: Connor Hansen Cc: Suresh Jayaraman, Martijn Uffing, linux-cifs, linux-kernel, sean finney On Fri, 10 Jun 2011 05:49:46 -0700 Connor Hansen <cmdkhh@gmail.com> wrote: > On Fri, Jun 10, 2011 at 5:14 AM, Suresh Jayaraman <sjayaraman@suse.de> wrote: > > On 06/10/2011 05:33 PM, Connor Hansen wrote: > >> On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <jlayton@redhat.com> wrote: > >>> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST) > >>> Uffing <mp3project@sarijopen.student.utwente.nl> wrote: > >>> > >>>> > >>>> <snip> > >>>>> call in get_dfs_path() > >>>>> rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); > >>>>> > >>>>> function header for CIFSTCon > >>>>> int CIFSTCon(unsigned int xid, struct cifs_ses *ses, > >>>>> const char *tree, struct cifs_tcon *tcon, > >>>>> const struct nls_table *nls_codepage) > >>>>> > >>>>> get_dfs_path() is passing struct cifs_tcon *tcon as NULL > >>>>> > >>>>> from config: CONFIG_CIFS_WEAK_PW_HASH=y > >>>>> > >>>>> in CIFSTCon > >>>>> > >>>>> #ifdef CONFIG_CIFS_WEAK_PW_HASH > >>>>> 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && > >>>>> 3223 (ses->server->secType == LANMAN)) > >>>>> 3224 calc_lanman_hash(tcon->password, > >>>>> ses->server->cryptkey, > >>>>> > >>>>> in calc_lanman_hash tcon is dereferenced(tcon->password) without being > >>>>> checked if null > >>>>> > >>>>> 3225 ses->server->sec_mode & > >>>>> 3226 SECMODE_PW_ENCRYPT ? > >>>>> true : false, > >>>>> 3227 bcc_ptr); > >>>>> 3228 else > >>>>> 3229 #endif /* CIFS_WEAK_PW_HASH */ > >>>>> > >>>>> Connor > >>>> > >>>> > >>>> Ave all > >>>> > >>>> I recompiled kernel 3.0-rc1 (hadn't enabled CONFIG_DEBUG_INFO=y) and put > >>>> the oops (with the new adresses) through gdb per instruction of Jeff. And > >>>> Connor was spot on! > >>>> > >>>> <qoute oops> > >>>> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 > >>>> IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] > >>>> </qoute oops> > >>>> > >>>> <qoute gdb> > >>>> This GDB was configured as "x86_64-linux-gnu". > >>>> For bug reporting instructions, please see: > >>>> <http://www.gnu.org/software/gdb/bugs/>... > >>>> Reading symbols from > >>>> /lib/modules/3.0.0-rc1-debug/kernel/fs/cifs/cifs.ko...done. > >>>> (gdb) list *(CIFSTCon+0xf6) > >>>> 0xc2b6 is in CIFSTCon (fs/cifs/connect.c:3230). > >>>> 3225 ses->server->sec_mode & > >>>> 3226 SECMODE_PW_ENCRYPT ? > >>>> true : false, > >>>> 3227 bcc_ptr); > >>>> 3228 else > >>>> 3229 #endif /* CIFS_WEAK_PW_HASH */ > >>>> 3230 rc = SMBNTencrypt(tcon->password, > >>>> ses->server->cryptkey, > >>>> 3231 bcc_ptr); > >>>> 3232 > >>>> 3233 bcc_ptr += CIFS_AUTH_RESP_SIZE; > >>>> 3234 if (ses->capabilities & CAP_UNICODE) { > >>>> (gdb) > >>>> </qoute gdb> > >>>> > >>> > >>> (cc'ing Sean F. since I suspect this regression is due to his changes) > >>> > >>> Thanks for the analysis, Martijn and Connor... > >>> > >>> What sort of server are you mounting here? It looks like it's using > >>> share-level security, so it's either very old or is a samba server > >>> configured that way. > >>> > >>> I suspect that commit c1508ca236 is the culprit. With that, we call > >>> into expand_dfs_referral on every mount attempt. Previously we only > >>> called into there when we got back an EREMOTE error and that would > >>> have been unlikely on a share-level security connection. > >>> > >>> I think there are several possible solutions, but since Sean was in > >>> here most recently I'd like to have his opinion. > >> > >> I don't know enough about cifs but this call in fs/cifs/connect.c > >> > >> 2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); > >> > >> will always result in a null pointer derefence as CIFSTCon uses the > >> cifs_tcon struct for passwords without verification > > > > Yes, I too was hovering around this code path today and it doesn't look > > correct. Specifically, the call from cifs_dfs_path to CIFSTCon with > > cifs_tcon as NULL seems wrong. I tried to do dig history a bit with `git > > blame`, but couldn't figure out the commit that introduced this. > > > > > > -- > > Suresh Jayaraman > > > > git annotate fs/cifs/connect.c > 1da177e4 (Linus Torvalds 2005-04-16 15:20:36 -0700 2268) > rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); > > this was valid at the time to simply get the rc, and the code was checked > if ((rc == 0) && (tcon != NULL)) { // first use of tcon in > CIFSTCon back then..... > > > after a loooooong look, i found the patch which changed it > > 00e485b0 > commit 00e485b0198ea4f509341373f1d9adb0a5977a2f > Author: Jeff Layton <jlayton@redhat.com> > Date: Fri Dec 5 20:41:21 2008 -0500 > > cifs: store password in tcon > > cifs: store password in tcon > > Each tcon has its own password for share-level security. Store it in > the tcon and wipe it clean and free it when freeing the tcon. When > doing the tree connect with share-level security, use the tcon password > instead of the session password. > > Signed-off-by: Jeff Layton <jlayton@redhat.com> > Signed-off-by: Steve French <sfrench@us.ibm.com> > Yep, mea culpa. This patch should fix it. Martin, can you test it? Anyone else have comments? Thanks... -----------------------[snip]-------------------- [PATCH] cifs: correctly handle NULL tcon pointer in CIFSTCon Long ago (in commit 00e485b0), I added some code to handle share-level passwords in CIFSTCon. That code ignored the fact that it's legit to pass in a NULL tcon pointer when connecting to the IPC$ share on the server. This wasn't really a problem until recently as we only called CIFSTCon this way when the server returned -EREMOTE. With the introduction of commit c1508ca2 however, it gets called this way on every mount, causing an oops when share-level security is in effect. Fix this by simply treating a NULL tcon pointer as if user-level security were in effect. I'm not aware of any servers that protect the IPC$ share with a specific password anyway. Also, add a comment to the top of CIFSTCon to ensure that we don't make the same mistake again. Reported-by: Martijn Uffing <mp3project@sarijopen.student.utwente.nl> Signed-off-by: Jeff Layton <jlayton@redhat.com> --- fs/cifs/connect.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index 7b6cad2..fa5a5d7 100644 --- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -3174,6 +3174,10 @@ out: return rc; } +/* + * Issue a TREE_CONNECT request. Note that for IPC$ shares, that the tcon + * pointer may be NULL. + */ int CIFSTCon(unsigned int xid, struct cifs_ses *ses, const char *tree, struct cifs_tcon *tcon, @@ -3208,7 +3212,7 @@ CIFSTCon(unsigned int xid, struct cifs_ses *ses, pSMB->AndXCommand = 0xFF; pSMB->Flags = cpu_to_le16(TCON_EXTENDED_SECINFO); bcc_ptr = &pSMB->Password[0]; - if ((ses->server->sec_mode) & SECMODE_USER) { + if (!tcon || (ses->server->sec_mode & SECMODE_USER)) { pSMB->PasswordLength = cpu_to_le16(1); /* minimum */ *bcc_ptr = 0; /* password is null byte */ bcc_ptr++; /* skip password */ -- 1.7.5.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-11 11:41 ` Jeff Layton @ 2011-06-11 16:25 ` Connor Hansen 2011-06-11 22:31 ` Martijn Uffing 1 sibling, 0 replies; 18+ messages in thread From: Connor Hansen @ 2011-06-11 16:25 UTC (permalink / raw) To: Jeff Layton Cc: Suresh Jayaraman, Martijn Uffing, linux-cifs, linux-kernel, sean finney On Sat, Jun 11, 2011 at 4:41 AM, Jeff Layton <jlayton@redhat.com> wrote: > On Fri, 10 Jun 2011 05:49:46 -0700 > Connor Hansen <cmdkhh@gmail.com> wrote: > >> On Fri, Jun 10, 2011 at 5:14 AM, Suresh Jayaraman <sjayaraman@suse.de> wrote: >> > On 06/10/2011 05:33 PM, Connor Hansen wrote: >> >> On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <jlayton@redhat.com> wrote: >> >>> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST) >> >>> Uffing <mp3project@sarijopen.student.utwente.nl> wrote: >> >>> >> >>>> >> >>>> <snip> >> >>>>> call in get_dfs_path() >> >>>>> rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); >> >>>>> >> >>>>> function header for CIFSTCon >> >>>>> int CIFSTCon(unsigned int xid, struct cifs_ses *ses, >> >>>>> const char *tree, struct cifs_tcon *tcon, >> >>>>> const struct nls_table *nls_codepage) >> >>>>> >> >>>>> get_dfs_path() is passing struct cifs_tcon *tcon as NULL >> >>>>> >> >>>>> from config: CONFIG_CIFS_WEAK_PW_HASH=y >> >>>>> >> >>>>> in CIFSTCon >> >>>>> >> >>>>> #ifdef CONFIG_CIFS_WEAK_PW_HASH >> >>>>> 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && >> >>>>> 3223 (ses->server->secType == LANMAN)) >> >>>>> 3224 calc_lanman_hash(tcon->password, >> >>>>> ses->server->cryptkey, >> >>>>> >> >>>>> in calc_lanman_hash tcon is dereferenced(tcon->password) without being >> >>>>> checked if null >> >>>>> >> >>>>> 3225 ses->server->sec_mode & >> >>>>> 3226 SECMODE_PW_ENCRYPT ? >> >>>>> true : false, >> >>>>> 3227 bcc_ptr); >> >>>>> 3228 else >> >>>>> 3229 #endif /* CIFS_WEAK_PW_HASH */ >> >>>>> >> >>>>> Connor >> >>>> >> >>>> >> >>>> Ave all >> >>>> >> >>>> I recompiled kernel 3.0-rc1 (hadn't enabled CONFIG_DEBUG_INFO=y) and put >> >>>> the oops (with the new adresses) through gdb per instruction of Jeff. And >> >>>> Connor was spot on! >> >>>> >> >>>> <qoute oops> >> >>>> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 >> >>>> IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] >> >>>> </qoute oops> >> >>>> >> >>>> <qoute gdb> >> >>>> This GDB was configured as "x86_64-linux-gnu". >> >>>> For bug reporting instructions, please see: >> >>>> <http://www.gnu.org/software/gdb/bugs/>... >> >>>> Reading symbols from >> >>>> /lib/modules/3.0.0-rc1-debug/kernel/fs/cifs/cifs.ko...done. >> >>>> (gdb) list *(CIFSTCon+0xf6) >> >>>> 0xc2b6 is in CIFSTCon (fs/cifs/connect.c:3230). >> >>>> 3225 ses->server->sec_mode & >> >>>> 3226 SECMODE_PW_ENCRYPT ? >> >>>> true : false, >> >>>> 3227 bcc_ptr); >> >>>> 3228 else >> >>>> 3229 #endif /* CIFS_WEAK_PW_HASH */ >> >>>> 3230 rc = SMBNTencrypt(tcon->password, >> >>>> ses->server->cryptkey, >> >>>> 3231 bcc_ptr); >> >>>> 3232 >> >>>> 3233 bcc_ptr += CIFS_AUTH_RESP_SIZE; >> >>>> 3234 if (ses->capabilities & CAP_UNICODE) { >> >>>> (gdb) >> >>>> </qoute gdb> >> >>>> >> >>> >> >>> (cc'ing Sean F. since I suspect this regression is due to his changes) >> >>> >> >>> Thanks for the analysis, Martijn and Connor... >> >>> >> >>> What sort of server are you mounting here? It looks like it's using >> >>> share-level security, so it's either very old or is a samba server >> >>> configured that way. >> >>> >> >>> I suspect that commit c1508ca236 is the culprit. With that, we call >> >>> into expand_dfs_referral on every mount attempt. Previously we only >> >>> called into there when we got back an EREMOTE error and that would >> >>> have been unlikely on a share-level security connection. >> >>> >> >>> I think there are several possible solutions, but since Sean was in >> >>> here most recently I'd like to have his opinion. >> >> >> >> I don't know enough about cifs but this call in fs/cifs/connect.c >> >> >> >> 2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); >> >> >> >> will always result in a null pointer derefence as CIFSTCon uses the >> >> cifs_tcon struct for passwords without verification >> > >> > Yes, I too was hovering around this code path today and it doesn't look >> > correct. Specifically, the call from cifs_dfs_path to CIFSTCon with >> > cifs_tcon as NULL seems wrong. I tried to do dig history a bit with `git >> > blame`, but couldn't figure out the commit that introduced this. >> > >> > >> > -- >> > Suresh Jayaraman >> > >> >> git annotate fs/cifs/connect.c >> 1da177e4 (Linus Torvalds 2005-04-16 15:20:36 -0700 2268) >> rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); >> >> this was valid at the time to simply get the rc, and the code was checked >> if ((rc == 0) && (tcon != NULL)) { // first use of tcon in >> CIFSTCon back then..... >> >> >> after a loooooong look, i found the patch which changed it >> >> 00e485b0 >> commit 00e485b0198ea4f509341373f1d9adb0a5977a2f >> Author: Jeff Layton <jlayton@redhat.com> >> Date: Fri Dec 5 20:41:21 2008 -0500 >> >> cifs: store password in tcon >> >> cifs: store password in tcon >> >> Each tcon has its own password for share-level security. Store it in >> the tcon and wipe it clean and free it when freeing the tcon. When >> doing the tree connect with share-level security, use the tcon password >> instead of the session password. >> >> Signed-off-by: Jeff Layton <jlayton@redhat.com> >> Signed-off-by: Steve French <sfrench@us.ibm.com> >> > > Yep, mea culpa. This patch should fix it. Martin, can you test it? > Anyone else have comments? > > Thanks... Looks good to me, Connor > > -----------------------[snip]-------------------- > > [PATCH] cifs: correctly handle NULL tcon pointer in CIFSTCon > > Long ago (in commit 00e485b0), I added some code to handle share-level > passwords in CIFSTCon. That code ignored the fact that it's legit to > pass in a NULL tcon pointer when connecting to the IPC$ share on the > server. > > This wasn't really a problem until recently as we only called CIFSTCon > this way when the server returned -EREMOTE. With the introduction of > commit c1508ca2 however, it gets called this way on every mount, causing > an oops when share-level security is in effect. > > Fix this by simply treating a NULL tcon pointer as if user-level > security were in effect. I'm not aware of any servers that protect the > IPC$ share with a specific password anyway. Also, add a comment to the > top of CIFSTCon to ensure that we don't make the same mistake again. > > Reported-by: Martijn Uffing <mp3project@sarijopen.student.utwente.nl> > Signed-off-by: Jeff Layton <jlayton@redhat.com> > --- > fs/cifs/connect.c | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c > index 7b6cad2..fa5a5d7 100644 > --- a/fs/cifs/connect.c > +++ b/fs/cifs/connect.c > @@ -3174,6 +3174,10 @@ out: > return rc; > } > > +/* > + * Issue a TREE_CONNECT request. Note that for IPC$ shares, that the tcon > + * pointer may be NULL. > + */ > int > CIFSTCon(unsigned int xid, struct cifs_ses *ses, > const char *tree, struct cifs_tcon *tcon, > @@ -3208,7 +3212,7 @@ CIFSTCon(unsigned int xid, struct cifs_ses *ses, > pSMB->AndXCommand = 0xFF; > pSMB->Flags = cpu_to_le16(TCON_EXTENDED_SECINFO); > bcc_ptr = &pSMB->Password[0]; > - if ((ses->server->sec_mode) & SECMODE_USER) { > + if (!tcon || (ses->server->sec_mode & SECMODE_USER)) { > pSMB->PasswordLength = cpu_to_le16(1); /* minimum */ > *bcc_ptr = 0; /* password is null byte */ > bcc_ptr++; /* skip password */ > -- > 1.7.5.2 > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-11 11:41 ` Jeff Layton 2011-06-11 16:25 ` Connor Hansen @ 2011-06-11 22:31 ` Martijn Uffing 2011-06-12 1:17 ` Jeff Layton 2011-06-13 15:48 ` Jeff Layton 1 sibling, 2 replies; 18+ messages in thread From: Martijn Uffing @ 2011-06-11 22:31 UTC (permalink / raw) To: Jeff Layton Cc: Connor Hansen, Suresh Jayaraman, linux-cifs, linux-kernel, sean finney <snip> > > Yep, mea culpa. This patch should fix it. Martin, can you test it? > Anyone else have comments? > > Thanks... Unfortunately, I have to quote Britney: "Oops! I did it again" Well, not entirely true, the OOPS changed into a BUG, but my samba mount still doesn't work. The OOPS to BUG has a interesting diff. Don't know if it really matters, but some more info about my samba setup. Never such a thing as to much info. Note, the SAMBA hostname and DNS hostname of the server are NOT the same. ######## <samba setup> ############# SERVER: -DNS_hostname : sarijopen.student.utwente.nl -SAMBA_hostname : duckman-tm -ipv4 only : testparm -v|grep wins : name resolve order = lmhosts wins host bcast max wins ttl = 518400 min wins ttl = 21600 wins proxy = No wins server = 130.89.4.21, 130.89.4.22 wins support = No wins hook = No Domain Controller or anything. This a student LAN of circa 1000 computers where you can set your SAMBA hostname and workgroup to anything you like. Browse masters of ad hoc workgroups are decided by elections. Only the WINS servers are provided as a service of the IT department. I dont have very deep knowledge of samba, but when I read some specs, my first thought was "this stuff is NOT designed for the way we use it". However, it works. (Well, with a s*#%load of legitimate samba broadcast traffic) CLIENT: -DNS_hostname = xxxx.student.utwente.nl -SAMBA_hostname = xxxx -ipv4/ipv6 dual stack -fstab: //sarijopen.student.utwente.nl/sysadmin /home/XXXX/docs_sysadmin cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0 0 ######### </samba setup> ######### diff -up OOPS BUG CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 -BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 -IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] -PGD 127393067 PUD 129c80067 PMD 0 -Oops: 0000 [#1] SMP +CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: sarijopen.student.utwente.nl +CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of \\sarijopen.student.utwente.nl\sysadmin to IP: -2 +------------[ cut here ]------------ +kernel BUG at mm/slab.c:501! +invalid opcode: 0000 [#1] SMP BUG: Registering the dns_resolver key type CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: sarijopen.student.utwente.nl CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of \\sarijopen.student.utwente.nl\sysadmin to IP: -2 ------------[ cut here ]------------ kernel BUG at mm/slab.c:501! invalid opcode: 0000 [#1] SMP CPU 0 Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 usbhid sr_mod cdrom hid evdev pata_marvell sky2 skge snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm tpm_tis snd_seq_midi snd_rawmidi tpm snd_seq_midi_event pcspkr tpm_bios snd_seq uhci_hcd snd_timer snd_seq_device snd i2c_i801 i2c_core ehci_hcd intel_agp intel_gtt soundcore snd_page_alloc Pid: 2085, comm: mount.cifs Not tainted 3.0.0-rc1-debug-patched #1 System manufacturer P5Q-E/P5Q-E RIP: 0010:[<ffffffff810d19f4>] [<ffffffff810d19f4>] kfree+0x134/0x170 RSP: 0018:ffff880129251cc8 EFLAGS: 00010046 RAX: ffffea000070f420 RBX: ffff8801287e2e00 RCX: ffff88012f3c8800 RDX: 4000000000000000 RSI: 00000000000000d0 RDI: ffffffffa045cebb RBP: ffff880129251d18 R08: b018000000000000 R09: 000000000000000a R10: 0000000000000006 R11: dead000000200200 R12: ffffffffa045cebb R13: 0000000000000282 R14: ffff88012a903400 R15: ffff88012a903800 FS: 00007f6d20b9f700(0000) GS:ffff88012fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fb9903dfc58 CR3: 0000000128b43000 CR4: 00000000000406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process mount.cifs (pid: 2085, threadinfo ffff880129250000, task ffff88012aba6100) Stack: ffff880129251c5c ffffffff810ec545 ffff88012f3c8800 ffff88010f876d10 ffff88012f3c8800 ffff8801287e2e00 ffff880129251d80 ffff88010f876d10 ffff88012a903400 ffff88012a903800 ffff880129251d38 ffffffffa043d19f Call Trace: [<ffffffff810ec545>] ? __d_instantiate+0x85/0xf0 [<ffffffffa043d19f>] cifs_cleanup_volume_info+0x1f/0x70 [cifs] [<ffffffffa043123b>] cifs_do_mount+0x11b/0x3b0 [cifs] [<ffffffff810db35b>] mount_fs+0x1b/0xd0 [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0 [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110 [<ffffffff810f732b>] do_mount+0x2cb/0x7d0 [<ffffffff810f78c3>] sys_mount+0x93/0xe0 [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b Code: c8 44 01 09 4c 8b 45 c0 41 fe 46 40 8b 13 4b 8d 34 38 29 c2 4c 89 c7 89 13 89 d2 48 c1 e2 03 e8 53 d2 0c 00 8b 03 e9 47 ff ff ff <0f> 0b eb fe 48 8b 40 10 e9 16 ff ff ff 4c 8d 43 18 89 c2 4c 89 RIP [<ffffffff810d19f4>] kfree+0x134/0x170 RSP <ffff880129251cc8> ---[ end trace cffbbd6be8c5a0f3 ]--- So, we're from OOPS to BUG. I tried gdb, but it won't decode the kfree+0x134 into something, which I could with the real OOPS. Some pointers how I can help with gdb? http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses mentions only OOPS, no BUG. Greetz Martijn (BTW, I will mostly be of the net a couple of days, so my reply's can take a while) > > -----------------------[snip]-------------------- > > [PATCH] cifs: correctly handle NULL tcon pointer in CIFSTCon > > Long ago (in commit 00e485b0), I added some code to handle share-level > passwords in CIFSTCon. That code ignored the fact that it's legit to > pass in a NULL tcon pointer when connecting to the IPC$ share on the > server. > > This wasn't really a problem until recently as we only called CIFSTCon > this way when the server returned -EREMOTE. With the introduction of > commit c1508ca2 however, it gets called this way on every mount, causing > an oops when share-level security is in effect. > > Fix this by simply treating a NULL tcon pointer as if user-level > security were in effect. I'm not aware of any servers that protect the > IPC$ share with a specific password anyway. Also, add a comment to the > top of CIFSTCon to ensure that we don't make the same mistake again. > > Reported-by: Martijn Uffing <mp3project@sarijopen.student.utwente.nl> > Signed-off-by: Jeff Layton <jlayton@redhat.com> > --- > fs/cifs/connect.c | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c > index 7b6cad2..fa5a5d7 100644 > --- a/fs/cifs/connect.c > +++ b/fs/cifs/connect.c > @@ -3174,6 +3174,10 @@ out: > return rc; > } > > +/* > + * Issue a TREE_CONNECT request. Note that for IPC$ shares, that the tcon > + * pointer may be NULL. > + */ > int > CIFSTCon(unsigned int xid, struct cifs_ses *ses, > const char *tree, struct cifs_tcon *tcon, > @@ -3208,7 +3212,7 @@ CIFSTCon(unsigned int xid, struct cifs_ses *ses, > pSMB->AndXCommand = 0xFF; > pSMB->Flags = cpu_to_le16(TCON_EXTENDED_SECINFO); > bcc_ptr = &pSMB->Password[0]; > - if ((ses->server->sec_mode) & SECMODE_USER) { > + if (!tcon || (ses->server->sec_mode & SECMODE_USER)) { > pSMB->PasswordLength = cpu_to_le16(1); /* minimum */ > *bcc_ptr = 0; /* password is null byte */ > bcc_ptr++; /* skip password */ > -- > 1.7.5.2 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-11 22:31 ` Martijn Uffing @ 2011-06-12 1:17 ` Jeff Layton 2011-06-13 15:48 ` Jeff Layton 1 sibling, 0 replies; 18+ messages in thread From: Jeff Layton @ 2011-06-12 1:17 UTC (permalink / raw) To: Martijn Uffing Cc: Connor Hansen, Suresh Jayaraman, linux-cifs, linux-kernel, sean finney On Sun, 12 Jun 2011 00:31:47 +0200 (CEST) Martijn Uffing <mp3project@sarijopen.student.utwente.nl> wrote: > > > > <snip> > > > > Yep, mea culpa. This patch should fix it. Martin, can you test it? > > Anyone else have comments? > > > > Thanks... > > > Unfortunately, I have to quote Britney: "Oops! I did it again" > Well, not entirely true, the OOPS changed into a BUG, but my samba mount > still doesn't work. > > The OOPS to BUG has a interesting diff. Don't know if it really matters, > but some more info about my samba setup. Never such a thing as to much > info. Note, the SAMBA hostname and DNS hostname of the server are > NOT the same. > > > ######## <samba setup> ############# > SERVER: > -DNS_hostname : sarijopen.student.utwente.nl > -SAMBA_hostname : duckman-tm > -ipv4 only : > testparm -v|grep wins : > name resolve order = lmhosts wins host bcast > max wins ttl = 518400 > min wins ttl = 21600 > wins proxy = No > wins server = 130.89.4.21, 130.89.4.22 > wins support = No > wins hook = > No Domain Controller or anything. This a student LAN of circa 1000 > computers where you can set your SAMBA hostname and workgroup to anything you like. Browse masters > of ad hoc workgroups are decided by elections. Only the WINS servers are > provided as a service of the IT department. I dont have very deep > knowledge of samba, but when I read some specs, my first thought was "this stuff is NOT designed for the way we use it". > However, it works. (Well, with a s*#%load of legitimate samba broadcast > traffic) > > CLIENT: > -DNS_hostname = xxxx.student.utwente.nl > -SAMBA_hostname = xxxx > -ipv4/ipv6 dual stack > -fstab: //sarijopen.student.utwente.nl/sysadmin /home/XXXX/docs_sysadmin > cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0 > 0 > ######### </samba setup> ######### > > > > diff -up OOPS BUG > > CIFS VFS: default security mechanism requested. The default security > mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 > -BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 > -IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] > -PGD 127393067 PUD 129c80067 PMD 0 > -Oops: 0000 [#1] SMP > +CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: > sarijopen.student.utwente.nl > +CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of > \\sarijopen.student.utwente.nl\sysadmin to IP: -2 > +------------[ cut here ]------------ > +kernel BUG at mm/slab.c:501! > +invalid opcode: 0000 [#1] SMP > > BUG: > > Registering the dns_resolver key type > CIFS VFS: default security mechanism requested. The default security > mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 > CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: > sarijopen.student.utwente.nl > CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of > \\sarijopen.student.utwente.nl\sysadmin to IP: -2 > ------------[ cut here ]------------ > kernel BUG at mm/slab.c:501! > invalid opcode: 0000 [#1] SMP > CPU 0 > Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver > nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm > i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 usbhid > sr_mod cdrom hid evdev pata_marvell sky2 skge snd_hda_codec_hdmi > snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm tpm_tis > snd_seq_midi snd_rawmidi tpm snd_seq_midi_event pcspkr tpm_bios snd_seq > uhci_hcd snd_timer snd_seq_device snd i2c_i801 i2c_core ehci_hcd intel_agp > intel_gtt soundcore snd_page_alloc > > Pid: 2085, comm: mount.cifs Not tainted 3.0.0-rc1-debug-patched #1 System > manufacturer P5Q-E/P5Q-E > RIP: 0010:[<ffffffff810d19f4>] [<ffffffff810d19f4>] kfree+0x134/0x170 > RSP: 0018:ffff880129251cc8 EFLAGS: 00010046 > RAX: ffffea000070f420 RBX: ffff8801287e2e00 RCX: ffff88012f3c8800 > RDX: 4000000000000000 RSI: 00000000000000d0 RDI: ffffffffa045cebb > RBP: ffff880129251d18 R08: b018000000000000 R09: 000000000000000a > R10: 0000000000000006 R11: dead000000200200 R12: ffffffffa045cebb > R13: 0000000000000282 R14: ffff88012a903400 R15: ffff88012a903800 > FS: 00007f6d20b9f700(0000) GS:ffff88012fc00000(0000) > knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 00007fb9903dfc58 CR3: 0000000128b43000 CR4: 00000000000406f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process mount.cifs (pid: 2085, threadinfo ffff880129250000, task > ffff88012aba6100) > Stack: > ffff880129251c5c ffffffff810ec545 ffff88012f3c8800 ffff88010f876d10 > ffff88012f3c8800 ffff8801287e2e00 ffff880129251d80 ffff88010f876d10 > ffff88012a903400 ffff88012a903800 ffff880129251d38 ffffffffa043d19f > Call Trace: > [<ffffffff810ec545>] ? __d_instantiate+0x85/0xf0 > [<ffffffffa043d19f>] cifs_cleanup_volume_info+0x1f/0x70 [cifs] > [<ffffffffa043123b>] cifs_do_mount+0x11b/0x3b0 [cifs] > [<ffffffff810db35b>] mount_fs+0x1b/0xd0 > [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0 > [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110 > [<ffffffff810f732b>] do_mount+0x2cb/0x7d0 > [<ffffffff810f78c3>] sys_mount+0x93/0xe0 > [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b > Code: c8 44 01 09 4c 8b 45 c0 41 fe 46 40 8b 13 4b 8d 34 38 29 c2 4c 89 c7 > 89 13 89 d2 48 c1 e2 03 e8 53 d2 0c 00 8b 03 e9 47 ff ff ff <0f> 0b eb fe > 48 8b 40 10 e9 16 ff ff ff 4c 8d 43 18 89 c2 4c 89 > RIP [<ffffffff810d19f4>] kfree+0x134/0x170 > RSP <ffff880129251cc8> > ---[ end trace cffbbd6be8c5a0f3 ]--- > > > > So, we're from OOPS to BUG. I tried gdb, but it won't decode the > kfree+0x134 into something, which I could with the real OOPS. > Some pointers how I can help with gdb? > > http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses mentions > only OOPS, no BUG. > > Greetz Martijn > (BTW, I will mostly be of the net a couple of days, so my reply's can take > a while) > That panic doesn't look related to the one you originally reported. I think there was at least one double-kfree bug fixed in rc2, so you might want to try rebasing to that. FWIW, I set up a samba server doing share-level security and was able to reproduce your original oops. This patch seems to fix it, and I was able to successfully mount using a rc2 based kernel with that patch. Given that, I'll go ahead and send this up to Steve so that he can review it for 3.0. Thanks, -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-11 22:31 ` Martijn Uffing 2011-06-12 1:17 ` Jeff Layton @ 2011-06-13 15:48 ` Jeff Layton 2011-06-14 2:59 ` Pavel Shilovsky 2011-06-14 21:11 ` Martijn Uffing 1 sibling, 2 replies; 18+ messages in thread From: Jeff Layton @ 2011-06-13 15:48 UTC (permalink / raw) To: Martijn Uffing Cc: Connor Hansen, Suresh Jayaraman, linux-cifs, linux-kernel, sean finney, Pavel Shilovsky On Sun, 12 Jun 2011 00:31:47 +0200 (CEST) Martijn Uffing <mp3project@sarijopen.student.utwente.nl> wrote: > > > > <snip> > > > > Yep, mea culpa. This patch should fix it. Martin, can you test it? > > Anyone else have comments? > > > > Thanks... > > > Unfortunately, I have to quote Britney: "Oops! I did it again" > Well, not entirely true, the OOPS changed into a BUG, but my samba mount > still doesn't work. > > The OOPS to BUG has a interesting diff. Don't know if it really matters, > but some more info about my samba setup. Never such a thing as to much > info. Note, the SAMBA hostname and DNS hostname of the server are > NOT the same. > > > ######## <samba setup> ############# > SERVER: > -DNS_hostname : sarijopen.student.utwente.nl > -SAMBA_hostname : duckman-tm > -ipv4 only : > testparm -v|grep wins : > name resolve order = lmhosts wins host bcast > max wins ttl = 518400 > min wins ttl = 21600 > wins proxy = No > wins server = 130.89.4.21, 130.89.4.22 > wins support = No > wins hook = > No Domain Controller or anything. This a student LAN of circa 1000 > computers where you can set your SAMBA hostname and workgroup to anything you like. Browse masters > of ad hoc workgroups are decided by elections. Only the WINS servers are > provided as a service of the IT department. I dont have very deep > knowledge of samba, but when I read some specs, my first thought was "this stuff is NOT designed for the way we use it". > However, it works. (Well, with a s*#%load of legitimate samba broadcast > traffic) > > CLIENT: > -DNS_hostname = xxxx.student.utwente.nl > -SAMBA_hostname = xxxx > -ipv4/ipv6 dual stack > -fstab: //sarijopen.student.utwente.nl/sysadmin /home/XXXX/docs_sysadmin > cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0 > 0 > ######### </samba setup> ######### > > > > diff -up OOPS BUG > > CIFS VFS: default security mechanism requested. The default security > mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 > -BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 > -IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] > -PGD 127393067 PUD 129c80067 PMD 0 > -Oops: 0000 [#1] SMP > +CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: > sarijopen.student.utwente.nl > +CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of > \\sarijopen.student.utwente.nl\sysadmin to IP: -2 > +------------[ cut here ]------------ > +kernel BUG at mm/slab.c:501! > +invalid opcode: 0000 [#1] SMP > > BUG: > > Registering the dns_resolver key type > CIFS VFS: default security mechanism requested. The default security > mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 > CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: > sarijopen.student.utwente.nl > CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of > \\sarijopen.student.utwente.nl\sysadmin to IP: -2 > ------------[ cut here ]------------ > kernel BUG at mm/slab.c:501! > invalid opcode: 0000 [#1] SMP > CPU 0 > Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver > nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm > i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 usbhid > sr_mod cdrom hid evdev pata_marvell sky2 skge snd_hda_codec_hdmi > snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm tpm_tis > snd_seq_midi snd_rawmidi tpm snd_seq_midi_event pcspkr tpm_bios snd_seq > uhci_hcd snd_timer snd_seq_device snd i2c_i801 i2c_core ehci_hcd intel_agp > intel_gtt soundcore snd_page_alloc > > Pid: 2085, comm: mount.cifs Not tainted 3.0.0-rc1-debug-patched #1 System > manufacturer P5Q-E/P5Q-E > RIP: 0010:[<ffffffff810d19f4>] [<ffffffff810d19f4>] kfree+0x134/0x170 > RSP: 0018:ffff880129251cc8 EFLAGS: 00010046 > RAX: ffffea000070f420 RBX: ffff8801287e2e00 RCX: ffff88012f3c8800 > RDX: 4000000000000000 RSI: 00000000000000d0 RDI: ffffffffa045cebb > RBP: ffff880129251d18 R08: b018000000000000 R09: 000000000000000a > R10: 0000000000000006 R11: dead000000200200 R12: ffffffffa045cebb > R13: 0000000000000282 R14: ffff88012a903400 R15: ffff88012a903800 > FS: 00007f6d20b9f700(0000) GS:ffff88012fc00000(0000) > knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 00007fb9903dfc58 CR3: 0000000128b43000 CR4: 00000000000406f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process mount.cifs (pid: 2085, threadinfo ffff880129250000, task > ffff88012aba6100) > Stack: > ffff880129251c5c ffffffff810ec545 ffff88012f3c8800 ffff88010f876d10 > ffff88012f3c8800 ffff8801287e2e00 ffff880129251d80 ffff88010f876d10 > ffff88012a903400 ffff88012a903800 ffff880129251d38 ffffffffa043d19f > Call Trace: > [<ffffffff810ec545>] ? __d_instantiate+0x85/0xf0 > [<ffffffffa043d19f>] cifs_cleanup_volume_info+0x1f/0x70 [cifs] > [<ffffffffa043123b>] cifs_do_mount+0x11b/0x3b0 [cifs] > [<ffffffff810db35b>] mount_fs+0x1b/0xd0 > [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0 > [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110 > [<ffffffff810f732b>] do_mount+0x2cb/0x7d0 > [<ffffffff810f78c3>] sys_mount+0x93/0xe0 > [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b > Code: c8 44 01 09 4c 8b 45 c0 41 fe 46 40 8b 13 4b 8d 34 38 29 c2 4c 89 c7 > 89 13 89 d2 48 c1 e2 03 e8 53 d2 0c 00 8b 03 e9 47 ff ff ff <0f> 0b eb fe > 48 8b 40 10 e9 16 ff ff ff 4c 8d 43 18 89 c2 4c 89 > RIP [<ffffffff810d19f4>] kfree+0x134/0x170 > RSP <ffff880129251cc8> > ---[ end trace cffbbd6be8c5a0f3 ]--- > > > > So, we're from OOPS to BUG. I tried gdb, but it won't decode the > kfree+0x134 into something, which I could with the real OOPS. > Some pointers how I can help with gdb? > > http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses mentions > only OOPS, no BUG. > > Greetz Martijn > (BTW, I will mostly be of the net a couple of days, so my reply's can take > a while) > (cc'ing Pavel) Ok, I've been able to reproduce on -rc2 as well, simply by mounting with -o sec=none. Pavel, I'm pretty sure this got broken by commit 724d9f1cfb. That patch doesn't handle the "null user" case correctly. There are probably several different ways to fix it: [ 249.418776] ------------[ cut here ]------------ [ 249.419050] kernel BUG at mm/slub.c:2948! [ 249.419050] invalid opcode: 0000 [#1] SMP [ 249.419050] CPU 1 [ 249.419050] Modules linked in: des_generic md4 nls_utf8 cifs fscache sunrpc ipx p8022 psnap llc p8023 rose ax25 joydev i2c_piix4 i2c_core virtio_balloon virtio_net virtio_blk [last unloaded: cifs] [ 249.419050] [ 249.419050] Pid: 1058, comm: mount.cifs Not tainted 3.0-0.rc2.git0.2.fc16.x86_64 #1 Bochs Bochs [ 249.419050] RIP: 0010:[<ffffffff81126249>] [<ffffffff81126249>] kfree+0x60/0xfc [ 249.419050] RSP: 0018:ffff88003ba2bce8 EFLAGS: 00010246 [ 249.419050] RAX: 0020000000000000 RBX: ffffffffa013d46d RCX: ffff880034380930 [ 249.419050] RDX: 0020000000000000 RSI: ffff8800314a4ea0 RDI: ffffffffa013d46d [ 249.419050] RBP: ffff88003ba2bd08 R08: ffff88003e002500 R09: 000000000000005a [ 249.419050] R10: ffffffff82421ed0 R11: 00000000000003a7 R12: ffffea0000704558 [ 249.419050] R13: ffff88002f1a8050 R14: ffff88003140c2d0 R15: ffff88003a40d330 [ 249.419050] FS: 00007f89290dc740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 [ 249.419050] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 249.419050] CR2: 00007f804783a240 CR3: 000000003aea9000 CR4: 00000000000006e0 [ 249.419050] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 249.419050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 249.419050] Process mount.cifs (pid: 1058, threadinfo ffff88003ba2a000, task ffff8800314a47a0) [ 249.419050] Stack: [ 249.419050] ffff88003c312000 ffff88003ba2bd70 ffff88002f1a8050 ffff88003140c2d0 [ 249.419050] ffff88003ba2bd28 ffffffffa011e1a7 ffff88003ba1c240 ffff88003140c240 [ 249.419050] ffff88003ba2bda8 ffffffffa0112107 ffff88003ba2bd98 ffff880034380930 [ 249.419050] Call Trace: [ 249.419050] [<ffffffffa011e1a7>] cifs_cleanup_volume_info+0x24/0x72 [cifs] [ 249.419050] [<ffffffffa0112107>] cifs_do_mount+0x34e/0x364 [cifs] [ 249.419050] [<ffffffff8113a2dd>] mount_fs+0x69/0x158 [ 249.419050] [<ffffffff81103e6c>] ? __alloc_percpu+0x10/0x12 [ 249.419050] [<ffffffff8114f35e>] vfs_kern_mount+0x63/0xa0 [ 249.419050] [<ffffffff81150032>] do_kern_mount+0x4d/0xdf [ 249.419050] [<ffffffff811516c8>] do_mount+0x63c/0x69f [ 249.419050] [<ffffffff811519ac>] sys_mount+0x88/0xc2 [ 249.419050] [<ffffffff814fb002>] system_call_fastpath+0x16/0x1b [ 249.419050] Code: e9 ae 00 00 00 48 83 fb 10 0f 86 af 00 00 00 48 89 df e8 11 dd ff ff 49 89 c4 48 8b 00 a8 80 75 19 49 f7 04 24 00 c0 00 00 75 02 <0f> 0b 4c 89 e7 e8 78 e1 fc ff e9 84 00 00 00 4d 8b 6c 24 10 48 [ 249.419050] RIP [<ffffffff81126249>] kfree+0x60/0xfc [ 249.419050] RSP <ffff88003ba2bce8> [ 249.474238] ---[ end trace 48c6ff1e268f2f6a ]--- -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-13 15:48 ` Jeff Layton @ 2011-06-14 2:59 ` Pavel Shilovsky 2011-06-14 21:11 ` Martijn Uffing 1 sibling, 0 replies; 18+ messages in thread From: Pavel Shilovsky @ 2011-06-14 2:59 UTC (permalink / raw) To: Jeff Layton Cc: Martijn Uffing, Connor Hansen, Suresh Jayaraman, linux-cifs, linux-kernel, sean finney 2011/6/13 Jeff Layton <jlayton@redhat.com>: > On Sun, 12 Jun 2011 00:31:47 +0200 (CEST) > Martijn Uffing <mp3project@sarijopen.student.utwente.nl> wrote: > >> >> >> >> <snip> >> > >> > Yep, mea culpa. This patch should fix it. Martin, can you test it? >> > Anyone else have comments? >> > >> > Thanks... >> >> >> Unfortunately, I have to quote Britney: "Oops! I did it again" >> Well, not entirely true, the OOPS changed into a BUG, but my samba mount >> still doesn't work. >> >> The OOPS to BUG has a interesting diff. Don't know if it really matters, >> but some more info about my samba setup. Never such a thing as to much >> info. Note, the SAMBA hostname and DNS hostname of the server are >> NOT the same. >> >> >> ######## <samba setup> ############# >> SERVER: >> -DNS_hostname : sarijopen.student.utwente.nl >> -SAMBA_hostname : duckman-tm >> -ipv4 only : >> testparm -v|grep wins : >> name resolve order = lmhosts wins host bcast >> max wins ttl = 518400 >> min wins ttl = 21600 >> wins proxy = No >> wins server = 130.89.4.21, 130.89.4.22 >> wins support = No >> wins hook = >> No Domain Controller or anything. This a student LAN of circa 1000 >> computers where you can set your SAMBA hostname and workgroup to anything you like. Browse masters >> of ad hoc workgroups are decided by elections. Only the WINS servers are >> provided as a service of the IT department. I dont have very deep >> knowledge of samba, but when I read some specs, my first thought was "this stuff is NOT designed for the way we use it". >> However, it works. (Well, with a s*#%load of legitimate samba broadcast >> traffic) >> >> CLIENT: >> -DNS_hostname = xxxx.student.utwente.nl >> -SAMBA_hostname = xxxx >> -ipv4/ipv6 dual stack >> -fstab: //sarijopen.student.utwente.nl/sysadmin /home/XXXX/docs_sysadmin >> cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0 >> 0 >> ######### </samba setup> ######### >> >> >> >> diff -up OOPS BUG >> >> CIFS VFS: default security mechanism requested. The default security >> mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 >> -BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 >> -IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] >> -PGD 127393067 PUD 129c80067 PMD 0 >> -Oops: 0000 [#1] SMP >> +CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: >> sarijopen.student.utwente.nl >> +CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of >> \\sarijopen.student.utwente.nl\sysadmin to IP: -2 >> +------------[ cut here ]------------ >> +kernel BUG at mm/slab.c:501! >> +invalid opcode: 0000 [#1] SMP >> >> BUG: >> >> Registering the dns_resolver key type >> CIFS VFS: default security mechanism requested. The default security >> mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41 >> CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: >> sarijopen.student.utwente.nl >> CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of >> \\sarijopen.student.utwente.nl\sysadmin to IP: -2 >> ------------[ cut here ]------------ >> kernel BUG at mm/slab.c:501! >> invalid opcode: 0000 [#1] SMP >> CPU 0 >> Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver >> nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm >> i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 usbhid >> sr_mod cdrom hid evdev pata_marvell sky2 skge snd_hda_codec_hdmi >> snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm tpm_tis >> snd_seq_midi snd_rawmidi tpm snd_seq_midi_event pcspkr tpm_bios snd_seq >> uhci_hcd snd_timer snd_seq_device snd i2c_i801 i2c_core ehci_hcd intel_agp >> intel_gtt soundcore snd_page_alloc >> >> Pid: 2085, comm: mount.cifs Not tainted 3.0.0-rc1-debug-patched #1 System >> manufacturer P5Q-E/P5Q-E >> RIP: 0010:[<ffffffff810d19f4>] [<ffffffff810d19f4>] kfree+0x134/0x170 >> RSP: 0018:ffff880129251cc8 EFLAGS: 00010046 >> RAX: ffffea000070f420 RBX: ffff8801287e2e00 RCX: ffff88012f3c8800 >> RDX: 4000000000000000 RSI: 00000000000000d0 RDI: ffffffffa045cebb >> RBP: ffff880129251d18 R08: b018000000000000 R09: 000000000000000a >> R10: 0000000000000006 R11: dead000000200200 R12: ffffffffa045cebb >> R13: 0000000000000282 R14: ffff88012a903400 R15: ffff88012a903800 >> FS: 00007f6d20b9f700(0000) GS:ffff88012fc00000(0000) >> knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >> CR2: 00007fb9903dfc58 CR3: 0000000128b43000 CR4: 00000000000406f0 >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >> Process mount.cifs (pid: 2085, threadinfo ffff880129250000, task >> ffff88012aba6100) >> Stack: >> ffff880129251c5c ffffffff810ec545 ffff88012f3c8800 ffff88010f876d10 >> ffff88012f3c8800 ffff8801287e2e00 ffff880129251d80 ffff88010f876d10 >> ffff88012a903400 ffff88012a903800 ffff880129251d38 ffffffffa043d19f >> Call Trace: >> [<ffffffff810ec545>] ? __d_instantiate+0x85/0xf0 >> [<ffffffffa043d19f>] cifs_cleanup_volume_info+0x1f/0x70 [cifs] >> [<ffffffffa043123b>] cifs_do_mount+0x11b/0x3b0 [cifs] >> [<ffffffff810db35b>] mount_fs+0x1b/0xd0 >> [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0 >> [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110 >> [<ffffffff810f732b>] do_mount+0x2cb/0x7d0 >> [<ffffffff810f78c3>] sys_mount+0x93/0xe0 >> [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b >> Code: c8 44 01 09 4c 8b 45 c0 41 fe 46 40 8b 13 4b 8d 34 38 29 c2 4c 89 c7 >> 89 13 89 d2 48 c1 e2 03 e8 53 d2 0c 00 8b 03 e9 47 ff ff ff <0f> 0b eb fe >> 48 8b 40 10 e9 16 ff ff ff 4c 8d 43 18 89 c2 4c 89 >> RIP [<ffffffff810d19f4>] kfree+0x134/0x170 >> RSP <ffff880129251cc8> >> ---[ end trace cffbbd6be8c5a0f3 ]--- >> >> >> >> So, we're from OOPS to BUG. I tried gdb, but it won't decode the >> kfree+0x134 into something, which I could with the real OOPS. >> Some pointers how I can help with gdb? >> >> http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses mentions >> only OOPS, no BUG. >> >> Greetz Martijn >> (BTW, I will mostly be of the net a couple of days, so my reply's can take >> a while) >> > > (cc'ing Pavel) > > Ok, I've been able to reproduce on -rc2 as well, simply by mounting > with -o sec=none. Pavel, I'm pretty sure this got broken by commit > 724d9f1cfb. That patch doesn't handle the "null user" case correctly. > There are probably several different ways to fix it: > > > [ 249.418776] ------------[ cut here ]------------ > [ 249.419050] kernel BUG at mm/slub.c:2948! > [ 249.419050] invalid opcode: 0000 [#1] SMP > [ 249.419050] CPU 1 > [ 249.419050] Modules linked in: des_generic md4 nls_utf8 cifs fscache sunrpc ipx p8022 psnap llc p8023 rose ax25 joydev i2c_piix4 i2c_core virtio_balloon virtio_net virtio_blk [last unloaded: cifs] > [ 249.419050] > [ 249.419050] Pid: 1058, comm: mount.cifs Not tainted 3.0-0.rc2.git0.2.fc16.x86_64 #1 Bochs Bochs > [ 249.419050] RIP: 0010:[<ffffffff81126249>] [<ffffffff81126249>] kfree+0x60/0xfc > [ 249.419050] RSP: 0018:ffff88003ba2bce8 EFLAGS: 00010246 > [ 249.419050] RAX: 0020000000000000 RBX: ffffffffa013d46d RCX: ffff880034380930 > [ 249.419050] RDX: 0020000000000000 RSI: ffff8800314a4ea0 RDI: ffffffffa013d46d > [ 249.419050] RBP: ffff88003ba2bd08 R08: ffff88003e002500 R09: 000000000000005a > [ 249.419050] R10: ffffffff82421ed0 R11: 00000000000003a7 R12: ffffea0000704558 > [ 249.419050] R13: ffff88002f1a8050 R14: ffff88003140c2d0 R15: ffff88003a40d330 > [ 249.419050] FS: 00007f89290dc740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 > [ 249.419050] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 249.419050] CR2: 00007f804783a240 CR3: 000000003aea9000 CR4: 00000000000006e0 > [ 249.419050] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 249.419050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 249.419050] Process mount.cifs (pid: 1058, threadinfo ffff88003ba2a000, task ffff8800314a47a0) > [ 249.419050] Stack: > [ 249.419050] ffff88003c312000 ffff88003ba2bd70 ffff88002f1a8050 ffff88003140c2d0 > [ 249.419050] ffff88003ba2bd28 ffffffffa011e1a7 ffff88003ba1c240 ffff88003140c240 > [ 249.419050] ffff88003ba2bda8 ffffffffa0112107 ffff88003ba2bd98 ffff880034380930 > [ 249.419050] Call Trace: > [ 249.419050] [<ffffffffa011e1a7>] cifs_cleanup_volume_info+0x24/0x72 [cifs] > [ 249.419050] [<ffffffffa0112107>] cifs_do_mount+0x34e/0x364 [cifs] > [ 249.419050] [<ffffffff8113a2dd>] mount_fs+0x69/0x158 > [ 249.419050] [<ffffffff81103e6c>] ? __alloc_percpu+0x10/0x12 > [ 249.419050] [<ffffffff8114f35e>] vfs_kern_mount+0x63/0xa0 > [ 249.419050] [<ffffffff81150032>] do_kern_mount+0x4d/0xdf > [ 249.419050] [<ffffffff811516c8>] do_mount+0x63c/0x69f > [ 249.419050] [<ffffffff811519ac>] sys_mount+0x88/0xc2 > [ 249.419050] [<ffffffff814fb002>] system_call_fastpath+0x16/0x1b > [ 249.419050] Code: e9 ae 00 00 00 48 83 fb 10 0f 86 af 00 00 00 48 89 df e8 11 dd ff ff 49 89 c4 48 8b 00 a8 80 75 19 49 f7 04 24 00 c0 00 00 75 02 <0f> 0b 4c 89 e7 e8 78 e1 fc ff e9 84 00 00 00 4d 8b 6c 24 10 48 > [ 249.419050] RIP [<ffffffff81126249>] kfree+0x60/0xfc > [ 249.419050] RSP <ffff88003ba2bce8> > [ 249.474238] ---[ end trace 48c6ff1e268f2f6a ]--- > > > -- > Jeff Layton <jlayton@redhat.com> > Ok, I will look at it soon. -- Best regards, Pavel Shilovsky. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-13 15:48 ` Jeff Layton 2011-06-14 2:59 ` Pavel Shilovsky @ 2011-06-14 21:11 ` Martijn Uffing 1 sibling, 0 replies; 18+ messages in thread From: Martijn Uffing @ 2011-06-14 21:11 UTC (permalink / raw) To: Jeff Layton Cc: Connor Hansen, Suresh Jayaraman, linux-cifs, linux-kernel, sean finney, Pavel Shilovsky > (cc'ing Pavel) > > Ok, I've been able to reproduce on -rc2 as well, simply by mounting > with -o sec=none. Pavel, I'm pretty sure this got broken by commit > 724d9f1cfb. That patch doesn't handle the "null user" case correctly. > There are probably several different ways to fix it: > Ave all Just to confirm the OOPS/BUG is still present in 3.0-rc3 3.0-rc3 -> same OOPS as in rc1 3.0-rc3+ Jeff's patch -> same BUG as in rc1 Can I be helpful with further testing by cranking up some more debugging options in the kernel hacking section of "make menuconfig", or is the cause of the OOPS/BUG clear enough? Martijn ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-10 11:37 ` Jeff Layton 2011-06-10 12:03 ` Connor Hansen @ 2011-06-10 22:03 ` Martijn Uffing 1 sibling, 0 replies; 18+ messages in thread From: Martijn Uffing @ 2011-06-10 22:03 UTC (permalink / raw) To: Jeff Layton; +Cc: Connor Hansen, linux-cifs, linux-kernel, sean finney On Fri, 10 Jun 2011, Jeff Layton wrote: > On Fri, 10 Jun 2011 02:57:21 +0200 (CEST) > Uffing <mp3project@sarijopen.student.utwente.nl> wrote: > >> >> <snip> >>> call in get_dfs_path() >>> rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage); >>> >>> function header for CIFSTCon >>> int CIFSTCon(unsigned int xid, struct cifs_ses *ses, >>> const char *tree, struct cifs_tcon *tcon, >>> const struct nls_table *nls_codepage) >>> >>> get_dfs_path() is passing struct cifs_tcon *tcon as NULL >>> >>> from config: CONFIG_CIFS_WEAK_PW_HASH=y >>> >>> in CIFSTCon >>> >>> #ifdef CONFIG_CIFS_WEAK_PW_HASH >>> 3222 if ((global_secflags & CIFSSEC_MAY_LANMAN) && >>> 3223 (ses->server->secType == LANMAN)) >>> 3224 calc_lanman_hash(tcon->password, >>> ses->server->cryptkey, >>> >>> in calc_lanman_hash tcon is dereferenced(tcon->password) without being >>> checked if null >>> >>> 3225 ses->server->sec_mode & >>> 3226 SECMODE_PW_ENCRYPT ? >>> true : false, >>> 3227 bcc_ptr); >>> 3228 else >>> 3229 #endif /* CIFS_WEAK_PW_HASH */ >>> >>> Connor >> >> >> Ave all >> >> I recompiled kernel 3.0-rc1 (hadn't enabled CONFIG_DEBUG_INFO=y) and put >> the oops (with the new adresses) through gdb per instruction of Jeff. And >> Connor was spot on! >> >> <qoute oops> >> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 >> IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs] >> </qoute oops> >> >> <qoute gdb> >> This GDB was configured as "x86_64-linux-gnu". >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>... >> Reading symbols from >> /lib/modules/3.0.0-rc1-debug/kernel/fs/cifs/cifs.ko...done. >> (gdb) list *(CIFSTCon+0xf6) >> 0xc2b6 is in CIFSTCon (fs/cifs/connect.c:3230). >> 3225 ses->server->sec_mode & >> 3226 SECMODE_PW_ENCRYPT ? >> true : false, >> 3227 bcc_ptr); >> 3228 else >> 3229 #endif /* CIFS_WEAK_PW_HASH */ >> 3230 rc = SMBNTencrypt(tcon->password, >> ses->server->cryptkey, >> 3231 bcc_ptr); >> 3232 >> 3233 bcc_ptr += CIFS_AUTH_RESP_SIZE; >> 3234 if (ses->capabilities & CAP_UNICODE) { >> (gdb) >> </qoute gdb> >> > > (cc'ing Sean F. since I suspect this regression is due to his changes) > > Thanks for the analysis, Martijn and Connor... > > What sort of server are you mounting here? It looks like it's using > share-level security, so it's either very old or is a samba server > configured that way. To be honest ... both :) a)server is Debian Etch (samba 3.0.24-6etch10) (yeah i know old, but no time at the moment to upgrade/reinstall the whole system) b)share security. (security=share) in smb.conf This is on purpose. (all access is shielded based on hostnames) Mu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OOPS] 3.0-rc1 cifs 2011-06-09 20:15 [OOPS] 3.0-rc1 cifs Martijn Uffing 2011-06-09 22:30 ` Jeff Layton @ 2011-06-15 19:55 ` Maciej Rutecki 1 sibling, 0 replies; 18+ messages in thread From: Maciej Rutecki @ 2011-06-15 19:55 UTC (permalink / raw) To: Martijn Uffing; +Cc: linux-cifs, linux-kernel On czwartek, 9 czerwca 2011 o 22:15:05 Martijn Uffing wrote: > Ave People > > > I've got an oops with 3.0-rc1. (The same Oops also occurs with 3.0-rc2 and > the git snapshot of today linux-2.6-06e8684.) > The Oops occurs at boot time while the boot scripts try to automount a > samba share. > > Last (tested) working kernel : 2.6.39 > First (tested) oopsing kernel : 3.0-rc1 I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=37542 for your bug report, please add your address to the CC list in there, thanks! -- Maciej Rutecki http://www.maciek.unixy.pl ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-06-15 19:55 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-06-09 20:15 [OOPS] 3.0-rc1 cifs Martijn Uffing 2011-06-09 22:30 ` Jeff Layton 2011-06-09 22:50 ` Connor Hansen 2011-06-09 22:53 ` Connor Hansen 2011-06-10 0:57 ` Martijn Uffing 2011-06-10 11:37 ` Jeff Layton 2011-06-10 12:03 ` Connor Hansen 2011-06-10 12:14 ` Suresh Jayaraman 2011-06-10 12:49 ` Connor Hansen 2011-06-11 11:41 ` Jeff Layton 2011-06-11 16:25 ` Connor Hansen 2011-06-11 22:31 ` Martijn Uffing 2011-06-12 1:17 ` Jeff Layton 2011-06-13 15:48 ` Jeff Layton 2011-06-14 2:59 ` Pavel Shilovsky 2011-06-14 21:11 ` Martijn Uffing 2011-06-10 22:03 ` Martijn Uffing 2011-06-15 19:55 ` Maciej Rutecki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox