Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

readlink:	no

follow_link:	no

put_link:	no

truncate:	yes		(see below)

setattr:	yes

permission:	no (may not block if called in rcu-walk mode)

get_acl:	no

	Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on

victim.

	cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.

	->truncate() is never called directly - it's a callback, not a

method. It's called by vmtruncate() - deprecated library function used by

->setattr(). Locking information above applies to that call (i.e. is

inherited from ->setattr() - vmtruncate() is used when ATTR_SIZE had been

passed).

See Documentation/filesystems/directory-locking for more detailed discussion

of the locking scheme for directory operations.

     obtained by calling object->cookie->def->get_aux()/get_attr().

 (*) Invalidate data object [mandatory]:

	int (*invalidate_object)(struct fscache_operation *op)

     This is called to invalidate a data object (as pointed to by op->object).

     All the data stored for this object should be discarded and an

     attr_changed operation should be performed.  The caller will follow up

     with an object update operation.

     fscache_op_complete() must be called on op before returning.

 (*) Discard object [mandatory]:

	void (*drop_object)(struct fscache_object *object)

     If an I/O error occurs, fscache_io_error() should be called and -ENOBUFS

     returned if possible or fscache_end_io() called with a suitable error

     code..

     code.

     fscache_put_retrieval() should be called after a page or pages are dealt

     with.  This will complete the operation when all pages are dealt with.

 (*) Request pages be read from cache [mandatory]:

     error value should be 0 if successful and an error otherwise.

 (*) Record that one or more pages being retrieved or allocated have been dealt

     with:

	void fscache_retrieval_complete(struct fscache_retrieval *op,

					int n_pages);

     This is called to record the fact that one or more pages have been dealt

     with and are no longer the concern of this operation.  When the number of

     pages remaining in the operation reaches 0, the operation will be

     completed.

 (*) Record operation completion:

	void fscache_op_complete(struct fscache_operation *op);

     This is called to record the completion of an operation.  This deducts

     this operation from the parent object's run state, potentially permitting

     one or more pending operations to start running.

 (*) Set highest store limit:

	void fscache_set_store_limit(struct fscache_object *object,

	(12) Index and data file update

	(13) Miscellaneous cookie operations

	(14) Cookie unregistration

	(15) Index and data file invalidation

	(16) FS-Cache specific page flags.

	(15) Index invalidation

	(16) Data file invalidation

	(17) FS-Cache specific page flags.

=============================

first.

================================

INDEX AND DATA FILE INVALIDATION

================================

==================

INDEX INVALIDATION

==================

There is no direct way to invalidate an index subtree.  To do this, the caller

should relinquish and retire the cookie they have, and then acquire a new one.

======================

DATA FILE INVALIDATION

======================

Sometimes it will be necessary to invalidate an object that contains data.

Typically this will be necessary when the server tells the netfs of a foreign

change - at which point the netfs has to throw away all the state it had for an

inode and reload from the server.

To indicate that a cache object should be invalidated, the following function

can be called:

	void fscache_invalidate(struct fscache_cookie *cookie);

This can be called with spinlocks held as it defers the work to a thread pool.

All extant storage, retrieval and attribute change ops at this point are

cancelled and discarded.  Some future operations will be rejected until the

cache has had a chance to insert a barrier in the operations queue.  After

that, operations will be queued again behind the invalidation operation.

The invalidation operation will perform an attribute change operation and an

auxiliary data update operation as it is very likely these will have changed.

Using the following function, the netfs can wait for the invalidation operation

to have reached a point at which it can start submitting ordinary operations

once again:

There is no direct way to invalidate an index subtree or a data file.  To do

this, the caller should relinquish and retire the cookie they have, and then

acquire a new one.

	void fscache_wait_on_invalidate(struct fscache_cookie *cookie);

===========================

     The normal running state.  In this state, requests the netfs makes will be

     passed on to the cache.

 (6) State FSCACHE_OBJECT_UPDATING.

 (6) State FSCACHE_OBJECT_INVALIDATING.

     The object is undergoing invalidation.  When the state comes here, it

     discards all pending read, write and attribute change operations as it is

     going to clear out the cache entirely and reinitialise it.  It will then

     continue to the FSCACHE_OBJECT_UPDATING state.

 (7) State FSCACHE_OBJECT_UPDATING.

     The state machine comes here to update the object in the cache from the

     netfs's records.  This involves updating the auxiliary data that is used

And there are terminal states in which an object cleans itself up, deallocates

memory and potentially deletes stuff from disk:

 (7) State FSCACHE_OBJECT_LC_DYING.

 (8) State FSCACHE_OBJECT_LC_DYING.

     The object comes here if it is dying because of a lookup or creation

     error.  This would be due to a disk error or system error of some sort.

     Temporary data is cleaned up, and the parent is released.

 (8) State FSCACHE_OBJECT_DYING.

 (9) State FSCACHE_OBJECT_DYING.

     The object comes here if it is dying due to an error, because its parent

     cookie has been relinquished by the netfs or because the cache is being

     can destroy themselves.  This object waits for all its children to go away

     before advancing to the next state.

 (9) State FSCACHE_OBJECT_ABORT_INIT.

(10) State FSCACHE_OBJECT_ABORT_INIT.

     The object comes to this state if it was waiting on its parent in

     FSCACHE_OBJECT_INIT, but its parent died.  The object will destroy itself

     so that the parent may proceed from the FSCACHE_OBJECT_DYING state.

(10) State FSCACHE_OBJECT_RELEASING.

(11) State FSCACHE_OBJECT_RECYCLING.

(11) State FSCACHE_OBJECT_RELEASING.

(12) State FSCACHE_OBJECT_RECYCLING.

     The object comes to one of these two states when dying once it is rid of

     all its children, if it is dying because the netfs relinquished its

     cookie.  In the first state, the cached data is expected to persist, and

     in the second it will be deleted.

(12) State FSCACHE_OBJECT_WITHDRAWING.

(13) State FSCACHE_OBJECT_WITHDRAWING.

     The object transits to this state if the cache decides it wants to

     withdraw the object from service, perhaps to make space, but also due to

     error or just because the whole cache is being withdrawn.

(13) State FSCACHE_OBJECT_DEAD.

(14) State FSCACHE_OBJECT_DEAD.

     The object transits to this state when the in-memory object record is

     ready to be deleted.  The object processor shouldn't ever see an object in

     necessary (the object might have died whilst the thread was waiting).

     When it has finished doing its processing, it should call

     fscache_put_operation() on it.

     fscache_op_complete() and fscache_put_operation() on it.

 (4) The operation holds an effective lock upon the object, preventing other

     exclusive ops conflicting until it is released.  The operation can be