Narasimha Valiveti | 1 Aug 2007 18:26
Picon

cifs umount panic on centos5 (update 8)

Hello,

This may not be related to cifs unmount (as I have seen a similar panic during NFS umount also),
just wanted to check whether anyone has seen this on centos5 (or rhel5). With centos5 and latest
updates installed, I am seeing a panic during CIFS and NFS unmounts.
Here is the stack:

       process: umount.cifs

       shrink_dcache_for_umount+0x2e
       generic_shutdown_super+0x16
       kill_anon_super+0x9
       deactivate_super+0x52
       sys_umount+0x1f0
       . . .

[root <at> h22 ~]# uname -a
Linux h22 2.6.18-8.1.8.el5 #1 SMP Tue Jul 10 06:50:22 EDT 2007 i686 i686 i386 GNU/Linux

Has anyone encountered this on rhel 5 (centos 5) ?.
I have seen some change log description of this in 18 and 19 kernels, but not sure whether its
completely fixed yet and which patch version fixed it. Any pointers would help.

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.19
Thanks In Advance,
- vnr
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Peter Cook | 1 Aug 2007 18:43
Picon

Re: CIFS non-existant recursive directory

Thanks for the prompt responses Steve. I apologize on taking so long to reply--I had to convince Ubuntu that it wanted to work correctly with a custom kernel (no easy task) so that I could compile in 1.50. If interested, there is some really poorly written documentation on their custom kernel compilation here: https://wiki.ubuntu.com/KernelCustomBuild , which also has a link to using git to pull from their current development tree, which is what I did. Their current development version is 2.6.22-9 according to uname -r, and I replaced their cifs with 1.50 as well as patching with ck's ck1 patch set.

The good news is that 1.50 seems to have fixed the permissions errors I was working around before. I can leave LinuxExtensionsEnabled set to 1 and mount successfully. The share now honors the uid and gid that I specifiy, albeit ignoring my file_mode and dir_mode requests. Using the nounix option worked as you described (essentially LinuxExtensionsEnabled to 0), which then honors the uid, gid, file_mode and dir_mode as specified in the mount.

Here is the command I used to mount:
sudo mount -t cifs //192.168.2.2/mp3 /media/fileserver -o iocharset=utf8,file_mode=0777,dir_mode=0777,credentials=/etc/cifspw,sync,dirsync,uid=maytag,gid=mp3

