Provide an add_wait_queue_tail() function to add a waiter to the back of a wait queue instead of the front. Signed-off-by: David Howells <dhowells@redhat.com> --- include/linux/pagemap.h | 7 +++++-- include/linux/wait.h | 1 + kernel/wait.c | 18 ++++++++++++++++++ mm/filemap.c | 2 +- 4 files changed, 25 insertions(+), 3 deletions(-) diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h index c5df3ae..ad9484f 100644 --- ...

nfs_readpage_async() needs to be non-static so that it can be used as a fallback for the local on-disk caching should an EIO crop up when reading the cache. Signed-off-by: David Howells <dhowells@redhat.com> --- fs/nfs/read.c | 4 ++-- include/linux/nfs_fs.h | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/nfs/read.c b/fs/nfs/read.c index 3d7d963..725a5a2 100644 --- a/fs/nfs/read.c +++ b/fs/nfs/read.c @@ -114,8 +114,8 @@ static void ...

Define and create inode-level cache data storage objects (as managed by nfs_inode structs). Each inode-level object is created in a superblock-level index object and is itself a data storage object into which pages from the inode are stored. The inode object key is the NFS file handle for the inode. The inode object is given coherency data to carry in the auxiliary data permitted by the cache. This is a sequence made up of: (1) i_mtime from the NFS inode. (2) i_ctime from the NFS ...

Permit local filesystem caching to be enabled for NFS in the kernel configuration. Signed-off-by: David Howells <dhowells@redhat.com> --- fs/Kconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/fs/Kconfig b/fs/Kconfig index c42ec50..fa8e978 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -1644,6 +1644,14 @@ config NFS_V4 If unsure, say N. +config NFS_FSCACHE + bool "Provide NFS client caching support (EXPERIMENTAL)" + depends on ...

Add a function to install a monitor on the page lock waitqueue for a particular page, thus allowing the page being unlocked to be detected. This is used by CacheFiles to detect read completion on a page in the backing filesystem so that it can then copy the data to the waiting netfs page. Signed-off-by: David Howells <dhowells@redhat.com> --- include/linux/pagemap.h | 5 +++++ mm/filemap.c | 18 ++++++++++++++++++ 2 files changed, 23 insertions(+), 0 deletions(-) diff ...

Invalidate the FsCache page flags on the pages belonging to an inode when the cache backing that NFS inode is removed. This allows a live cache to be withdrawn. Signed-off-by: David Howells <dhowells@redhat.com> --- fs/nfs/fscache-index.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 40 insertions(+), 0 deletions(-) diff --git a/fs/nfs/fscache-index.c b/fs/nfs/fscache-index.c index c3c63fa..eec8e7e 100644 --- a/fs/nfs/fscache-index.c +++ ...

Define and create superblock-level cache index objects (as managed by nfs_server structs). Each superblock object is created in a server level index object and is itself an index into which inode-level objects are inserted. Ideally there would be one superblock-level object per server, and the former would be folded into the latter; however, since the "nosharecache" option exists this isn't possible. The superblock object key is a sequence consisting of: (1) Certain superblock ...

Add read context retention so that FS-Cache can call back into NFS when a read operation on the cache fails EIO rather than reading data. This permits NFS to then fetch the data from the server instead using the appropriate security context. Signed-off-by: David Howells <dhowells@redhat.com> --- fs/nfs/fscache-index.c | 26 ++++++++++++++++++++++++++ 1 files changed, 26 insertions(+), 0 deletions(-) diff --git a/fs/nfs/fscache-index.c b/fs/nfs/fscache-index.c index eec8e7e..af9f06b ...

Allow kernel services to override LSM settings appropriate to the actions performed by a task by duplicating a security record, modifying it and then using task_struct::act_as to point to it when performing operations on behalf of a task. This is used, for example, by CacheFiles which has to transparently access the cache on behalf of a process that thinks it is doing, say, NFS accesses with a potentially inappropriate (with respect to accessing the cache) set of security data. This patch ...

Change current->fs[ug]id to current_fs[ug]id() so that fsgid and fsuid can be separated from the task_struct. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> --- arch/ia64/kernel/perfmon.c | 4 ++-- arch/powerpc/platforms/cell/spufs/inode.c | 4 ++-- drivers/isdn/capi/capifs.c | 4 ++-- drivers/usb/core/inode.c | 4 ++-- fs/9p/fid.c | 2 +- ...

Bind data storage objects in the local cache to NFS inodes. Signed-off-by: David Howells <dhowells@redhat.com> --- fs/nfs/fscache.c | 174 ++++++++++++++++++++++++++++++++++++++++++++++++ fs/nfs/fscache.h | 15 ++++ fs/nfs/inode.c | 39 +++++++++-- include/linux/nfs_fs.h | 11 +++ 4 files changed, 233 insertions(+), 6 deletions(-) diff --git a/fs/nfs/fscache.c b/fs/nfs/fscache.c index cbd09f0..839a5ea 100644 --- a/fs/nfs/fscache.c +++ b/fs/nfs/fscache.c @@ ...

