linux-toradex.git/fs/cachefiles/namei.c, branch v3.14.47

locks: break delegations on rename

2013-11-09T05:16:43+00:00

Cc: David Howells 
Acked-by: Jeff Layton 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Al Viro

locks: break delegations on unlink

2013-11-09T05:16:42+00:00

We need to break delegations on any operation that changes the set of
links pointing to an inode.  Start with unlink.

Such operations also hold the i_mutex on a parent directory.  Breaking a
delegation may require waiting for a timeout (by default 90 seconds) in
the case of a unresponsive NFS client.  To avoid blocking all directory
operations, we therefore drop locks before waiting for the delegation.
The logic then looks like:

	acquire locks
	...
	test for delegation; if found:
		take reference on inode
		release locks
		wait for delegation break
		drop reference on inode
		retry

It is possible this could never terminate.  (Even if we take precautions
to prevent another delegation being acquired on the same inode, we could
get a different inode on each retry.)  But this seems very unlikely.

The initial test for a delegation happens after the lock on the target
inode is acquired, but the directory inode may have been acquired
further up the call stack.  We therefore add a "struct inode **"
argument to any intervening functions, which we use to pass the inode
back up to the caller in the case it needs a delegation synchronously
broken.

Cc: David Howells 
Cc: Tyler Hicks 
Cc: Dustin Kirkland 
Acked-by: Jeff Layton 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Al Viro

CacheFiles: Don't try to dump the index key if the cookie has been cleared

2013-09-20T22:15:43+00:00

Don't try to dump the index key that distinguishes an object if netfs
data in the cookie the object refers to has been cleared (ie.  the
cookie has passed most of the way through
__fscache_relinquish_cookie()).

Since the netfs holds the index key, we can't get at it once the ->def
and ->netfs_data pointers have been cleared - and a NULL pointer
exception will ensue, usually just after a:

	CacheFiles: Error: Unexpected object collision

error is reported.

Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds

FS-Cache: Fix object state machine to have separate work and wait states

2013-06-19T13:16:47+00:00

Fix object state machine to have separate work and wait states as that makes
it easier to envision.

There are now three kinds of state:

 (1) Work state.  This is an execution state.  No event processing is performed
     by a work state.  The function attached to a work state returns a pointer
     indicating the next state to which the OSM should transition.  Returning
     NO_TRANSIT repeats the current state, but goes back to the scheduler
     first.

 (2) Wait state.  This is an event processing state.  No execution is
     performed by a wait state.  Wait states are just tables of "if event X
     occurs, clear it and transition to state Y".  The dispatcher returns to
     the scheduler if none of the events in which the wait state has an
     interest are currently pending.

 (3) Out-of-band state.  This is a special work state.  Transitions to normal
     states can be overridden when an unexpected event occurs (eg. I/O error).
     Instead the dispatcher disables and clears the OOB event and transits to
     the specified work state.  This then acts as an ordinary work state,
     though object->state points to the overridden destination.  Returning
     NO_TRANSIT resumes the overridden transition.

In addition, the states have names in their definitions, so there's no need for
tables of state names.  Further, the EV_REQUEUE event is no longer necessary as
that is automatic for work states.

Since the states are now separate structs rather than values in an enum, it's
not possible to use comparisons other than (non-)equality between them, so use
some object->flags to indicate what phase an object is in.

The EV_RELEASE, EV_RETIRE and EV_WITHDRAW events have been squished into one
(EV_KILL).  An object flag now carries the information about retirement.

Similarly, the RELEASING, RECYCLING and WITHDRAWING states have been merged
into an KILL_OBJECT state and additional states have been added for handling
waiting dependent objects (JUMPSTART_DEPS and KILL_DEPENDENTS).

A state has also been added for synchronising with parent object initialisation
(WAIT_FOR_PARENT) and another for initiating look up (PARENT_READY).

Signed-off-by: David Howells 
Tested-By: Milosz Tanski 
Acked-by: Jeff Layton

FS-Cache: Wrap checks on object state

2013-06-19T13:16:47+00:00

Wrap checks on object state (mostly outside of fs/fscache/object.c) with
inline functions so that the mechanism can be replaced.

Some of the state checks within object.c are left as-is as they will be
replaced.

Signed-off-by: David Howells 
Tested-By: Milosz Tanski 
Acked-by: Jeff Layton

CacheFiles: name i_mutex lock class explicitly

2013-06-19T13:16:47+00:00

Just some cleanup.

(And note the caller of this function may, for example, call vfs_unlink
on a child, so the "1" (I_MUTEX_PARENT) really was what was intended
here.)

Signed-off-by: J. Bruce Fields 
Signed-off-by: David Howells 
Tested-By: Milosz Tanski 
Acked-by: Jeff Layton

FS-Cache: Don't mask off the object event mask when printing it

2012-12-20T22:08:53+00:00

Don't mask off the object event mask when printing it.  That way it can be seen
if threre are bits set that shouldn't be.

Signed-off-by: David Howells

don't pass nameidata * to vfs_create()

2012-07-14T12:34:50+00:00

all we want is a boolean flag, same as the method gets now

Signed-off-by: Al Viro

switch touch_atime to struct path

2012-03-21T01:29:41+00:00

Signed-off-by: Al Viro

CacheFiles: Add calls to path-based security hooks

2011-01-23T23:49:45+00:00

Add calls to path-based security hooks into CacheFiles as, unlike inode-based
security, these aren't implicit in the vfs_mkdir() and similar calls.

Reported-by: Tetsuo Handa 
Signed-off-by: David Howells 
Signed-off-by: James Morris