Unfortunately, I am still having the same problem with the "ghost" recursive directory, as originally described (or as seen in detail here: http://ubuntuforums.org/showthread.php?p=3055182#post3055182 ).

To update on that thread slightly, I was able to replicate the ghost directory problem on a separate Ubuntu system using the same mount commands, albeit using the LinuxExtensionsEnabled 1 workaround due to the older version of cifs in the non-custom kernel.

Possibly relevant information:
On the client:
package samba is version: 3.0.24-2ubuntu1
package smbfs is version: 3.0.24-2ubuntu1

On the server, samba, smbfs, samba-common are all of the same version.

Could the problem be server side? Possibly something I have wrong in my smb.conf?

Thanks again for your time and responses.

-Peter

On 7/27/07, Steve French <smfrench <at> gmail.com> wrote:
> I have one note that wasn't mentioned on that thread, that came to me now.
> The only way I could get cifs to mount the share with the correct uid/gid
> was to manually set /proc/fs/cifs/LinuxExtensionsEnabled to 0.

You usually will get better behavior to Samba mounting with the Linux
Extensions enabled but wanted to note that with cifs 1.50 (now on the
download site if you have kernel version later than about 2.6.14 or so
http://pserver.samba.org/samba/ftp/cifs-cvs/cifs-1.50.tar.gz) you can
disable Unix Extensions more easily for just one mount via the new
cifs  mount option "nosfu"

Also note that since cifs version 1.49 (maybe even a little earlier)
you can override the uid and/or gid by specifying it on mount -
whether or not Unix Extensions are enabled.

--
Thanks,

Steve



--
Peter Cook
cookpj <at> gmail.com
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Akemi Yagi | 2 Aug 2007 20:42
Picon
Gravatar

Re: cifs umount panic on centos5 (update 8)

On Wed, 01 Aug 2007 09:26:48 -0700, Narasimha Valiveti wrote:

> Hello,
> 
> This may not be related to cifs unmount (as I have seen a similar panic
> during NFS umount also),
> just wanted to check whether anyone has seen this on centos5 (or rhel5).
> With centos5 and latest
> updates installed, I am seeing a panic during CIFS and NFS unmounts. Here
> is the stack:
> 
>        process: umount.cifs
> 
>        shrink_dcache_for_umount+0x2e
>        generic_shutdown_super+0x16
>        kill_anon_super+0x9
>        deactivate_super+0x52
>        sys_umount+0x1f0
>        . . .
> 
> [root <at> h22 ~]# uname -a
> Linux h22 2.6.18-8.1.8.el5 #1 SMP Tue Jul 10 06:50:22 EDT 2007 i686 i686
> i386 GNU/Linux
> 
> Has anyone encountered this on rhel 5 (centos 5) ?. I have seen some
> change log description of this in 18 and 19 kernels, but not sure whether
> its
> completely fixed yet and which patch version fixed it. Any pointers would
> help.
> 
> http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.19
> <http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.18>

kernel 2.6.18 (cifs 1.45) has a cifs bug that is known to cause
system crashes.  I don't know if your problem is related but check out
this CentOS bug report.  The patched cifs.ko is available for this
particular bug.

http://bugs.centos.org/view.php?id=1776

Also, test kernels with cifs 1.48 are available for RHEL and you can use
them in CentOS.  The info is in that bug report.

Akemi
Jeff Layton | 6 Aug 2007 15:54
Picon
Favicon

[PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)

Apologies for the resend, but the original sending had the date in the
email header and it caused some of these to bounce...

( Please consider trimming the Cc list if discussing some aspect of this
that doesn't concern everyone.)

When an unprivileged process attempts to modify a file that has the
setuid or setgid bits set, the VFS will attempt to clear these bits. The
VFS will set the ATTR_KILL_SUID or ATTR_KILL_SGID bits in the ia_valid
mask, and then call notify_change to clear these bits and set the mode
accordingly.

With a networked filesystem (NFS in particular but most likely others),
the client machine may not have credentials that allow for the clearing
of these bits. In some situations, this can lead to file corruption, or
to an operation failing outright because the setattr fails.

In this situation, we'd like to just leave the handling of this to
the server and ignore these bits. The problem is that by the time
nfs_setattr is called, the VFS has already reinterpreted the ATTR_KILL_*
bits into a mode change. We can't fix this in the filesystems where
this is a problem, as doing so would leave us having to second-guess
what the VFS wants us to do. So we need to change it so that filesystems
have more flexibility in how to interpret the ATTR_KILL_* bits.

The first patch in the following patchset moves this logic into a helper
function, and then only calls this helper function for inodes that do
not have a setattr operation defined. The subsequent patches fix up
individual filesystem setattr functions to call this helper function.

The upshot of this is that with this change, filesystems that define
a setattr inode operation are now responsible for handling the ATTR_KILL
bits as well. They can trivially do so by calling the helper, but they
must do so.

Some of the follow-on patches may not be strictly necessary, but I
decided that it was better to take the conservative approach and call
the helper when I wasn't sure. I've tried to CC the maintainers
for the individual filesystems as well where I could find them,
please let me know if there are others who should be informed.

Comments and suggestions appreciated...

Signed-off-by: Jeff Layton <jlayton <at> redhat.com>

Jeff Layton | 6 Aug 2007 15:54
Picon
Favicon

[PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function

Separate the handling of the local ia_valid bitmask from the one in
attr->ia_valid. This allows us to hand off the actual handling of the
ATTR_KILL_* flags to the .setattr i_op when one is defined.

notify_change still needs to process those flags for the local ia_valid
variable, since it uses that to decide whether to return early, and to pass
a (hopefully) appropriate bitmask to fsnotify_change.

Signed-off-by: Jeff Layton <jlayton <at> redhat.com>
---
 fs/attr.c          |   54 +++++++++++++++++++++++++++++++++------------------
 include/linux/fs.h |    1 +
 2 files changed, 36 insertions(+), 19 deletions(-)

diff --git a/fs/attr.c b/fs/attr.c
index f8dfc22..47015e0 100644
--- a/fs/attr.c
+++ b/fs/attr.c
 <at>  <at>  -100,15 +100,39  <at>  <at>  int inode_setattr(struct inode * inode, struct iattr * attr)
 }
 EXPORT_SYMBOL(inode_setattr);

+void attr_kill_to_mode(struct inode *inode, struct iattr *attr)
+{
+	if (attr->ia_valid & ATTR_KILL_SUID) {
+		attr->ia_valid &= ~ATTR_KILL_SUID;
+		if (inode->i_mode & S_ISUID) {
+			if (!(attr->ia_valid & ATTR_MODE)) {
+				attr->ia_valid |= ATTR_MODE;
+				attr->ia_mode = inode->i_mode;
+			}
+			attr->ia_mode &= ~S_ISUID;
+		}
+	}
+	if (attr->ia_valid & ATTR_KILL_SGID) {
+		attr->ia_valid &= ~ATTR_KILL_SGID;
+		if ((inode->i_mode & (S_ISGID | S_IXGRP)) ==
+		    (S_ISGID | S_IXGRP)) {
+			if (!(attr->ia_valid & ATTR_MODE)) {
+				attr->ia_valid |= ATTR_MODE;
+				attr->ia_mode = inode->i_mode;
+			}
+			attr->ia_mode &= ~S_ISGID;
+		}
+	}
+}
+EXPORT_SYMBOL(attr_kill_to_mode);
+
 int notify_change(struct dentry * dentry, struct iattr * attr)
 {
 	struct inode *inode = dentry->d_inode;
-	mode_t mode;
 	int error;
 	struct timespec now;
 	unsigned int ia_valid = attr->ia_valid;

-	mode = inode->i_mode;
 	now = current_fs_time(inode->i_sb);

 	attr->ia_ctime = now;
 <at>  <at>  -117,26 +141,17  <at>  <at>  int notify_change(struct dentry * dentry, struct iattr * attr)
 	if (!(ia_valid & ATTR_MTIME_SET))
 		attr->ia_mtime = now;
 	if (ia_valid & ATTR_KILL_SUID) {
-		attr->ia_valid &= ~ATTR_KILL_SUID;
-		if (mode & S_ISUID) {
-			if (!(ia_valid & ATTR_MODE)) {
-				ia_valid = attr->ia_valid |= ATTR_MODE;
-				attr->ia_mode = inode->i_mode;
-			}
-			attr->ia_mode &= ~S_ISUID;
-		}
+		ia_valid &= ~ATTR_KILL_SUID;
+		if (inode->i_mode & S_ISUID)
+			ia_valid |= ATTR_MODE;
 	}
 	if (ia_valid & ATTR_KILL_SGID) {
-		attr->ia_valid &= ~ ATTR_KILL_SGID;
-		if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
-			if (!(ia_valid & ATTR_MODE)) {
-				ia_valid = attr->ia_valid |= ATTR_MODE;
-				attr->ia_mode = inode->i_mode;
-			}
-			attr->ia_mode &= ~S_ISGID;
-		}
+		ia_valid &= ~ATTR_KILL_SGID;
+		if ((inode->i_mode & (S_ISGID | S_IXGRP)) ==
+		    (S_ISGID | S_IXGRP))
+			ia_valid |= ATTR_MODE;
 	}
-	if (!attr->ia_valid)
+	if (!ia_valid)
 		return 0;

 	if (ia_valid & ATTR_SIZE)
 <at>  <at>  -147,6 +162,7  <at>  <at>  int notify_change(struct dentry * dentry, struct iattr * attr)
 		if (!error)
 			error = inode->i_op->setattr(dentry, attr);
 	} else {
+		attr_kill_to_mode(inode, attr);
 		error = inode_change_ok(inode, attr);
 		if (!error)
 			error = security_inode_setattr(dentry, attr);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index d33bead..f617b23 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
 <at>  <at>  -1561,6 +1561,7  <at>  <at>  extern int do_remount_sb(struct super_block *sb, int flags,
 #ifdef CONFIG_BLOCK
 extern sector_t bmap(struct inode *, sector_t);
 #endif
+extern void attr_kill_to_mode(struct inode *inode, struct iattr *attr);
 extern int notify_change(struct dentry *, struct iattr *);
 extern int permission(struct inode *, int, struct nameidata *);
 extern int generic_permission(struct inode *, int,
--

-- 
1.5.2.2

Jeff Layton | 6 Aug 2007 15:54
Picon
Favicon

[PATCH 05/25] CIFS: call attr_kill_to_mode in cifs_setattr


Signed-off-by: Jeff Layton <jlayton <at> redhat.com>
---
 fs/cifs/inode.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index dd41677..6fee1fa 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
 <at>  <at>  -1429,6 +1429,8  <at>  <at>  int cifs_setattr(struct dentry *direntry, struct iattr *attrs)
 	cifs_sb = CIFS_SB(direntry->d_inode->i_sb);
 	pTcon = cifs_sb->tcon;

+	attr_kill_to_mode(direntry->d_inode, attrs);
+
 	if ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NO_PERM) == 0) {
 		/* check if we have permission to change attrs */
 		rc = inode_change_ok(direntry->d_inode, attrs);
--

-- 
1.5.2.2

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Miklos Szeredi | 6 Aug 2007 19:43
Picon

Re: [PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function

> Separate the handling of the local ia_valid bitmask from the one in
> attr->ia_valid. This allows us to hand off the actual handling of the
> ATTR_KILL_* flags to the .setattr i_op when one is defined.
> 
> notify_change still needs to process those flags for the local ia_valid
> variable, since it uses that to decide whether to return early, and to pass
> a (hopefully) appropriate bitmask to fsnotify_change.

I agree with this change and fuse will make use of it as well.

Maybe instead of unconditionally moving attr_kill_to_mode() inside
->setattr() it could be made conditional based on an inode flag
similarly to S_NOCMTIME.  Advantages:

 - no need to modify a lot of in-tree filesystems
 - no silent breakage of out-of-tree fs

Actually I think the new flag would be used by exacly the same
filesystems as S_NOCMTIME, so maybe it would make sense to rename
S_NOCMTIME to something more generic (S_NOATTRUPDATE or whatever) and
use that.

But that could still break out-of-tree fs, so a separate flag is
probably better.

Miklos

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
Jeff Layton | 6 Aug 2007 20:13
Picon
Favicon

Re: [fuse-devel] [PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function

On Mon, 06 Aug 2007 19:43:46 +0200
Miklos Szeredi <miklos <at> szeredi.hu> wrote:

> > Separate the handling of the local ia_valid bitmask from the one in
> > attr->ia_valid. This allows us to hand off the actual handling of the
> > ATTR_KILL_* flags to the .setattr i_op when one is defined.
> > 
> > notify_change still needs to process those flags for the local ia_valid
> > variable, since it uses that to decide whether to return early, and to pass
> > a (hopefully) appropriate bitmask to fsnotify_change.
> 
> I agree with this change and fuse will make use of it as well.
> 
> Maybe instead of unconditionally moving attr_kill_to_mode() inside
> ->setattr() it could be made conditional based on an inode flag
> similarly to S_NOCMTIME.  Advantages:
> 
>  - no need to modify a lot of in-tree filesystems
>  - no silent breakage of out-of-tree fs
> 
> Actually I think the new flag would be used by exacly the same
> filesystems as S_NOCMTIME, so maybe it would make sense to rename
> S_NOCMTIME to something more generic (S_NOATTRUPDATE or whatever) and
> use that.
> 
> But that could still break out-of-tree fs, so a separate flag is
> probably better.
> 

In the past I've been told that adding new flags is something of a
"last resort". Since it's not strictly necessary to fix this then
it may be best to avoid that.

That said, if the concensus is that we need a transition mechanism,
then I'd be open to such a suggestion.

--

-- 
Jeff Layton <jlayton <at> redhat.com>

Miklos Szeredi | 6 Aug 2007 20:28
Picon

Re: [PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function

> > I agree with this change and fuse will make use of it as well.
> > 
> > Maybe instead of unconditionally moving attr_kill_to_mode() inside
> > ->setattr() it could be made conditional based on an inode flag
> > similarly to S_NOCMTIME.  Advantages:
> > 
> >  - no need to modify a lot of in-tree filesystems
> >  - no silent breakage of out-of-tree fs
> > 
> > Actually I think the new flag would be used by exacly the same
> > filesystems as S_NOCMTIME, so maybe it would make sense to rename
> > S_NOCMTIME to something more generic (S_NOATTRUPDATE or whatever) and
> > use that.
> > 
> > But that could still break out-of-tree fs, so a separate flag is
> > probably better.
> > 
> 
> In the past I've been told that adding new flags is something of a
> "last resort". Since it's not strictly necessary to fix this then
> it may be best to avoid that.
> 
> That said, if the concensus is that we need a transition mechanism,
> then I'd be open to such a suggestion.

I think there's really no other choice here.

Your patch is changing the API in a very unsafe way, since there will
be no error or warning on an unconverted fs.  And that could lead to
security holes.

If we would rename the setattr method to setattr_new as well as
changing it's behavior, that would be fine.  But I guess we do not
want to do that.

Miklos

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
Trond Myklebust | 6 Aug 2007 21:04
Picon
Picon

Re: [fuse-devel] [PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function

On Mon, 2007-08-06 at 20:28 +0200, Miklos Szeredi wrote:

> Your patch is changing the API in a very unsafe way, since there will
> be no error or warning on an unconverted fs.  And that could lead to
> security holes.
> 
> If we would rename the setattr method to setattr_new as well as
> changing it's behavior, that would be fine.  But I guess we do not
> want to do that.

Which "unconverted fses"? If we're talking out of tree stuff, then too
bad: it is _their_ responsibility to keep up with kernel changes.

Trond

-
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane