Discussion:
Kernel oops on 2.6.37-rc3, accessing remote DFS links
(too old to reply)
Robbert Kouprie
2010-12-06 11:58:38 UTC
Permalink
Hi,

While troubleshooting a DFS issue, I hit a kernel panic:

foxdft13 = DFS root
foxdft08 = file server, serving "Global" share

# mount -t cifs //foxdft13.fox.local/company /mnt/bla/ -o
credentials=/creds,sec=ntlmv2,dom=fox
# ls -la /mnt/bla/Global/

fs/cifs/inode.c: CIFS VFS: in cifs_revalidate_dentry as Xid: 603 with
uid: 0
fs/cifs/inode.c: Revalidate: \\foxdft13.fox.local\company\Global inode
0xe289aaac count 1 dentry: 0xda8c53b8 d_time 151744140 jiffies 151765235
fs/cifs/inode.c: Getting info on \\foxdft13.fox.local\company\Global
fs/cifs/transport.c: For smb_command 50
fs/cifs/transport.c: Sending smb: total_len 148
fs/cifs/connect.c: rfc1002 length 0x27
fs/cifs/connect.c: invalid transact2 word count
Status code returned 0xc0000257 NT_STATUS_PATH_NOT_COVERED
fs/cifs/netmisc.c: Mapping smb error code 3 to POSIX err -66
fs/cifs/cifssmb.c: Send error in QPathInfo = -66
fs/cifs/inode.c: creating fake fattr for DFS referral
fs/cifs/inode.c: cifs_revalidate_cache: revalidating inode 62
fs/cifs/inode.c: cifs_revalidate_cache: invalidating inode 62 mapping
fs/cifs/inode.c: inode 0xe289aaac old_time=151744140 new_time=151765237
fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate_dentry (xid = 603) rc
= 0
fs/cifs/cifs_dfs_ref.c: in cifs_dfs_follow_mountpoint
fs/cifs/cifs_dfs_ref.c: CIFS VFS: in cifs_dfs_follow_mountpoint as Xid:
604 with uid: 0
fs/cifs/cifssmb.c: In GetDFSRefer the path
\foxdft13.fox.local\company\Global
fs/cifs/transport.c: For smb_command 50
fs/cifs/transport.c: Sending smb: total_len 144
fs/cifs/connect.c: rfc1002 length 0x124
fs/cifs/cifssmb.c: Decoding GetDFSRefer response BCC: 233 Offset 56
fs/cifs/cifssmb.c: num_referrals: 1 dfs flags: 0x2 ...

fs/cifs/cifs_dfs_ref.c: DFS: ref path: \foxdft13.fox.local\company\Global
fs/cifs/cifs_dfs_ref.c: DFS: node path: \foxdft08\company\Global
fs/cifs/cifs_dfs_ref.c: DFS: fl: 2, srv_type: 0
fs/cifs/cifs_dfs_ref.c: DFS: ref_flags: 0, path_consumed: 34
fs/cifs/dns_resolve.c: dns_resolve_server_name_to_ip: resolved: foxdft08
to 10.0.0.72
fs/cifs/cifsfs.c: Devname: \\foxdft08\company flags: 0
fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 605 with uid: 0
fs/cifs/connect.c: Domain name set
fs/cifs/connect.c: prefix path /Global
fs/cifs/connect.c: Username: vmtest
fs/cifs/connect.c: UNC: \\foxdft08\company ip: 10.0.0.72
fs/cifs/connect.c: Existing tcp session with server found
fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 606 with uid: 0
fs/cifs/connect.c: Existing smb sess found (status=1)
fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 606) rc = 0
fs/cifs/connect.c: file mode: 0x1ed dir mode: 0x1ed
fs/cifs/connect.c: Found match on UNC path
fs/cifs/connect.c: cifs_put_smb_ses: ses_count=2