The attached patch causes read_cache_pages() to release page-private data on a page for which add_to_page_cache() fails or the filler function fails. This permits pages with caching references associated with them to be cleaned up. The invalidatepage() address space op is called (indirectly) to do the honours. Signed-off-by: David Howells <dhowells@redhat.com> --- mm/readahead.c | 39 +++++++++++++++++++++++++++++++++++++-- 1 files changed, 37 insertions(+), 2 deletions(-) diff ...

Add FS-Cache option bit to nfs_server struct. This is set to indicate local on-disk caching is enabled for a particular superblock. Also add debug bit for local caching operations. Signed-off-by: David Howells <dhowells@redhat.com> --- include/linux/nfs_fs.h | 1 + include/linux/nfs_fs_sb.h | 2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h index a69ba80..14894c9 100644 --- a/include/linux/nfs_fs.h +++ ...

Make NFSD work with detached security, using the patches that excise the security information from task_struct to struct task_security as a base. Each time NFSD wants a new security descriptor (to do NFS4 recovery or just to do NFS operations), a task_security record is derived from NFSD's *objective* security, modified and then applied as the *subjective* security. This means (a) the changes are not visible to anyone looking at NFSD through /proc, (b) there is no leakage between two ...

Add a 'kernel_service' object class to SELinux and give this object class two access vectors: 'use_as_override' and 'create_files_as'. The first vector is used to grant a process the right to nominate an alternate process security ID for the kernel to use as an override for the SELinux subjective security when accessing stuff on behalf of another process. For example, CacheFiles when accessing the cache on behalf on a process accessing an NFS file needs to use a subjective security ID ...

Add NFS mount options to allow the local caching support to be enabled. The attached patch makes it possible for the NFS filesystem to be told to make use of the network filesystem local caching service (FS-Cache). To be able to use this, a recent nfsutils package is required. There are three variant NFS mount options that can be added to a mount command to control caching for a mount. Only the last one specified takes effect: (*) Adding "fsc" will request caching. (*) Adding ...

Read pages from an FS-Cache data storage object representing an inode into an NFS inode. Signed-off-by: David Howells <dhowells@redhat.com> --- fs/nfs/fscache.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/nfs/fscache.h | 47 +++++++++++++++++++++++ fs/nfs/read.c | 18 +++++++++ 3 files changed, 176 insertions(+), 1 deletions(-) diff --git a/fs/nfs/fscache.c b/fs/nfs/fscache.c index 4c0a8e2..7551c3b 100644 --- a/fs/nfs/fscache.c +++ b/fs/nfs/fscache.c @@ ...

