On Tue, Apr 23, 2013 at 12:05:20PM -0400, J. Bruce Fields wrote: > On Tue, Apr 23, 2013 at 11:46:45AM -0400, Steve Dickson wrote: > > > > > > On 10/04/13 11:09, J. Bruce Fields wrote: > > > On Tue, Apr 02, 2013 at 05:45:41PM -0400, Steve Dickson wrote: > > >> > From: Steve Dickson <steved@xxxxxxxxxx> > > >> > > > >> > Here is the next release of the Label NFS patches > > >> > forward ported to linux-3.9-rc3. > > >> > > > >> > I decided to include the the v4.2 enabling patches since > > >> > I'm doing all my testing with both sets so at this point > > >> > I don't think it makes sense to separate them. Plus I'm > > >> > hoping they will take care of the SETATTR problem Bruce was > > >> > seeing since label attributes were leaking into the bitmask > > >> > when they were not suppose to. > > > Still getting a failure. All you need to do is something like: > > > > > > git clone git://linux-nfs.org/~bfields/pynfs.git > > > cd pynfs > > > ./setup.py build > > > ./setup.py build_ext --inplace > > > ./nfs4.0/testserver.py pip1:/path/to/export/tmpdir ---maketree --rundeps SATT13 > > Unfortunately, I'm not able to reproduce this error on any of the following kernels > > * No labels > > * No labels configured > > # CONFIG_NFS_V4_2 is not set > > # CONFIG_NFSD_V4_SECURITY_LABEL is not set > > * Labels configured > > CONFIG_NFS_V4_2=y > > CONFIG_NFS_V4_SECURITY_LABEL=y > > > > What exactly was failing? > > Sorry I can't find the results right now. I'll re-run and let you know. The server is returning -EOPNOTSUPP in response to an nfs4 SETATTR which sets a mode. The operation shouldn't be failing, and if it does it should return an NFS error, not -ERRNO. I can't reproduce this just by doing chmod on the linux client. I'm not sure what pynfs is doing differently to trigger the bug. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
