<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/nfsd/export.c, branch linux-4.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.12.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.12.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-01-31T17:31:54Z</updated>
<entry>
<title>nfsd: opt in to labeled nfs per export</title>
<updated>2017-01-31T17:31:54Z</updated>
<author>
<name>J. Bruce Fields</name>
</author>
<published>2017-01-03T17:30:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=32ddd944a056c786f6acdd95ed29e994adc613a2'/>
<id>urn:sha1:32ddd944a056c786f6acdd95ed29e994adc613a2</id>
<content type='text'>
Currently turning on NFSv4.2 results in 4.2 clients suddenly seeing the
individual file labels as they're set on the server.  This is not what
they've previously seen, and not appropriate in may cases.  (In
particular, if clients have heterogenous security policies then one
client's labels may not even make sense to another.)  Labeled NFS should
be opted in only in those cases when the administrator knows it makes
sense.

It's helpful to be able to turn 4.2 on by default, and otherwise the
protocol upgrade seems free of regressions.  So, default labeled NFS to
off and provide an export flag to reenable it.

Users wanting labeled NFS support on an export will henceforth need to:

	- make sure 4.2 support is enabled on client and server (as
	  before), and
	- upgrade the server nfs-utils to a version supporting the new
	  "security_label" export flag.
	- set that "security_label" flag on the export.

This is commit may be seen as a regression to anyone currently depending
on security labels.  We believe those cases are currently rare.

Reported-by: tibbs@math.uh.edu
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>nfsd: allow nfsd to advertise multiple layout types</title>
<updated>2016-07-15T19:31:32Z</updated>
<author>
<name>Jeff Layton</name>
</author>
<published>2016-07-10T19:55:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8a4c3926889e7bf226e9f0254e7eface1f85f312'/>
<id>urn:sha1:8a4c3926889e7bf226e9f0254e7eface1f85f312</id>
<content type='text'>
If the underlying filesystem supports multiple layout types, then there
is little reason not to advertise that fact to clients and let them
choose what type to use.

Turn the ex_layout_type field into a bitfield. For each supported
layout type, we set a bit in that field. When the client requests a
layout, ensure that the bit for that layout type is set. When the
client requests attributes, send back a list of supported types.

Signed-off-by: Jeff Layton &lt;jlayton@poochiereds.net&gt;
Reviewed-by: Weston Andros Adamson &lt;dros@primarydata.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>nfsd: implement machine credential support for some operations</title>
<updated>2016-07-13T19:32:47Z</updated>
<author>
<name>Andrew Elble</name>
</author>
<published>2016-06-15T16:52:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ed94164398c935a42be7b129a478eb19c598b68a'/>
<id>urn:sha1:ed94164398c935a42be7b129a478eb19c598b68a</id>
<content type='text'>
This addresses the conundrum referenced in RFC5661 18.35.3,
and will allow clients to return state to the server using the
machine credentials.

The biggest part of the problem is that we need to allow the client
to send a compound op with integrity/privacy on mounts that don't
have it enabled.

Add server support for properly decoding and using spo_must_enforce
and spo_must_allow bits. Add support for machine credentials to be
used for CLOSE, OPEN_DOWNGRADE, LOCKU, DELEGRETURN,
and TEST/FREE STATEID.
Implement a check so as to not throw WRONGSEC errors when these
operations are used if integrity/privacy isn't turned on.

Without this, Linux clients with credentials that expired while holding
delegations were getting stuck in an endless loop.

Signed-off-by: Andrew Elble &lt;aweits@rit.edu&gt;
Reviewed-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>sunrpc/nfsd: Remove redundant code by exports seq_operations functions</title>
<updated>2015-08-13T12:59:02Z</updated>
<author>
<name>Kinglong Mee</name>
</author>
<published>2015-07-27T03:09:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c8c081b70cb563cc4d41ab9933fa3323c6f6ffca'/>
<id>urn:sha1:c8c081b70cb563cc4d41ab9933fa3323c6f6ffca</id>
<content type='text'>
Nfsd has implement a site of seq_operations functions as sunrpc's cache.
Just exports sunrpc's codes, and remove nfsd's redundant codes.

v8, same as v6

Signed-off-by: Kinglong Mee &lt;kinglongmee@gmail.com&gt;
Reviewed-by: NeilBrown &lt;neilb@suse.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2015-04-27T00:22:07Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2015-04-26T22:48:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9ec3a646fe09970f801ab15e0f1694060b9f19af'/>
<id>urn:sha1:9ec3a646fe09970f801ab15e0f1694060b9f19af</id>
<content type='text'>
Pull fourth vfs update from Al Viro:
 "d_inode() annotations from David Howells (sat in for-next since before
  the beginning of merge window) + four assorted fixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  RCU pathwalk breakage when running into a symlink overmounting something
  fix I_DIO_WAKEUP definition
  direct-io: only inc/dec inode-&gt;i_dio_count for file systems
  fs/9p: fix readdir()
  VFS: assorted d_backing_inode() annotations
  VFS: fs/inode.c helpers: d_inode() annotations
  VFS: fs/cachefiles: d_backing_inode() annotations
  VFS: fs library helpers: d_inode() annotations
  VFS: assorted weird filesystems: d_inode() annotations
  VFS: normal filesystems (and lustre): d_inode() annotations
  VFS: security/: d_inode() annotations
  VFS: security/: d_backing_inode() annotations
  VFS: net/: d_inode() annotations
  VFS: net/unix: d_backing_inode() annotations
  VFS: kernel/: d_inode() annotations
  VFS: audit: d_backing_inode() annotations
  VFS: Fix up some -&gt;d_inode accesses in the chelsio driver
  VFS: Cachefiles should perform fs modifications on the top layer only
  VFS: AF_UNIX sockets should call mknod on the top layer only
