<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/sys/fs, branch stable/9</title>
<subtitle>FreeBSD source tree</subtitle>
<id>https://cgit-dev.freebsd.org/src/atom?h=stable%2F9</id>
<link rel='self' href='https://cgit-dev.freebsd.org/src/atom?h=stable%2F9'/>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/'/>
<updated>2017-05-07T20:32:07Z</updated>
<entry>
<title>MFC: r317236</title>
<updated>2017-05-07T20:32:07Z</updated>
<author>
<name>Rick Macklem</name>
<email>rmacklem@FreeBSD.org</email>
</author>
<published>2017-05-07T20:32:07Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=98b435731c8482c377f26cdf698abd8166812e5c'/>
<id>urn:sha1:98b435731c8482c377f26cdf698abd8166812e5c</id>
<content type='text'>
Fix the setting of atime for Linux client NFSv4 mounts.

The FreeBSD NFSv4 server did not set the attribute bit for TimeAccess in
the reply to an Open with exclusive_create, as required by the RFCs.
(This is required since the FreeBSD NFS server stores the create_verifier
 in the va_atime attribute.)
As such, the Linux NFSv4 client did not set the TimeAccess (atime) in
the Setattr done in an RPC after the one with the Open/exclusive_create.
This patch fixes the server to set the TimeAccess bit in the reply.

I believe that storing the create_verifier in an extended attribute for
file systems that support extended attributes might be a good idea,
but I will wait for a discussion of this on the freebsd-fs@ email list
before considering committing a patch to do this.
</content>
</entry>
<entry>
<title>MFC: r316667</title>
<updated>2017-04-26T23:32:57Z</updated>
<author>
<name>Rick Macklem</name>
<email>rmacklem@FreeBSD.org</email>
</author>
<published>2017-04-26T23:32:57Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=a2d84d5e0d2eae777b47b9fdf6fa4dcf05849f3a'/>
<id>urn:sha1:a2d84d5e0d2eae777b47b9fdf6fa4dcf05849f3a</id>
<content type='text'>
Fix the NFSv4 client hndling of a stale write verifier in the Commit operation.

When the NFSv4 client Commit operation encountered a stale write verifier,
it erroneously mapped that to EIO. This could have caused recently written
data to be lost when a server crashes/reboots between an UNSTABLE write
and the subsequent commit. This patch fixes this.
The bug was only for the NFSv4 client and did not affect NFSv3.
</content>
</entry>
<entry>
<title>MFC r292961, r295717:</title>
<updated>2016-12-06T10:37:27Z</updated>
<author>
<name>Konstantin Belousov</name>
<email>kib@FreeBSD.org</email>
</author>
<published>2016-12-06T10:37:27Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=c6e047f2a2eb7bb8b40d6976cbfda92a3a6642f7'/>
<id>urn:sha1:c6e047f2a2eb7bb8b40d6976cbfda92a3a6642f7</id>
<content type='text'>
Force nullfs vnode reclaim after unlinking and directory removal.

PR:	178238
</content>
</entry>
<entry>
<title>MFC r309179:</title>
<updated>2016-12-03T00:46:18Z</updated>
<author>
<name>Pedro F. Giffuni</name>
<email>pfg@FreeBSD.org</email>
</author>
<published>2016-12-03T00:46:18Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=37f47b56cb33eec27ce76b09a04e810cc761d01e'/>
<id>urn:sha1:37f47b56cb33eec27ce76b09a04e810cc761d01e</id>
<content type='text'>
ext2fs: avoid possible overflow when calculating malloc size.

This is inspired on r308064 for the case of mounting UFS.
</content>
</entry>
<entry>
<title>MFC r303799, r303800:</title>
<updated>2016-09-06T19:54:52Z</updated>
<author>
<name>Pedro F. Giffuni</name>
<email>pfg@FreeBSD.org</email>
</author>
<published>2016-09-06T19:54:52Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=cadfa734078f2cce19a1f37f8731325841a51db4'/>
<id>urn:sha1:cadfa734078f2cce19a1f37f8731325841a51db4</id>
<content type='text'>
ext2fs:	Add defines for some missing ext4 features and inode flags.

These are currently unused in our implementation and some even appear to
have not been implemented yet on linux but it is good to keep them for
reference.

