Hi Phil, I just checked in a fix for this. Basically, the problem was that in pvfs2_init_acl(), i wanted to mark the inode as dirty if its mode changed. Instead i was unconditionally marking it as dirty..duh Could you give it a spin and see if that fixes this issue? Thanks, Murali
On Wed, 20 Sep 2006, Phil Carns wrote: > We are seeing a new problem (not sure how long it has been around) with > setgid permission bits on directories. This happens with 2.6 kernels: > > /home/pcarns> mkdir /mnt/pvfs2/dir1 > /home/pcarns> chmod g+s /mnt/pvfs2/dir1 > /home/pcarns> mkdir /mnt/pvfs2/dir1/dir2 > /home/pcarns> ls -alh /mnt/pvfs2/dir1/ > total 12K > drwxr-sr-x 1 pcarns users 4.0K Sep 19 23:02 . > drwxrwxrwt 1 root root 4.0K Sep 19 23:02 .. > drwxr-xr-x 1 pcarns users 4.0K Sep 19 23:02 dir2 > > The problem is that dir2 did not inherit the setgid as it should have. > > Digging a little further, I can see this protocol exchange during the > "mkdir /mnt/pvfs2/dir1/dir2" command: > > - mkdir (with setgid bit appropriately set) > - crdirent > - getattr (with response showing setgid bit set) > - setattr (which clears the setgid bit) > > A snippet of the kernel logs with all of the debugging masks turned on > is listed below. The getattr is definitely seeing an i_mode of 42755, > but then a pvfs2_flush_inode() call is made which sets it to 40755. > > Any idea why pvfs2_flush_inode() is being triggered after the > subdirectory is created, and why it has the wrong permission bits? > > thanks, > -Phil > > > > Alloced OP (c3e483e0: 173 OP_MKDIR) > pvfs2: service_operation: pvfs2_create_dir c3e483e0 > client-core: reading op tag 173 OP_MKDIR > (get) Alloced OP (c3e483e0:173) > pvfs2: service_operation pvfs2_create_dir returning: 0 for c3e483e0. > Mkdir Got PVFS2 handle 1048567 on fsid 1451462841 > pvfs2_get_custom_inode: called > (sb is c0f81600 | MAJOR(dev)=0 | MINOR(dev)=0) > pvfs2_alloc_inode: allocated c9aa64b8 > pvfs2_read_inode: c9aa64b8 (inode = 1048567 | ct = 1) > pvfs2_inode_getattr: called on inode 1048567 > Alloced OP (c58bc420: 174 OP_GETATTR) > pvfs2: service_operation: pvfs2_inode_getattr c58bc420 > client-core: reading op tag 174 OP_GETATTR > (get) Alloced OP (c58bc420:174) > pvfs2: service_operation pvfs2_inode_getattr returning: 0 for c58bc420. > attrs->mask = 510007f (1048576, objtype = 4), size = 0 > pvfs2: copy_attributes_to_inode: setting inode->i_mode to 42755 from 0 > Getattr on handle 1048567, fsid 1451462841 > (inode ct = 1) returned 0 > Releasing OP (c58bc420: 174) > pvfs2_get_custom_inode: inode c9aa64e4 allocated > (pvfs2_inode is c9aa64b8 | sb is c0f81600) > Initializing ACL's for inode 1048567 > inode->i_mode before 40755 and after 40755 > pvfs2_flush_inode (1048567) writing mode 40755 > *********** pvfs2_flush_inode: 1048567 (ia_valid 1) > Alloced OP (c58bc420: 175 OP_SETATTR) > mode is 16877 | translated perms is 493 > pvfs2: service_operation: pvfs2_inode_setattr c58bc420 > client-core: reading op tag 175 OP_SETATTR > (get) Alloced OP (c58bc420:175) > pvfs2: service_operation pvfs2_inode_setattr returning: 0 for c58bc420. > pvfs2_inode_setattr: returning 0 > Releasing OP (c58bc420: 175) > Assigned dir inode new number of 1048567 > pvfs2_create_dir: Instantiating > *negative* dentry c52cf118 for test4 > Inode (Directory) 1048567 -> test4 > Releasing OP (c3e483e0: 173) > pvfs2_dirty_inode: 1048574 > _______________________________________________ > Pvfs2-developers mailing list > [email protected] > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers > > _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