</content>
</entry>
<entry>
<title>VFS: normal filesystems (and lustre): d_inode() annotations</title>
<updated>2015-04-15T19:06:57Z</updated>
<author>
<name>David Howells</name>
</author>
<published>2015-03-17T22:25:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2b0143b5c986be1ce8408b3aadc4709e0a94429d'/>
<id>urn:sha1:2b0143b5c986be1ce8408b3aadc4709e0a94429d</id>
<content type='text'>
that's the bulk of filesystem drivers dealing with inodes of their own

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>nfsd: add NFSEXP_PNFS to the exflags array</title>
<updated>2015-04-03T14:00:59Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2015-04-01T08:37:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9b3075c59f858d64478f46a15daa6ecda3cf2318'/>
<id>urn:sha1:9b3075c59f858d64478f46a15daa6ecda3cf2318</id>
<content type='text'>
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>NFSD: Using path_equal() for checking two paths</title>
<updated>2015-03-31T20:46:38Z</updated>
<author>
<name>Kinglong Mee</name>
</author>
<published>2015-03-15T15:13:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b77a4b2edb29459ad039a1d8f5769bb2192acae1'/>
<id>urn:sha1:b77a4b2edb29459ad039a1d8f5769bb2192acae1</id>
<content type='text'>
Signed-off-by: Kinglong Mee &lt;kinglongmee@gmail.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
<entry>
<title>nfsd: implement pNFS operations</title>
<updated>2015-02-02T17:09:42Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2014-05-05T11:11:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9cf514ccfacb301f3b1b4509a8ce25dffad55880'/>
<id>urn:sha1:9cf514ccfacb301f3b1b4509a8ce25dffad55880</id>
<content type='text'>
Add support for the GETDEVICEINFO, LAYOUTGET, LAYOUTCOMMIT and
LAYOUTRETURN NFSv4.1 operations, as well as backing code to manage
outstanding layouts and devices.

Layout management is very straight forward, with a nfs4_layout_stateid
structure that extends nfs4_stid to manage layout stateids as the
top-level structure.  It is linked into the nfs4_file and nfs4_client
structures like the other stateids, and contains a linked list of
layouts that hang of the stateid.  The actual layout operations are
implemented in layout drivers that are not part of this commit, but
will be added later.

The worst part of this commit is the management of the pNFS device IDs,
which suffers from a specification that is not sanely implementable due
to the fact that the device-IDs are global and not bound to an export,
and have a small enough size so that we can't store the fsid portion of
a file handle, and must never be reused.  As we still do need perform all
export authentication and validation checks on a device ID passed to
GETDEVICEINFO we are caught between a rock and a hard place.  To work
around this issue we add a new hash that maps from a 64-bit integer to a
fsid so that we can look up the export to authenticate against it,
a 32-bit integer as a generation that we can bump when changing the device,
and a currently unused 32-bit integer that could be used in the future
to handle more than a single device per export.  Entries in this hash
table are never deleted as we can't reuse the ids anyway, and would have
a severe lifetime problem anyway as Linux export structures are temporary
structures that can go away under load.

Parts of the XDR data, structures and marshaling/unmarshaling code, as
well as many concepts are derived from the old pNFS server implementation
from Andy Adamson, Benny Halevy, Dean Hildebrand, Marc Eshel, Fred Isaman,
Mike Sager, Ricardo Labiaga and many others.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>nfsd: allow turning off nfsv3 readdir_plus</title>
<updated>2014-08-18T19:12:14Z</updated>
<author>
<name>Rajesh Ghanekar</name>
</author>
<published>2014-08-02T02:17:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=18c01ab30288d9d0a7d80b08b659531f37ed379d'/>
<id>urn:sha1:18c01ab30288d9d0a7d80b08b659531f37ed379d</id>
<content type='text'>
One of our customer's application only needs file names, not file
attributes. With directories having 10K+ inodes (assuming buffer cache
has directory blocks cached having file names, but inode cache is
limited and hence need eviction of older cached inodes), older inodes
are evicted periodically. So if they keep on doing readdir(2) from NSF
client on multiple directories, some directory's files are periodically
removed from inode cache and hence new readdir(2) on same directory
requires disk access to bring back inodes again to inode cache.

As READDIRPLUS request fetches attributes also, doing getattr on each
file on server, it causes unnecessary disk accesses. If READDIRPLUS on
NFS client is returned with -ENOTSUPP, NFS client uses READDIR request
which just gets the names of the files in a directory, not attributes,
hence avoiding disk accesses on server.

There's already a corresponding client-side mount option, but an export
option reduces the need for configuration across multiple clients.

This flag affects NFSv3 only.  If it turns out it's needed for NFSv4 as
well then we may have to figure out how to extend the behavior to NFSv4,
but it's not currently obvious how to do that.

Signed-off-by: Rajesh Ghanekar &lt;rajesh_ghanekar@symantec.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
</content>
</entry>
</feed>
