Patchwork surprise behavior #1: ENOENT for existing directories

login
register
mail settings
Submitter Suresh Jayaraman
Date Nov. 30, 2009, 11:15 a.m.
Message ID <4B13A96F.20105@suse.de>
Download mbox | patch
Permalink /patch/39794/
State New
Headers show

Comments

Suresh Jayaraman - Nov. 30, 2009, 11:15 a.m.
On 11/30/2009 07:46 AM, aaron brick wrote:
> i am having two intermittent problems with CIFS and am sending
> separate emails to the list for each. this paragraph is identical. my
> desktop runs debian and kernel 2.6.32rc7; i am mounting a filesystem
> from my synology NAS, running DSM 2.2-0942 and using ext3 & RAID5
> internally. the link is gigabit through cat5e and a netgear switch.
> the only CIFS dmesg entry i see is a couple of: "CIFS VFS: server
> 10.1.1.2 of type Samba 3.2.8 returned unexpected error on SMB posix
> open, disabling posix open support. Check if server update available."
> (FWIW, synology hasn't released a firmware with a more recent samba.)
> 
> 
> here, creating files within a directory sometimes fails with ENOENT as
> if the parent did not exist. this generally prevents me from using the
> shared filesystem for compilation. an example follows:
> 
> 
> 11:08 / > mount | grep nas
> //nas/data on /data type cifs (rw,mand)
> 11:08 / > cd data
> 11:08 /data > mkdir a
> 11:08 /data > mkdir a/b
> mkdir: cannot create directory `a/b': No such file or directory
> 11:08 /data > strace mkdir a/b |& grep mkdir
> execve("/bin/mkdir", ["mkdir", "a/b"], [/* 22 vars */]) = 0
> mkdir("a/b", 0777)                      = -1 ENOENT (No such file or directory)
> write(2, "mkdir: ", 7mkdir: )                  = 7
> 

I have not been able to reproduce this 2.6.31-rc1 against Samba 3.2.7. But a
quick look at the code suggests there could be a problem if we do this
sequence:

POSIX open against Samba server < 3.3.1 (tcon->broken_posix_open will be set)
followed by a mkdir (will call CIFSPOSIXCreate). As we don't seem to check
whether the broken_posix_open is set, this might have led to this issue I think.

Does the following patch (a quick, untested) fix the issue?



 fs/cifs/inode.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

  

Thanks,
Jeff Layton - Nov. 30, 2009, 1:23 p.m.
On Mon, 30 Nov 2009 16:45:59 +0530
Suresh Jayaraman <sjayaraman@suse.de> wrote:

> On 11/30/2009 07:46 AM, aaron brick wrote:
> > i am having two intermittent problems with CIFS and am sending
> > separate emails to the list for each. this paragraph is identical. my
> > desktop runs debian and kernel 2.6.32rc7; i am mounting a filesystem
> > from my synology NAS, running DSM 2.2-0942 and using ext3 & RAID5
> > internally. the link is gigabit through cat5e and a netgear switch.
> > the only CIFS dmesg entry i see is a couple of: "CIFS VFS: server
> > 10.1.1.2 of type Samba 3.2.8 returned unexpected error on SMB posix
> > open, disabling posix open support. Check if server update available."
> > (FWIW, synology hasn't released a firmware with a more recent samba.)
> > 
> > 
> > here, creating files within a directory sometimes fails with ENOENT as
> > if the parent did not exist. this generally prevents me from using the
> > shared filesystem for compilation. an example follows:
> > 
> > 
> > 11:08 / > mount | grep nas
> > //nas/data on /data type cifs (rw,mand)
> > 11:08 / > cd data
> > 11:08 /data > mkdir a
> > 11:08 /data > mkdir a/b
> > mkdir: cannot create directory `a/b': No such file or directory
> > 11:08 /data > strace mkdir a/b |& grep mkdir
> > execve("/bin/mkdir", ["mkdir", "a/b"], [/* 22 vars */]) = 0
> > mkdir("a/b", 0777)                      = -1 ENOENT (No such file or directory)
> > write(2, "mkdir: ", 7mkdir: )                  = 7
> > 
> 
> I have not been able to reproduce this 2.6.31-rc1 against Samba 3.2.7. But a
> quick look at the code suggests there could be a problem if we do this
> sequence:
> 
> POSIX open against Samba server < 3.3.1 (tcon->broken_posix_open will be set)
> followed by a mkdir (will call CIFSPOSIXCreate). As we don't seem to check
> whether the broken_posix_open is set, this might have led to this issue I think.
> 
> Does the following patch (a quick, untested) fix the issue?
> 
> 
> 
>  fs/cifs/inode.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index cababd8..f1e9ab6 100644
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -1038,7 +1038,8 @@ int cifs_mkdir(struct inode *inode, struct dentry *direntry, int mode)
>  		return rc;
>  	}
>  
> -	if ((pTcon->ses->capabilities & CAP_UNIX) &&
> +	if (!tcon->broken_posix_open && tcon->unix_ext &&
             ^^^^ should be "pTcon"

> +	    (pTcon->ses->capabilities & CAP_UNIX) &&
>  		(CIFS_UNIX_POSIX_PATH_OPS_CAP &
>  			le64_to_cpu(pTcon->fsUnixInfo.Capability))) {
>  		u32 oplock = 0;
>   
> 
> Thanks,
>

Patch

diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index cababd8..f1e9ab6 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -1038,7 +1038,8 @@  int cifs_mkdir(struct inode *inode, struct dentry *direntry, int mode)
 		return rc;
 	}
 
-	if ((pTcon->ses->capabilities & CAP_UNIX) &&
+	if (!tcon->broken_posix_open && tcon->unix_ext &&
+	    (pTcon->ses->capabilities & CAP_UNIX) &&
 		(CIFS_UNIX_POSIX_PATH_OPS_CAP &
 			le64_to_cpu(pTcon->fsUnixInfo.Capability))) {
 		u32 oplock = 0;