Obtained from:	NetBSD
</content>
</entry>
<entry>
<title>MFC: r299514</title>
<updated>2016-05-27T23:15:58Z</updated>
<author>
<name>Rick Macklem</name>
<email>rmacklem@FreeBSD.org</email>
</author>
<published>2016-05-27T23:15:58Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=b58f3b9b31c4d06a0ef7ead7d16ad586427aca27'/>
<id>urn:sha1:b58f3b9b31c4d06a0ef7ead7d16ad586427aca27</id>
<content type='text'>
Fix use-after-free in NFS4 lock test service.

Trivial use-after-free where stp was freed too soon in the non-error path.
To fix, simply move its release to the end of the routine.
</content>
</entry>
<entry>
<title>MFC: r299201</title>
<updated>2016-05-20T01:25:14Z</updated>
<author>
<name>Rick Macklem</name>
<email>rmacklem@FreeBSD.org</email>
</author>
<published>2016-05-20T01:25:14Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=78fa4ef2fe1011bbddcb893a405004ad01c1dc2c'/>
<id>urn:sha1:78fa4ef2fe1011bbddcb893a405004ad01c1dc2c</id>
<content type='text'>
Give mountd -S priority over outstanding RPC requests when suspending the nfsd.

It was reported via email that under certain heavy RPC loads
long delays before the exports would be updated was observed
when using "mountd -S". This patch reverses the priority between
the exclusive lock request to suspend the nfsd threads and the
shared lock request for performing RPCs.
As such, when mountd attempts to suspend the nfsd threads, it
gets priority over outstanding RPC requests to do this.
I suspect that the case reported was an artificial test load,
but this patch did fix the problem for the reporter.
</content>
</entry>
<entry>
<title>MFC r298609:</title>
<updated>2016-05-10T02:15:09Z</updated>
<author>
<name>Pedro F. Giffuni</name>
<email>pfg@FreeBSD.org</email>
</author>
<published>2016-05-10T02:15:09Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=1b26979626237f19f2763607ea38e2e83bfc4316'/>
<id>urn:sha1:1b26979626237f19f2763607ea38e2e83bfc4316</id>
<content type='text'>
ext2fs: make use of the howmany() macro when available.

We have a howmany() macro in the &lt;sys/param.h&gt; header that is
convenient to re-use as it makes things easier to read.
</content>
</entry>
<entry>
<title>MFC: r298523</title>
<updated>2016-05-07T21:34:04Z</updated>
<author>
<name>Rick Macklem</name>
<email>rmacklem@FreeBSD.org</email>
</author>
<published>2016-05-07T21:34:04Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=27f55a375f5617a9c77be65074a7f9928f452e31'/>
<id>urn:sha1:27f55a375f5617a9c77be65074a7f9928f452e31</id>
<content type='text'>
Allow the NFSv4 server to reply NFSERR_WRONGSEC for the SetClientID operation.

It was reported via email that a Linux client couldn't do a Kerberized
NFS mount when only "sec=krb5" was specified for the exports. The Linux
client attempted a mount via krb5i and the server replied NFSERR_SERVERFAULT.
Although NFSERR_WRONGSEC isn't listed as an error for SetClientID, I
think it is the correct reply, so this patch enables that.
I do not know if this fixes the mount attempt, but adding "krb5i" to the
list of allowed security flavours does allow the mount to work.
</content>
</entry>
<entry>
<title>MFC: r297869</title>
<updated>2016-05-07T00:07:03Z</updated>
<author>
<name>Rick Macklem</name>
<email>rmacklem@FreeBSD.org</email>
</author>
<published>2016-05-07T00:07:03Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=247de25acbe5cb1cc7d28e81d7180ea8b32da799'/>
<id>urn:sha1:247de25acbe5cb1cc7d28e81d7180ea8b32da799</id>
<content type='text'>
If the VOP_SETATTR() call that saves the exclusive create verifier failed,
the NFS server would leave the newly created vnode locked. This could
result in a file system that would not unmount and processes wedged,
waiting for the file to be unlocked.
Since this VOP_SETATTR() never fails for most file systems, this bug
doesn't normally manifest itself. I found it during testing of an
exported GlusterFS file system, which can fail.
This patch adds the vput() and changes the error to the correct NFS one.
</content>
</entry>
</feed>
