Bug 5993 - mount -o remount, brl or -o remount, nobrl changes the reported "mand" option, but has no effect
mount -o remount, brl or -o remount, nobrl changes the reported "mand" option...
Status: RESOLVED FIXED
Product: CifsVFS
Classification: Unclassified
Component: user space tools
2.6
Other Linux
: P3 normal
: ---
Assigned To: Steve French
http://bugs.debian.org/483502
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-25 11:25 UTC by Debian samba package maintainers (PUBLIC MAILING LIST)
Modified: 2012-04-06 11:04 UTC (History)
1 user (show)

See Also:


Attachments
Test case provided by our user (1.00 KB, text/x-csrc)
2008-12-25 11:26 UTC, Debian samba package maintainers (PUBLIC MAILING LIST)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Debian samba package maintainers (PUBLIC MAILING LIST) 2008-12-25 11:25:34 UTC
As reported by our user in Debian:

When remounting a CIFS mount to change the byte-range locking option,
the system reports success; but the system's behavior continues to
reflect the originally-mounted choice.

While researching http://bugs.debian.org/483216, i discovered that
byte-range locks against files CIFS shares mounted with mount.cifs are
normally interpreted as "mandatory" locks, instead of "advisory"
locks.  This is adjustable with the nobrl/brl mount options.  mount
claims to be able to successfully modify those options using -o
remount, but in practice, the changed options don't seem to have any
effect at all, and the option selected at initial mount time is the
persistent behavior.

In particular, locking a certain range of a file with a read lock and
then locking the same range with a write lock gives an error when a
CIFS share is mounted with "brl".  This doesn't make much sense to me,
but i'm willing to accept it as intended for now.

I wrote a simple program (source attached) to test this locking
behavior.  I also observed that "brl" is translated into the "mand"
option in the relevant line in /proc/mounts, and that "nobrl" maps to
the *absence* of the "mand" option in the /proc/mounts entry.

You can adjust the options reported in /proc/mounts using the standard
"mount -o remount,newoptions" syntax, but the mountpoint's behavior
does not change. 

Here's a transcript demonstrating the problem.  "bob" is running the
most recent version of samba available in debian etch.  Note that the
behavior of the "testlocking" program is not changed by the -o remount
commands, even though /proc/mounts reflects the change:

[0 root@squeak ~]# grep /mnt /proc/mounts 
[1 root@squeak ~]# mount -t cifs -o guest,uid=dkg,sec=none //bob/dmz /mnt
[0 root@squeak ~]# grep /mnt /proc/mounts 
//bob/dmz /mnt cifs rw,mand,unc=\\bob\dmz,username=,uid=1000,posixpaths,rsize=16384,wsize=57344 0 0
[0 root@squeak ~]# touch /mnt/foo
[0 root@squeak ~]# ~dkg/src/cmrg/test/testlocking/testlocking /mnt/foo
write lock failed
[1 root@squeak ~]# mount -o remount,nobrl,guest,uid=dkg,sec=none /mnt
[0 root@squeak ~]# grep /mnt /proc/mounts 
//bob/dmz /mnt cifs rw,unc=\\bob\dmz,username=,uid=1000,posixpaths,rsize=16384,wsize=57344 0 0
[0 root@squeak ~]# ~dkg/src/cmrg/test/testlocking/testlocking /mnt/foo
write lock failed
[1 root@squeak ~]# umount /mnt
[0 root@squeak ~]# grep /mnt /proc/mounts 
[1 root@squeak ~]# mount -t cifs -o nobrl,guest,uid=dkg,sec=none //bob/dmz /mnt
[0 root@squeak ~]# grep /mnt /proc/mounts 
//bob/dmz /mnt cifs rw,unc=\\bob\dmz,username=,uid=1000,posixpaths,rsize=16384,wsize=57344 0 0
[0 root@squeak ~]# ~dkg/src/cmrg/test/testlocking/testlocking /mnt/foo
[0 root@squeak ~]# mount -o remount,brl,guest,uid=dkg,sec=none /mnt
[0 root@squeak ~]# grep /mnt /proc/mounts 
//bob/dmz /mnt cifs rw,mand,unc=\\bob\dmz,username=,uid=1000,posixpaths,rsize=16384,wsize=57344 0 0
[0 root@squeak ~]# ~dkg/src/cmrg/test/testlocking/testlocking /mnt/foo
[0 root@squeak ~]#
Comment 1 Debian samba package maintainers (PUBLIC MAILING LIST) 2008-12-25 11:26:46 UTC
Created attachment 3829 [details]
Test case provided by our user

This is the test program provided by our user
Comment 2 Shirish S. Pargaonkar 2009-03-05 15:19:17 UTC
Yes, -o remmount does not seem to change the original mount options to the 
ones during remount, looking into this.
It also adds an additional entry in /etc/mtab that does not get removed during
unmount and has to be removed from /etc/mtab manually.
Comment 3 Shirish S. Pargaonkar 2009-03-06 13:23:43 UTC
Looking at the mount.cifs documentation (man mount.cifs), I do not see
a remount option (i.e. -o remount).  cifs vfs client does not support
a remount option.
Comment 4 Steve French 2009-08-24 18:26:25 UTC
We should support changing most of the cifs_fs_sb.h flags (at least those that might not conflict with values on the tcon).   For updating tcon bit flags we need to first check if the share (tcon) is mounted twice (two superblocks pointing to one tcon - which presumably would preclude changing a flag common to both).  Similarly we could change things on the smb session but few things seem like good candidates to allow user to change there so for time being we probably can fix cifs_remount to only allow chaning flags (most but not all) of those in cifs_fs_sb.h and fail or ignore other changes.
Comment 5 Jeff Layton 2012-04-06 11:04:27 UTC
The handling of mand should now be cleaner and make more sense. Enabling "mand"
by default was a mistake since that tells the kernel to enforce mandatory
locks instead of leaving it up to the server. This should be fixed now in
current mount.cifs and kernel releases.