fs/cifs/cifssmb.c: In QFSDeviceInfo
fs/cifs/transport.c: For smb_command 50
fs/cifs/transport.c: Sending smb: total_len 72
fs/cifs/connect.c: rfc1002 length 0x44
fs/cifs/cifssmb.c: In QFSAttributeInfo
fs/cifs/transport.c: For smb_command 50
fs/cifs/transport.c: Sending smb: total_len 72
fs/cifs/connect.c: rfc1002 length 0x50
BUG: unable to handle kernel NULL pointer dereference at 0000001c
IP: [<f909e327>] cifs_sb_master_tcon+0x3/0x7 [cifs]
*pde = 00000000
Oops: 0000 [#2] SMP
last sysfs file: /sys/devices/virtual/bdi/cifs-183/uevent
Modules linked in: cifs hmac nls_utf8 nls_base xfs exportfs loop
parport_pc snd_pcm parport tpm_tis tpm tpm_bios snd_timer snd soundcore
psmouse snd_page_alloc pcspkr evdev serio_raw i2c_piix4 shpchp i2c_core
pci_hotplug ac container processor thermal_sys button ext3 jbd mbcache
sd_mod crc_t10dif ide_cd_mod cdrom ata_generic ata_piix libata floppy
e1000 mptspi piix mptscsih mptbase scsi_transport_spi ide_core scsi_mod
[last unloaded: cifs]

Pid: 1504, comm: ls Tainted: G D 2.6.37-rc3 #1 440BX Desktop
Reference Platform/VMware Virtual Platform
EIP: 0060:[<f909e327>] EFLAGS: 00010292 CPU: 2
EIP is at cifs_sb_master_tcon+0x3/0x7 [cifs]
EAX: 00000000 EBX: f7031400 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: f70c4000 EBP: f70c4000 ESP: f37c7d30
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process ls (pid: 1504, ti=f37c6000 task=f50a69a0 task.ti=f37c6000)
Stack:
f90aa3ab 0000004c 00000007 f4380000 f7031400 00000000 f7031100 f70c4000
f90a2a79 f70c5200 c127c977 f72affff f501b600 0000025d ef110540 f72a6718
f70c5e00 00000000 ef110540 f50a69a0 f50a69a0 f70c4174 f72a6728 00007d9c
Call Trace:
[<f90aa3ab>] ? cifs_build_path_to_root+0x17/0xe5 [cifs]
[<f90a2a79>] ? cifs_mount+0x19f0/0x1e3f [cifs]
[<c127c977>] ? _raw_spin_lock_bh+0x8/0x1e
[<f90958f9>] ? cifs_do_mount+0x110/0x247 [cifs]
[<f90957e9>] ? cifs_do_mount+0x0/0x247 [cifs]
[<c10b8331>] ? vfs_kern_mount+0x9f/0x185
[<f90b4c03>] ? cifs_dfs_follow_mountpoint+0x233/0x3cc [cifs]
[<c10bebab>] ? do_follow_link+0xb6/0x1b1
[<c10bef38>] ? link_path_walk+0x292/0x372
[<c10bf0da>] ? path_walk+0x4f/0xae
[<c10bf20b>] ? do_path_lookup+0x1f/0x69
[<c10bfaa8>] ? user_path_at+0x37/0x5f
[<c1098b0d>] ? vma_prio_tree_insert+0x17/0x2d
[<c10b99b1>] ? vfs_fstatat+0x2a/0x50
[<c10b9a18>] ? vfs_lstat+0x13/0x15
[<c10b9a29>] ? sys_lstat64+0xf/0x23
[<c1052a6c>] ? sys_futex+0xfe/0x112
[<c10b503c>] ? filp_close+0x4e/0x54
[<c127f339>] ? do_page_fault+0x0/0x36b
[<c1002f9f>] ? sysenter_do_call+0x12/0x28
Code: c8 59 5f 39 ee 0f 8c 49 ff ff ff 8b 44 24 60 65 33 05 14 00 00 00
74 05 e8 3f 0c f9 c7 83 c4 64 5b 5e 5f 5d c3 90 90 90 8b 40 08 <8b> 40 1c
c3 55 89 c5 83 3d a4 47 3b c1 00 57 89 d7 56 89 ce 53
EIP: [<f909e327>] cifs_sb_master_tcon+0x3/0x7 [cifs] SS:ESP 0068:f37c7d30
CR2: 000000000000001c
---[ end trace 9642afdeb896e709 ]---

Any ideas?

Regards,
--
Robbert
Jeff Layton
2010-12-06 12:08:46 UTC
Permalink
On Mon, 6 Dec 2010 12:58:38 +0100 (CET)
Post by Robbert Kouprie
Hi,
foxdft13 = DFS root
foxdft08 = file server, serving "Global" share
# mount -t cifs //foxdft13.fox.local/company /mnt/bla/ -o
credentials=/creds,sec=ntlmv2,dom=fox
# ls -la /mnt/bla/Global/
fs/cifs/inode.c: CIFS VFS: in cifs_revalidate_dentry as Xid: 603 with
uid: 0
fs/cifs/inode.c: Revalidate: \\foxdft13.fox.local\company\Global inode
0xe289aaac count 1 dentry: 0xda8c53b8 d_time 151744140 jiffies 151765235
fs/cifs/inode.c: Getting info on \\foxdft13.fox.local\company\Global
fs/cifs/transport.c: For smb_command 50
fs/cifs/transport.c: Sending smb: total_len 148
fs/cifs/connect.c: rfc1002 length 0x27
fs/cifs/connect.c: invalid transact2 word count
Status code returned 0xc0000257 NT_STATUS_PATH_NOT_COVERED
fs/cifs/netmisc.c: Mapping smb error code 3 to POSIX err -66
fs/cifs/cifssmb.c: Send error in QPathInfo = -66
fs/cifs/inode.c: creating fake fattr for DFS referral
fs/cifs/inode.c: cifs_revalidate_cache: revalidating inode 62
fs/cifs/inode.c: cifs_revalidate_cache: invalidating inode 62 mapping
fs/cifs/inode.c: inode 0xe289aaac old_time=151744140 new_time=151765237
fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate_dentry (xid = 603) rc
= 0
fs/cifs/cifs_dfs_ref.c: in cifs_dfs_follow_mountpoint
604 with uid: 0
fs/cifs/cifssmb.c: In GetDFSRefer the path
\foxdft13.fox.local\company\Global
fs/cifs/transport.c: For smb_command 50
fs/cifs/transport.c: Sending smb: total_len 144
fs/cifs/connect.c: rfc1002 length 0x124
fs/cifs/cifssmb.c: Decoding GetDFSRefer response BCC: 233 Offset 56
fs/cifs/cifssmb.c: num_referrals: 1 dfs flags: 0x2 ...
fs/cifs/cifs_dfs_ref.c: DFS: ref path: \foxdft13.fox.local\company\Global
fs/cifs/cifs_dfs_ref.c: DFS: node path: \foxdft08\company\Global
fs/cifs/cifs_dfs_ref.c: DFS: fl: 2, srv_type: 0
fs/cifs/cifs_dfs_ref.c: DFS: ref_flags: 0, path_consumed: 34
fs/cifs/dns_resolve.c: dns_resolve_server_name_to_ip: resolved: foxdft08
to 10.0.0.72
fs/cifs/cifsfs.c: Devname: \\foxdft08\company flags: 0
fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 605 with uid: 0
fs/cifs/connect.c: Domain name set
fs/cifs/connect.c: prefix path /Global
fs/cifs/connect.c: Username: vmtest
fs/cifs/connect.c: UNC: \\foxdft08\company ip: 10.0.0.72
fs/cifs/connect.c: Existing tcp session with server found
fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 606 with uid: 0
fs/cifs/connect.c: Existing smb sess found (status=1)
fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 606) rc = 0
fs/cifs/connect.c: file mode: 0x1ed dir mode: 0x1ed
fs/cifs/connect.c: Found match on UNC path
fs/cifs/connect.c: cifs_put_smb_ses: ses_count=2
fs/cifs/cifssmb.c: In QFSDeviceInfo
fs/cifs/transport.c: For smb_command 50
fs/cifs/transport.c: Sending smb: total_len 72
fs/cifs/connect.c: rfc1002 length 0x44
fs/cifs/cifssmb.c: In QFSAttributeInfo
fs/cifs/transport.c: For smb_command 50
fs/cifs/transport.c: Sending smb: total_len 72
fs/cifs/connect.c: rfc1002 length 0x50
BUG: unable to handle kernel NULL pointer dereference at 0000001c
IP: [<f909e327>] cifs_sb_master_tcon+0x3/0x7 [cifs]
*pde = 00000000
Oops: 0000 [#2] SMP
last sysfs file: /sys/devices/virtual/bdi/cifs-183/uevent
Modules linked in: cifs hmac nls_utf8 nls_base xfs exportfs loop
parport_pc snd_pcm parport tpm_tis tpm tpm_bios snd_timer snd soundcore
psmouse snd_page_alloc pcspkr evdev serio_raw i2c_piix4 shpchp i2c_core
pci_hotplug ac container processor thermal_sys button ext3 jbd mbcache
sd_mod crc_t10dif ide_cd_mod cdrom ata_generic ata_piix libata floppy
e1000 mptspi piix mptscsih mptbase scsi_transport_spi ide_core scsi_mod
[last unloaded: cifs]
Pid: 1504, comm: ls Tainted: G D 2.6.37-rc3 #1 440BX Desktop
Reference Platform/VMware Virtual Platform
EIP: 0060:[<f909e327>] EFLAGS: 00010292 CPU: 2
EIP is at cifs_sb_master_tcon+0x3/0x7 [cifs]
EAX: 00000000 EBX: f7031400 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: f70c4000 EBP: f70c4000 ESP: f37c7d30
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process ls (pid: 1504, ti=f37c6000 task=f50a69a0 task.ti=f37c6000)
f90aa3ab 0000004c 00000007 f4380000 f7031400 00000000 f7031100 f70c4000
f90a2a79 f70c5200 c127c977 f72affff f501b600 0000025d ef110540 f72a6718
f70c5e00 00000000 ef110540 f50a69a0 f50a69a0 f70c4174 f72a6728 00007d9c
[<f90aa3ab>] ? cifs_build_path_to_root+0x17/0xe5 [cifs]
[<f90a2a79>] ? cifs_mount+0x19f0/0x1e3f [cifs]
[<c127c977>] ? _raw_spin_lock_bh+0x8/0x1e
[<f90958f9>] ? cifs_do_mount+0x110/0x247 [cifs]
[<f90957e9>] ? cifs_do_mount+0x0/0x247 [cifs]
[<c10b8331>] ? vfs_kern_mount+0x9f/0x185
[<f90b4c03>] ? cifs_dfs_follow_mountpoint+0x233/0x3cc [cifs]
[<c10bebab>] ? do_follow_link+0xb6/0x1b1
[<c10bef38>] ? link_path_walk+0x292/0x372
[<c10bf0da>] ? path_walk+0x4f/0xae
[<c10bf20b>] ? do_path_lookup+0x1f/0x69
[<c10bfaa8>] ? user_path_at+0x37/0x5f
[<c1098b0d>] ? vma_prio_tree_insert+0x17/0x2d
[<c10b99b1>] ? vfs_fstatat+0x2a/0x50
[<c10b9a18>] ? vfs_lstat+0x13/0x15
[<c10b9a29>] ? sys_lstat64+0xf/0x23
[<c1052a6c>] ? sys_futex+0xfe/0x112
[<c10b503c>] ? filp_close+0x4e/0x54
[<c127f339>] ? do_page_fault+0x0/0x36b
[<c1002f9f>] ? sysenter_do_call+0x12/0x28
Code: c8 59 5f 39 ee 0f 8c 49 ff ff ff 8b 44 24 60 65 33 05 14 00 00 00
74 05 e8 3f 0c f9 c7 83 c4 64 5b 5e 5f 5d c3 90 90 90 8b 40 08 <8b> 40 1c
c3 55 89 c5 83 3d a4 47 3b c1 00 57 89 d7 56 89 ce 53
EIP: [<f909e327>] cifs_sb_master_tcon+0x3/0x7 [cifs] SS:ESP 0068:f37c7d30
CR2: 000000000000001c
---[ end trace 9642afdeb896e709 ]---
Any ideas?
Regards,
Yeah, it's a bug (obviously). I think I see what the problem is and
will send along a patch in a few minutes. Are you able to reproduce this at
will?
--
Jeff Layton <jlayton-***@public.gmane.org>
Jeff Layton
2010-12-06 12:15:03 UTC
Permalink
It's possible that cifs_mount will call cifs_build_path_to_root on a
newly instantiated cifs_sb. In that case, it's likely that the
master_tlink pointer has not yet been instantiated.

Fix this by having cifs_build_path_to_root take a cifsTconInfo pointer
as well, and have the caller pass that in.

Reported-by: Robbert Kouprie <robbert-***@public.gmane.org>
Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
---
fs/cifs/cifsproto.h | 3 ++-
fs/cifs/connect.c | 2 +-
fs/cifs/inode.c | 6 +++---
3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index f4cc34f..4e65b67 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -54,7 +54,8 @@ do { \
__func__, curr_xid, (int)rc); \
} while (0)
extern char *build_path_from_dentry(struct dentry *);
-extern char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb);
+extern char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb,
+ struct cifsTconInfo *tcon);
extern char *build_wildcard_path_from_dentry(struct dentry *direntry);
extern char *cifs_compose_mount_options(const char *sb_mountdata,
const char *fullpath, const struct dfs_info3_param *ref,
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index af7fa78..f2f58e3 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2913,7 +2913,7 @@ remote_path_check:
/* check if a whole path (including prepath) is not remote */
if (!rc && cifs_sb->prepathlen && tcon) {
/* build_path_to_root works only when we have a valid tcon */
- full_path = cifs_build_path_to_root(cifs_sb);
+ full_path = cifs_build_path_to_root(cifs_sb, tcon);
if (full_path == NULL) {
rc = -ENOMEM;
goto mount_fail_check;
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 0c1efbb..0023146 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -729,12 +729,12 @@ static const struct inode_operations cifs_ipc_inode_ops = {
.lookup = cifs_lookup,
};

-char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb)
+char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb,
+ struct cifsTconInfo *tcon)
{
int pplen = cifs_sb->prepathlen;
int dfsplen;
char *full_path = NULL;
- struct cifsTconInfo *tcon = cifs_sb_master_tcon(cifs_sb);

/* if no prefix path, simply set path to the root of share to "" */
if (pplen == 0) {
@@ -881,7 +881,7 @@ struct inode *cifs_root_iget(struct super_block *sb, unsigned long ino)
char *full_path;
struct cifsTconInfo *tcon = cifs_sb_master_tcon(cifs_sb);

- full_path = cifs_build_path_to_root(cifs_sb);
+ full_path = cifs_build_path_to_root(cifs_sb, tcon);
if (full_path == NULL)
return ERR_PTR(-ENOMEM);
--
1.7.3.2
Robbert Kouprie
2010-12-06 19:12:34 UTC
Permalink
Hi Jeff,
Post by Jeff Layton
It's possible that cifs_mount will call cifs_build_path_to_root on a
newly instantiated cifs_sb. In that case, it's likely that the
master_tlink pointer has not yet been instantiated.
Fix this by having cifs_build_path_to_root take a cifsTconInfo pointer
as well, and have the caller pass that in.
I still get an oops on 2.6.37-rc4-git5 with the patch applied:

BUG: unable to handle kernel NULL pointer dereference at 0000001c
IP: [<f8fd533b>] cifs_sb_master_tcon+0x3/0x7 [cifs]
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/bdi/cifs-2/uevent
Modules linked in: hmac nls_utf8 cifs nls_base xfs exportfs loop
snd_pcm parport_pc parport tpm_tis tpm tpm_bios snd_timer snd soundcore
snd_page_alloc psmouse evdev pcspkr serio_raw i2c_piix4 i2c_core shpchp
container pci_hotplug processor thermal_sys ac button ext3 jbd mbcache
sd_mod crc_t10dif ide_cd_mod cdrom ata_generic ata_piix libata floppy
e1000 mptspi mptscsih mptbase scsi_transport_spi scsi_mod piix ide_core
[last unloaded: scsi_wait_scan]

Pid: 1362, comm: ls Not tainted 2.6.37-rc4-git5 #2 440BX Desktop
Reference Platform/VMware Virtual Platform
EIP: 0060:[<f8fd533b>] EFLAGS: 00010286 CPU: 0
EIP is at cifs_sb_master_tcon+0x3/0x7 [cifs]
EAX: 00000000 EBX: f7156800 ECX: 40000040 EDX: 00000002
ESI: f7156800 EDI: f7156a00 EBP: 00000000 ESP: f72fddb0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process ls (pid: 1362, ti=f72fc000 task=f71379e0 task.ti=f72fc000)
Stack:
f8fe14f3 002c80d0 00000000 f7156a00 f7156800 00000000 00000000 f8fcc96b
0000007f f7156838 f5073d80 f50ac840 f8ff9f30 f8fcc7fd f522b000 c10b8301
f50ac900 f5073d80 00000000 f50ac900 f50ac900 f72fded4 00000000 f8febc6f
Call Trace:
[<f8fe14f3>] ? cifs_root_iget+0x1e/0x13f [cifs]
[<f8fcc96b>] ? cifs_do_mount+0x16e/0x247 [cifs]
[<f8fcc7fd>] ? cifs_do_mount+0x0/0x247 [cifs]
[<c10b8301>] ? vfs_kern_mount+0x9f/0x185
[<f8febc6f>] ? cifs_dfs_follow_mountpoint+0x233/0x3cc [cifs]
[<c10bec73>] ? do_follow_link+0xb6/0x1b1
[<c10bf000>] ? link_path_walk+0x292/0x372
[<c10bf1a2>] ? path_walk+0x4f/0xae
[<c10bf2d3>] ? do_path_lookup+0x1f/0x69
[<c10bfb70>] ? user_path_at+0x37/0x5f
[<c1098af9>] ? vma_prio_tree_insert+0x17/0x2d
[<c10b9981>] ? vfs_fstatat+0x2a/0x50
[<c10b99e8>] ? vfs_lstat+0x13/0x15
[<c10b99f9>] ? sys_lstat64+0xf/0x23
[<c1052a04>] ? sys_futex+0xfe/0x112
[<c10b500c>] ? filp_close+0x4e/0x54
[<c127f54f>] ? do_page_fault+0x0/0x36b
[<c1002f9f>] ? sysenter_do_call+0x12/0x28
Code: c8 59 5f 39 ee 0f 8c 49 ff ff ff 8b 44 24 60 65 33 05 14 00 00 00
74 05 e8 ef 9b 05 c8 83 c4 64 5b 5e 5f 5d c3 90 90 90 8b 40 08 <8b> 40
1c c3 55 89 c5 83 3d a4 47 3b c1 00 57 89 d7 56 89 ce 53
EIP: [<f8fd533b>] cifs_sb_master_tcon+0x3/0x7 [cifs] SS:ESP 0068:f72fddb0
CR2: 000000000000001c
---[ end trace 61b6103d05293c43 ]---

Regards,
Robbert
Jeff Layton
2010-12-06 19:34:23 UTC
Permalink
On Mon, 06 Dec 2010 20:12:34 +0100
Post by Robbert Kouprie
Hi Jeff,
Post by Jeff Layton
It's possible that cifs_mount will call cifs_build_path_to_root on a
newly instantiated cifs_sb. In that case, it's likely that the
master_tlink pointer has not yet been instantiated.
Fix this by having cifs_build_path_to_root take a cifsTconInfo pointer
as well, and have the caller pass that in.
BUG: unable to handle kernel NULL pointer dereference at 0000001c
IP: [<f8fd533b>] cifs_sb_master_tcon+0x3/0x7 [cifs]
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/bdi/cifs-2/uevent
Modules linked in: hmac nls_utf8 cifs nls_base xfs exportfs loop
snd_pcm parport_pc parport tpm_tis tpm tpm_bios snd_timer snd soundcore
snd_page_alloc psmouse evdev pcspkr serio_raw i2c_piix4 i2c_core shpchp
container pci_hotplug processor thermal_sys ac button ext3 jbd mbcache
sd_mod crc_t10dif ide_cd_mod cdrom ata_generic ata_piix libata floppy
e1000 mptspi mptscsih mptbase scsi_transport_spi scsi_mod piix ide_core
[last unloaded: scsi_wait_scan]
Pid: 1362, comm: ls Not tainted 2.6.37-rc4-git5 #2 440BX Desktop
Reference Platform/VMware Virtual Platform
EIP: 0060:[<f8fd533b>] EFLAGS: 00010286 CPU: 0
EIP is at cifs_sb_master_tcon+0x3/0x7 [cifs]
EAX: 00000000 EBX: f7156800 ECX: 40000040 EDX: 00000002
ESI: f7156800 EDI: f7156a00 EBP: 00000000 ESP: f72fddb0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process ls (pid: 1362, ti=f72fc000 task=f71379e0 task.ti=f72fc000)
f8fe14f3 002c80d0 00000000 f7156a00 f7156800 00000000 00000000 f8fcc96b
0000007f f7156838 f5073d80 f50ac840 f8ff9f30 f8fcc7fd f522b000 c10b8301
f50ac900 f5073d80 00000000 f50ac900 f50ac900 f72fded4 00000000 f8febc6f
[<f8fe14f3>] ? cifs_root_iget+0x1e/0x13f [cifs]
[<f8fcc96b>] ? cifs_do_mount+0x16e/0x247 [cifs]
[<f8fcc7fd>] ? cifs_do_mount+0x0/0x247 [cifs]
[<c10b8301>] ? vfs_kern_mount+0x9f/0x185
[<f8febc6f>] ? cifs_dfs_follow_mountpoint+0x233/0x3cc [cifs]
[<c10bec73>] ? do_follow_link+0xb6/0x1b1
[<c10bf000>] ? link_path_walk+0x292/0x372
[<c10bf1a2>] ? path_walk+0x4f/0xae
[<c10bf2d3>] ? do_path_lookup+0x1f/0x69
[<c10bfb70>] ? user_path_at+0x37/0x5f
[<c1098af9>] ? vma_prio_tree_insert+0x17/0x2d
[<c10b9981>] ? vfs_fstatat+0x2a/0x50
[<c10b99e8>] ? vfs_lstat+0x13/0x15
[<c10b99f9>] ? sys_lstat64+0xf/0x23
[<c1052a04>] ? sys_futex+0xfe/0x112
[<c10b500c>] ? filp_close+0x4e/0x54
[<c127f54f>] ? do_page_fault+0x0/0x36b
[<c1002f9f>] ? sysenter_do_call+0x12/0x28
Code: c8 59 5f 39 ee 0f 8c 49 ff ff ff 8b 44 24 60 65 33 05 14 00 00 00
74 05 e8 ef 9b 05 c8 83 c4 64 5b 5e 5f 5d c3 90 90 90 8b 40 08 <8b> 40
1c c3 55 89 c5 83 3d a4 47 3b c1 00 57 89 d7 56 89 ce 53
EIP: [<f8fd533b>] cifs_sb_master_tcon+0x3/0x7 [cifs] SS:ESP 0068:f72fddb0
CR2: 000000000000001c
---[ end trace 61b6103d05293c43 ]---
Regards,
Robbert
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Interesting...does this (untested) patch fix it? It may have to be "wiggled" into
place depending on your tree. If so, I'm surprised no one has tripped
over this before...

----------------[snip]--------------------

cifs: fix check of error return from is_path_accessable

This function will return 0 if everything went ok.

Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
---
fs/cifs/connect.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index bee397f..9fbe7c5 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2836,7 +2836,7 @@ remote_path_check:
goto mount_fail_check;
}
rc = is_path_accessible(xid, tcon, cifs_sb, full_path);
- if (rc != -EREMOTE) {
+ if (rc != 0 && rc != -EREMOTE) {
kfree(full_path);
goto mount_fail_check;
}
--
1.7.3.2
Robbert Kouprie
2010-12-06 21:39:37 UTC
Permalink
Hey Jeff,

This patch fixes the oops, and the remote DFS link is readable. Great!

Thanks!
Robbert
Post by Jeff Layton
On Mon, 06 Dec 2010 20:12:34 +0100
Post by Robbert Kouprie
Hi Jeff,
Post by Jeff Layton
It's possible that cifs_mount will call cifs_build_path_to_root on a
newly instantiated cifs_sb. In that case, it's likely that the
master_tlink pointer has not yet been instantiated.
Fix this by having cifs_build_path_to_root take a cifsTconInfo pointer
as well, and have the caller pass that in.
BUG: unable to handle kernel NULL pointer dereference at 0000001c
IP: [<f8fd533b>] cifs_sb_master_tcon+0x3/0x7 [cifs]
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/bdi/cifs-2/uevent
Modules linked in: hmac nls_utf8 cifs nls_base xfs exportfs loop
snd_pcm parport_pc parport tpm_tis tpm tpm_bios snd_timer snd soundcore
snd_page_alloc psmouse evdev pcspkr serio_raw i2c_piix4 i2c_core shpchp
container pci_hotplug processor thermal_sys ac button ext3 jbd mbcache
sd_mod crc_t10dif ide_cd_mod cdrom ata_generic ata_piix libata floppy
e1000 mptspi mptscsih mptbase scsi_transport_spi scsi_mod piix ide_core
[last unloaded: scsi_wait_scan]
Pid: 1362, comm: ls Not tainted 2.6.37-rc4-git5 #2 440BX Desktop
Reference Platform/VMware Virtual Platform
EIP: 0060:[<f8fd533b>] EFLAGS: 00010286 CPU: 0
EIP is at cifs_sb_master_tcon+0x3/0x7 [cifs]
EAX: 00000000 EBX: f7156800 ECX: 40000040 EDX: 00000002
ESI: f7156800 EDI: f7156a00 EBP: 00000000 ESP: f72fddb0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process ls (pid: 1362, ti=f72fc000 task=f71379e0 task.ti=f72fc000)
f8fe14f3 002c80d0 00000000 f7156a00 f7156800 00000000 00000000 f8fcc96b
0000007f f7156838 f5073d80 f50ac840 f8ff9f30 f8fcc7fd f522b000 c10b8301
f50ac900 f5073d80 00000000 f50ac900 f50ac900 f72fded4 00000000 f8febc6f
[<f8fe14f3>] ? cifs_root_iget+0x1e/0x13f [cifs]
[<f8fcc96b>] ? cifs_do_mount+0x16e/0x247 [cifs]
[<f8fcc7fd>] ? cifs_do_mount+0x0/0x247 [cifs]
[<c10b8301>] ? vfs_kern_mount+0x9f/0x185
[<f8febc6f>] ? cifs_dfs_follow_mountpoint+0x233/0x3cc [cifs]
[<c10bec73>] ? do_follow_link+0xb6/0x1b1
[<c10bf000>] ? link_path_walk+0x292/0x372
[<c10bf1a2>] ? path_walk+0x4f/0xae
[<c10bf2d3>] ? do_path_lookup+0x1f/0x69
[<c10bfb70>] ? user_path_at+0x37/0x5f
[<c1098af9>] ? vma_prio_tree_insert+0x17/0x2d
[<c10b9981>] ? vfs_fstatat+0x2a/0x50
[<c10b99e8>] ? vfs_lstat+0x13/0x15
[<c10b99f9>] ? sys_lstat64+0xf/0x23
[<c1052a04>] ? sys_futex+0xfe/0x112
[<c10b500c>] ? filp_close+0x4e/0x54
[<c127f54f>] ? do_page_fault+0x0/0x36b
[<c1002f9f>] ? sysenter_do_call+0x12/0x28
Code: c8 59 5f 39 ee 0f 8c 49 ff ff ff 8b 44 24 60 65 33 05 14 00 00 00
74 05 e8 ef 9b 05 c8 83 c4 64 5b 5e 5f 5d c3 90 90 90 8b 40 08 <8b> 40
1c c3 55 89 c5 83 3d a4 47 3b c1 00 57 89 d7 56 89 ce 53
EIP: [<f8fd533b>] cifs_sb_master_tcon+0x3/0x7 [cifs] SS:ESP 0068:f72fddb0
CR2: 000000000000001c
---[ end trace 61b6103d05293c43 ]---
Regards,
Robbert
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Interesting...does this (untested) patch fix it? It may have to be "wiggled" into
place depending on your tree. If so, I'm surprised no one has tripped
over this before...
----------------[snip]--------------------
cifs: fix check of error return from is_path_accessable
This function will return 0 if everything went ok.
---
fs/cifs/connect.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index bee397f..9fbe7c5 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
goto mount_fail_check;
}
rc = is_path_accessible(xid, tcon, cifs_sb, full_path);
- if (rc != -EREMOTE) {
+ if (rc != 0 && rc != -EREMOTE) {
kfree(full_path);
goto mount_fail_check;
}
Robbert Kouprie
2010-12-06 12:35:14 UTC
Permalink
Hi Jeff,
Post by Jeff Layton
Yeah, it's a bug (obviously). I think I see what the problem is and
will send along a patch in a few minutes. Are you able to reproduce this at
will?
Yes, I can reproduce this. I will test your patch right away.

Regards,
Robbert
Jeff Layton
2011-02-16 12:25:07 UTC
Permalink
On Wed, 16 Feb 2011 19:22:25 +1100
Hi All
Robert and Jeff thanks for working on and fixing this, I can confirm
that we now have;
- Remote DFS mounts working, using
- both sec=krb5 and sec=ntlm.
we have a SAMBA server, samba1, serving a DFS root as follows
[dfs]
path = /export/samba/dfs
msdfs root = yes
ls -l /export/samba/dfs
total 8
lrwxrwxrwx 1 root root 79 2010-03-10 07:53 home ->
msdfs:samba1\dfshome,samba2\dfshome
[dfshome]
comment = DFS Linux Home Directories
path = /export/home/1/%u
create mask = 0700
force create mode = 0700
directory mask = 0700
force directory mode = 0700
read only = No
browseable = No
valid users = %U
map acl inherit = yes
If I cifs mount the DFS root using
mount.cifs //samba1/dfs /tmp/dfs -o <options as required>
ls: cannot read symbolic link /tmp/dfs/home: Object is remote
ls: cannot read symbolic link /tmp/dfs/test-home: Object is remote
ls: cannot read symbolic link /tmp/dfs/projects: Object is remote
total 8
lrwxrwxrwx 1 root root 79 Mar 10 2010 home
lrwxrwxrwx 1 root root 46 Mar 10 2010 projects
lrwxrwxrwx 1 root root 79 Mar 25 2010 test-home
ls: cannot access /tmp/dfs/home/: Not a directory
I then remount and access a file in 'home' directly, which then allows
the directory listing to succeed.
user=dwilliams,dom=NICTA
-rw-r--r-- 1 <user> <group> 2450 Jun 8 2008 /tmp/dfs/home/.bashrc
home projects test-home
-rw-r--r-- 1 <user> <group> 3078 Aug 17 2007 2007-08-17-P.....
....
also access is OK if you mount 'home' directly via dfs
I'm looking for clarification on what the correct operation should be
since our Windows clients can access the root the traverse the directory
tree without error, not that this is evidence for correct operation.
I believe that's a bug...

The way things like autofs, DFS referrals and NFS used to work is by
pretending these mountpoints are symlinks and then abusing the
->follow_link operation on them in the kernel. Not all operations on
that inode trigger the follow_link op however, so sometimes -EREMOTE
errors bubble up when they shouldn't. Either that or we just have some
straightforward bad handling of -EREMOTE errors in the readdir codepath
-- I'm not sure yet :)

What may be best is to open a bug at bugzilla.samba.org and we'll chase
it down when we get a chance. If you do that, please cc me on it. FWIW,
I opened this bug a while back which is probably related, but haven't
had time to work on it:

https://bugzilla.redhat.com/show_bug.cgi?id=616765

This may also be helped by the d_automount patches that dhowells did
recently and that are going into 2.6.38, but I haven't had time to look
yet.
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
Jeff Layton
2010-12-07 02:07:32 UTC
Permalink
It's possible that cifs_mount will call cifs_build_path_to_root on a
newly instantiated cifs_sb. In that case, it's likely that the
master_tlink pointer has not yet been instantiated.

Fix this by having cifs_build_path_to_root take a cifsTconInfo pointer
as well, and have the caller pass that in.

Reported-and-Tested-by: Robbert Kouprie <robbert-***@public.gmane.org>
Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
---
fs/cifs/cifsproto.h | 3 ++-
fs/cifs/connect.c | 2 +-
fs/cifs/inode.c | 6 +++---
3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index 5523047..e6d1481 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -54,7 +54,8 @@ do { \
__func__, curr_xid, (int)rc); \
} while (0)
extern char *build_path_from_dentry(struct dentry *);
-extern char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb);
+extern char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb,
+ struct cifsTconInfo *tcon);
extern char *build_wildcard_path_from_dentry(struct dentry *direntry);
extern char *cifs_compose_mount_options(const char *sb_mountdata,
const char *fullpath, const struct dfs_info3_param *ref,
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 53f9c31..0a203ec 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2833,7 +2833,7 @@ remote_path_check:
/* check if a whole path (including prepath) is not remote */
if (!rc && cifs_sb->prepathlen && tcon) {
/* build_path_to_root works only when we have a valid tcon */
- full_path = cifs_build_path_to_root(cifs_sb);
+ full_path = cifs_build_path_to_root(cifs_sb, tcon);
if (full_path == NULL) {
rc = -ENOMEM;
goto mount_fail_check;
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index aa48521..589f3e3 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -728,12 +728,12 @@ static const struct inode_operations cifs_ipc_inode_ops = {
.lookup = cifs_lookup,
};

-char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb)
+char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb,
+ struct cifsTconInfo *tcon)
{
int pplen = cifs_sb->prepathlen;
int dfsplen;
char *full_path = NULL;
- struct cifsTconInfo *tcon = cifs_sb_master_tcon(cifs_sb);

/* if no prefix path, simply set path to the root of share to "" */
if (pplen == 0) {
@@ -875,7 +875,7 @@ struct inode *cifs_root_iget(struct super_block *sb, unsigned long ino)
char *full_path;
struct cifsTconInfo *tcon = cifs_sb_master_tcon(cifs_sb);

- full_path = cifs_build_path_to_root(cifs_sb);
+ full_path = cifs_build_path_to_root(cifs_sb, tcon);
if (full_path == NULL)
return ERR_PTR(-ENOMEM);
--
1.7.3.2
Jeff Layton
2010-12-07 02:07:33 UTC
Permalink
This function will return 0 if everything went ok. Commit 9d002df4
however added a block of code after the following check for
rc == -EREMOTE. With that change and when rc == 0, doing the
"goto mount_fail_check" here skips that code, leaving the tlink_tree
and master_tlink pointer unpopulated. That causes an oops later
in cifs_root_iget.

Reported-and-Tested-by: Robbert Kouprie <robbert-***@public.gmane.org>
Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
---
fs/cifs/connect.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 0a203ec..cc1a860 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2839,7 +2839,7 @@ remote_path_check:
goto mount_fail_check;
}
rc = is_path_accessible(xid, tcon, cifs_sb, full_path);
- if (rc != -EREMOTE) {
+ if (rc != 0 && rc != -EREMOTE) {
kfree(full_path);
goto mount_fail_check;
}
--
1.7.3.2
Loading...