Ah...That seems a wrong, should returns EIO in this case. The fs has a marked the blocks for fs metadata as "used" on bitmaps at the mkfs time, so if we are able to allocate a new block(which checks Ur..If the allocated data blocks overlaps the fs metadata blocks, that means fs is corrupted: could be a bad block group descriptor, or a bad bitmap. In any case it should mark fs error and should not continue allocation in next group. What does fsck reports? Mingming --

Are these patches in the upstream kernel yet? I'd submitted fixes like this for 2.4 kernels, but it never seems to make it into the kernel for 2.6... Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. --

There is also a similar complaint from users who format ext3 directly on a disk/LUN without a partition table, because the partition table offset negatively impacts the performance of the filesystem (causing unaligned Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. --

Then use the existing side-band protocol and ignore the NFSv4 spec And changing the name and minor details is exactly what Casey requested. --

Trond can, and I'm completely confident he will, correct me if I'm wrong, but interoperability seems to require that you can't assume the perfect administration scenario. If you could, the name/value pair scheme would be perfectly viable, but Trond has very clearly explained why it is not reasonable to assume that. But, for early going you may get away with telling people that the configuration has to be identical. They won't listen and will mess it up, but you will probably get away with ...

Possibly I'm missing something, but if I'm implementing a security module that has any security attribute at all, e.g. capability module with security.capability, and I see a hook called "get_security_blob" or "get_security_attr" or the like, I'll implement that hook and return my attribute there. Which in turn will _break_ the labeled NFS functionality because it is expecting a MAC label specifically. The whole point here is that we do not want modules like capability to return their ...

With the SGI supplied reference implementation it ought to be a small matter of work to write an RFC. If the information weren't SGI proprietary I could even tell you how long it ought to take a junior engineer in Melbourne to write. The fact that there is currently no RFC does not mean that there cannot be a RFC, only that no one has written (or published) one yet. Casey Schaufler casey@schaufler-ca.com --

Actually we can expect interoperability with SELinux on both ends. With policy being the same on both ends it is completely valid to export a secctx which is a user readable text representation of a label and be able to use it on another selinux machine with the same policy. If I have a RHEL4 and RHEL 5 box with different policies then it is the job of the translation daemon to say I've gotten this label from this doi do I have a mapping for it. If yes translate it into my doi. If not ...

Hehe I didn't miss it but I don't drink (A coke would be greatly --

It assumes more than that. It assumes that a secctx will be interpreted exactly the same way on both the client and the server. On an old style MLS machine, where the label was encoded in a data structure, this was usually a reasonable assumption, but even then not always. Given that there is no reason to expect that the policy on the server will match that on the client it looks to me like you've got a day one exposure. It doesn't matter that the LSM is the same on both ends, that's one of ...

An xattr protocol is overkill for conveying a MAC label over the network, and would still not provide the required semantics. Please see prior discussion on this e.g. http://marc.info/?l=linux-kernel&m=120424789929258&w=2 Note that RAs are already used to convey ACLs and all other system-managed metatdata. i.e. an extensible, appropriate infrastructure already exists in the NFSv4 protocol, and has been used successfully for similar purposes. We do not need to add a new, generalized ...

Most of the original SGI XFS team went to NetApp. The engineer who developed the side-band xattr protocol (last I heard he was a real estate speculator in Florida) spent lots of time with them. Easier may be pragmatic, but that does not make it right. I suggest, that in my opinion (there, is that sufficiently non-confrontational?) that Linux and the LSM are much better served by a general xattr protocol than by adding a single Well, that's why I keep suggesting ...

It's as unstructured as the named attributes already in. Or file data for that matter. --

The reason we are trying to go through the standards process in the first place is that there is a desire to use SELinux with large netapp storage boxes. I don't believe that netapp supports the existing side-band protocol for NFSv4 and the impression I got was that they we were going to have an incredibly hard time convincing them of putting anything in that isn't part of the standard. It seems that adding one recommended attribute which is described in a 3 page internet draft(Most of which ...

I completely disagree here. The Linux development model isn't to code the entire thing throw it over a wall and then deal with the collateral damage. This first version assumes a heterogenous environment and from what we see so far that seems to be the common usecase for this technology. A prototype implementation is already done for label translations and it does need to be outlined in the RFC (Which I've already started doing). However it is not necessary for an initial release. The ...

What part of 'interoperability' don't you get here? There is no room for extensions that allow clients+servers to establish arbitrary private protocols. --

The problem isn't that of supporting the naive user xattr model: we can almost do that within the existing 'named attribute' model of NFSv4. The problem is that of supporting the arbitrary "security metadata" that are allowed to have side-effects on the system behaviour, and that we appear to have thought was a good idea to overload onto the xattr interface. In the case of maclabels, where the "side-effect" is to describe and enable extra access control rules, then you have the potential ...

That is simply because I don't care for your design and implementation choices, I think they're a bad way to go, I've suggested what I think you should do, and I'm sorry that that comes off as confrontational but that does not change what I see as flaws in your approach. I understand what you're trying to do and I think You're very possibly right. I am not argueing from what's right for Smack, I am argueing from what's right for the LSM. Smack is a label based MAC LSM, like SELinux. I ...

There are several things here. I've spoken to several people about this and the belief I've gotten from most of them is that a recommended attribute is how this is to be transported. The NFSv4 spec people will probably say that if you want xattr like functionality for NFSv4 use named attributes. For us this is not an option since we require semantics to label on create/open and the only way we can do this is by adding a recommended attribute. The create/open calls in NFSv4 takes a list of ...

Phew, he missed that one. Casey Schaufler casey@schaufler-ca.com --

Now this is were I always get confused. I sounds like you're saying that a name/value pair is insufficiently structured for Sorry, but as far as I'm concerned you just threw a bunny under the train for no apparent reason. What have ioctls got to do with anything? Casey Schaufler casey@schaufler-ca.com --

Two of the main reasons for NFS's success as a protocol are the facts that it is (more or less) standardized, while remaining (again more or less) back-end agnostic. I can take pretty much any client from any one vendor and any server from any other vendor, and make them work together. The reason why this works is mainly because the protocol has built upon a consensus assumption of POSIX filesystem semantics on the servers (hence, BTW, the pain when the IETF requested that we ...

I am adding a new hook to provide the functionality that Casey suggested. It takes an inode, context, contextlen and sets it in the LSM. The question is that since there is a need to be able to set in-core, on-disk, or both; should these be two separate hooks? or should we make the hook take a flag that has in-core, and ondisk and it can be masked together for both? Dave --

As I've told you several times before: we're _NOT_ putting private ioctl^Hxattrs onto the wire. If the protocol can't be described in an RFC, then it isn't going in no matter what expletive you choose to use... --

You can become root in the new container. Your capabilities are meaningful only to targets (users, files) which exist in the user namespace in which you are root. It becomes more precise than the --

I'm afraid, that I'm just starting a new thread of discussion in a So do you mean that I can become a root, by calling clone()? Thanks, Pavel --

It appears I could do this with the generic netlink subsystem. And, will still be in the netlink implementation and will still return Agian, will still be in the netlink implementation. Also, still in the netlink implementation, with a comment a bit more That's not going to change. There's nothing new here at all. This is merely an re-implementation of the existing autofs ioctl I'll add a document describing this, as previously agreed. I haven't had any problems with this ...