Kernel oops on 2.6.37-rc3, accessing remote DFS links

Kernel oops on 2.6.37-rc3, accessing remote DFS links

[Robbert Kouprie]

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

Re: Kernel oops on 2.6.37-rc3, accessing remote DFS links

[Jeff Layton]

On Mon, 6 Dec 2010 12:58:38 +0100 (CET)
Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:

> 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,
> 

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-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

[PATCH] cifs: allow calling cifs_build_path_to_root on incomplete cifs_sb

[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.

Reported-by: Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org>
Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@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

Re: Kernel oops on 2.6.37-rc3, accessing remote DFS links

[Robbert Kouprie]

Hi Jeff,

On Mon, 6 Dec 2010, Jeff Layton wrote:

> 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

Re: [PATCH] cifs: allow calling cifs_build_path_to_root on incomplete cifs_sb

[Robbert Kouprie]

Hi Jeff,

Op 6-12-2010 13:15, Jeff Layton schreef:
> 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

Re: [PATCH] cifs: allow calling cifs_build_path_to_root on incomplete cifs_sb

[Jeff Layton]

On Mon, 06 Dec 2010 20:12:34 +0100
Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:

> Hi Jeff,
> 
> Op 6-12-2010 13:15, Jeff Layton schreef:
> > 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> 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+AlfA@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

Re: [PATCH] cifs: allow calling cifs_build_path_to_root on incomplete cifs_sb

[Robbert Kouprie]

Hey Jeff,

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

Thanks!
Robbert

Op 6-12-2010 20:34, Jeff Layton schreef:
> On Mon, 06 Dec 2010 20:12:34 +0100
> Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org> wrote:
> 
>> Hi Jeff,
>>
>> Op 6-12-2010 13:15, Jeff Layton schreef:
>>> 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
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> 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+AlfA@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;
>  		}

[PATCH] cifs: allow calling cifs_build_path_to_root on incomplete cifs_sb

[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.

Reported-and-Tested-by: Robbert Kouprie <robbert-C1IQQP51G3M@public.gmane.org>
Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@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

Re: [PATCH] cifs: allow calling cifs_build_path_to_root on incomplete cifs_sb

[Jeff Layton]

On Wed, 16 Feb 2011 19:22:25 +1100
Darren Williams <darren.w-bdq14YP6qtRg9hUCZPvPmw@public.gmane.org> wrote:

> 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.
> 
> I'm just looking for clarification on the following feature or bug:
> 
> we have a SAMBA server, samba1, serving a DFS root as follows
> 
> [dfs]
>     path = /export/samba/dfs
>     msdfs root = yes
> 
> configured as:
> 
> ls -l /export/samba/dfs
> total 8
> lrwxrwxrwx 1 root root 79 2010-03-10 07:53 home -> 
> msdfs:samba1\dfshome,samba2\dfshome
> 
> and SAMBA servers, samba1 and samba2 with shares:
> 
> [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>
> then list the directory I get the following errors:
> 
> 
> root@atp-h5gcn1s:~# mount.cifs //samba1/dfs /tmp/dfs/ -o <options>
> Password:
> root@atp-h5gcn1s:~# ls -l /tmp/dfs/
> 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
> root@atp-h5gcn1s:~# ls -l /tmp/dfs/home/
> ls: cannot access /tmp/dfs/home/: Not a directory
> root@atp-h5gcn1s:~# umount /tmp/dfs
> 
> I then remount and access a file in 'home' directly, which then allows 
> the directory listing to succeed.
> 
> root@atp-h5gcn1s:~# mount.cifs //samba1/dfs /tmp/dfs/ -o 
> user=dwilliams,dom=NICTA
> Password:
> root@atp-h5gcn1s:~# ls -l /tmp/dfs/home/.bashrc
> -rw-r--r-- 1 <user> <group> 2450 Jun  8  2008 /tmp/dfs/home/.bashrc
> root@atp-h5gcn1s:~# ls  /tmp/dfs/
> home  projects    test-home
> root@atp-h5gcn1s:~# ls -l /tmp/dfs/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
> 
> root@atp-h5gcn1s:~# mount.cifs //samba1/dfs/home /tmp/dfs/ -o <options>
> 
> 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+AlfA@public.gmane.org>