)]}' { "log": [ { "commit": "fee096deb4f33897937b974cb2c5168bab7935be", "tree": "c86e5ed5b3435ff0f0266f343b19f8cc7be63340", "parents": [ "d0e27b7808dc667f3015be0b6888f6d680e222c8" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:12:05 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:12:05 2009 +0000" }, "message": "CacheFiles: Catch an overly long wait for an old active object\n\nCatch an overly long wait for an old, dying active object when we want to\nreplace it with a new one. The probability is that all the slow-work threads\nare hogged, and the delete can\u0027t get a look in.\n\nWhat we do instead is:\n\n (1) if there\u0027s nothing in the slow work queue, we sleep until either the dying\n object has finished dying or there is something in the slow work queue\n behind which we can queue our object.\n\n (2) if there is something in the slow work queue, we return ETIMEDOUT to\n fscache_lookup_object(), which then puts us back on the slow work queue,\n presumably behind the deletion that we\u0027re blocked by. We are then\n deferred for a while until we work our way back through the queue -\n without blocking a slow-work thread unnecessarily.\n\nA backtrace similar to the following may appear in the log without this patch:\n\n\tINFO: task kslowd004:5711 blocked for more than 120 seconds.\n\t\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n\tkslowd004 D 0000000000000000 0 5711 2 0x00000080\n\t ffff88000340bb80 0000000000000046 ffff88002550d000 0000000000000000\n\t ffff88002550d000 0000000000000007 ffff88000340bfd8 ffff88002550d2a8\n\t 000000000000ddf0 00000000000118c0 00000000000118c0 ffff88002550d2a8\n\tCall Trace:\n\t [\u003cffffffff81058e21\u003e] ? trace_hardirqs_on+0xd/0xf\n\t [\u003cffffffffa011c4d8\u003e] ? cachefiles_wait_bit+0x0/0xd [cachefiles]\n\t [\u003cffffffffa011c4e1\u003e] cachefiles_wait_bit+0x9/0xd [cachefiles]\n\t [\u003cffffffff81353153\u003e] __wait_on_bit+0x43/0x76\n\t [\u003cffffffff8111ae39\u003e] ? ext3_xattr_get+0x1ec/0x270\n\t [\u003cffffffff813531ef\u003e] out_of_line_wait_on_bit+0x69/0x74\n\t [\u003cffffffffa011c4d8\u003e] ? cachefiles_wait_bit+0x0/0xd [cachefiles]\n\t [\u003cffffffff8104c125\u003e] ? wake_bit_function+0x0/0x2e\n\t [\u003cffffffffa011bc79\u003e] cachefiles_mark_object_active+0x203/0x23b [cachefiles]\n\t [\u003cffffffffa011c209\u003e] cachefiles_walk_to_object+0x558/0x827 [cachefiles]\n\t [\u003cffffffffa011a429\u003e] cachefiles_lookup_object+0xac/0x12a [cachefiles]\n\t [\u003cffffffffa00aa1e9\u003e] fscache_lookup_object+0x1c7/0x214 [fscache]\n\t [\u003cffffffffa00aafc5\u003e] fscache_object_state_machine+0xa5/0x52d [fscache]\n\t [\u003cffffffffa00ab4ac\u003e] fscache_object_slow_work_execute+0x5f/0xa0 [fscache]\n\t [\u003cffffffff81082093\u003e] slow_work_execute+0x18f/0x2d1\n\t [\u003cffffffff8108239a\u003e] slow_work_thread+0x1c5/0x308\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffff810821d5\u003e] ? slow_work_thread+0x0/0x308\n\t [\u003cffffffff8104be91\u003e] kthread+0x7a/0x82\n\t [\u003cffffffff8100beda\u003e] child_rip+0xa/0x20\n\t [\u003cffffffff8100b87c\u003e] ? restore_args+0x0/0x30\n\t [\u003cffffffff8104be17\u003e] ? kthread+0x0/0x82\n\t [\u003cffffffff8100bed0\u003e] ? child_rip+0x0/0x20\n\t1 lock held by kslowd004/5711:\n\t #0: (\u0026sb-\u003es_type-\u003ei_mutex_key#7/1){+.+.+.}, at: [\u003cffffffffa011be64\u003e] cachefiles_walk_to_object+0x1b3/0x827 [cachefiles]\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "868411be3f445a83fafbd734f3e426400138add5", "tree": "5eb855730adfa903abae29a9a20a78f1cfe597af", "parents": [ "60d543ca724be155c2b6166e36a00c80b21bd810" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:48 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:48 2009 +0000" }, "message": "FS-Cache: Actually requeue an object when requested\n\nFS-Cache objects have an FSCACHE_OBJECT_EV_REQUEUE event that can theoretically\nbe raised to ask the state machine to requeue the object for further processing\nbefore the work function returns to the slow-work facility.\n\nHowever, fscache_object_work_execute() was clearing that bit before checking\nthe event mask to see whether the object has any pending events that require it\nto be requeued immediately.\n\nInstead, the bit should be cleared after the check and enqueue.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "60d543ca724be155c2b6166e36a00c80b21bd810", "tree": "90ec6edd77ddb7666dbf7069aa2e001f155cea49", "parents": [ "d461d26dde901b0523c46b0317e7fccf574a3933" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:45 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:45 2009 +0000" }, "message": "FS-Cache: Start processing an object\u0027s operations on that object\u0027s death\n\nStart processing an object\u0027s operations when that object moves into the DYING\nstate as the object cannot be destroyed until all its outstanding operations\nhave completed.\n\nFurthermore, make sure that read and allocation operations handle being woken\nup on a dead object. Such events are recorded in the Allocs.abt and\nRetrvls.abt statistics as viewable through /proc/fs/fscache/stats.\n\nThe code for waiting for object activation for the read and allocation\noperations is also extracted into its own function as it is much the same in\nall cases, differing only in the stats incremented.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "d461d26dde901b0523c46b0317e7fccf574a3933", "tree": "abaac0f4259ec9458fa40be85ed7a3d4f8982cc5", "parents": [ "2175bb06dc6cf2af9c098a1770561f9e63edae4e" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:41 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:41 2009 +0000" }, "message": "FS-Cache: Make sure FSCACHE_COOKIE_LOOKING_UP cleared on lookup failure\n\nWe must make sure that FSCACHE_COOKIE_LOOKING_UP is cleared on lookup failure\n(if an object reaches the LC_DYING state), and we should clear it before\nclearing FSCACHE_COOKIE_CREATING.\n\nIf this doesn\u0027t happen then fscache_wait_for_deferred_lookup() may hold\nallocation and retrieval operations indefinitely until they\u0027re interrupted by\nsignals - which in turn pins the dying object until they go away.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "6897e3df8fc37bd4a58bbcdef8306da7fc175584", "tree": "e826cd96f0395775d4fea113dc283ae0282f0384", "parents": [ "5753c441889253e4323eee85f791a1d64cf08196" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:22 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:22 2009 +0000" }, "message": "FS-Cache: The object-available state can\u0027t rely on the cookie to be available\n\nThe object-available state in the object processing state machine (as\nprocessed by fscache_object_available()) can\u0027t rely on the cookie to be\navailable because the FSCACHE_COOKIE_CREATING bit may have been cleared by\nfscache_obtained_object() prior to the object being put into the\nFSCACHE_OBJECT_AVAILABLE state.\n\nClearing the FSCACHE_COOKIE_CREATING bit on a cookie permits\n__fscache_relinquish_cookie() to proceed and detach the cookie from the\nobject.\n\nTo deal with this, we don\u0027t dereference object-\u003ecookie in\nfscache_object_available() if the object has already been detached.\n\nIn addition, a couple of assertions are added into fscache_drop_object() to\nmake sure the object is unbound from the cookie before it gets there.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "52bd75fdb135d6133d878ae60c6e7e3f4ebc1cfc", "tree": "4fad4fa37ce533c520a4575e5b7df90e19c6a666", "parents": [ "4fbf4291aa15926cd4fdca0ffe9122e89d0459db" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:08 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:08 2009 +0000" }, "message": "FS-Cache: Add counters for entry/exit to/from cache operation functions\n\nCount entries to and exits from cache operation table functions. Maintain\nthese as a single counter that\u0027s added to or removed from as appropriate.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "4fbf4291aa15926cd4fdca0ffe9122e89d0459db", "tree": "ec2195c39ef8117acea598af4a5c20c77f67aa0b", "parents": [ "440f0affe247e9990c8f8778f1861da4fd7d5e50" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:04 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:04 2009 +0000" }, "message": "FS-Cache: Allow the current state of all objects to be dumped\n\nAllow the current state of all fscache objects to be dumped by doing:\n\n\tcat /proc/fs/fscache/objects\n\nBy default, all objects and all fields will be shown. This can be restricted\nby adding a suitable key to one of the caller\u0027s keyrings (such as the session\nkeyring):\n\n\tkeyctl add user fscache:objlist \"\u003crestrictions\u003e\" @s\n\nThe \u003crestrictions\u003e are:\n\n\tK\tShow hexdump of object key (don\u0027t show if not given)\n\tA\tShow hexdump of object aux data (don\u0027t show if not given)\n\nAnd paired restrictions:\n\n\tC\tShow objects that have a cookie\n\tc\tShow objects that don\u0027t have a cookie\n\tB\tShow objects that are busy\n\tb\tShow objects that aren\u0027t busy\n\tW\tShow objects that have pending writes\n\tw\tShow objects that don\u0027t have pending writes\n\tR\tShow objects that have outstanding reads\n\tr\tShow objects that don\u0027t have outstanding reads\n\tS\tShow objects that have slow work queued\n\ts\tShow objects that don\u0027t have slow work queued\n\nIf neither side of a restriction pair is given, then both are implied. For\nexample:\n\n\tkeyctl add user fscache:objlist KB @s\n\nshows objects that are busy, and lists their object keys, but does not dump\ntheir auxiliary data. It also implies \"CcWwRrSs\", but as \u0027B\u0027 is given, \u0027b\u0027 is\nnot implied.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "440f0affe247e9990c8f8778f1861da4fd7d5e50", "tree": "0012732ac8af0245005403d9a3b0a2b1209edf32", "parents": [ "3bde31a4ac225cb5805be02eff6eaaf7e0766ccd" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:01 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:01 2009 +0000" }, "message": "FS-Cache: Annotate slow-work runqueue proc lines for FS-Cache work items\n\nAnnotate slow-work runqueue proc lines for FS-Cache work items. Objects\ninclude the object ID and the state. Operations include the object ID, the\noperation ID and the operation type and state.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "3d7a641e544e428191667e8b1f83f96fa46dbd65", "tree": "172aa672eca96b94f5531885b82abb82b43c7d8a", "parents": [ "66b00a7c93ec782d118d2c03bd599cfd041e80a1" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:10:23 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:10:23 2009 +0000" }, "message": "SLOW_WORK: Wait for outstanding work items belonging to a module to clear\n\nWait for outstanding slow work items belonging to a module to clear when\nunregistering that module as a user of the facility. This prevents the put_ref\ncode of a work item from being taken away before it returns.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "36c9559022850f919269564a74bf17fdabf4bb30", "tree": "f163afcf8f8a9eb1a5d63fd6198fcb3e29564493", "parents": [ "2868cbea72dc89ae0eb17693596b1dedaafff1c5" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:38 2009 +0100" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:38 2009 +0100" }, "message": "FS-Cache: Object management state machine\n\nImplement the cache object management state machine.\n\nThe following documentation is added to illuminate the working of this state\nmachine. It will also be added as:\n\n\tDocumentation/filesystems/caching/object.txt\n\n\t \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\t IN-KERNEL CACHE OBJECT REPRESENTATION AND MANAGEMENT\n\t \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nREPRESENTATION\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFS-Cache maintains an in-kernel representation of each object that a netfs is\ncurrently interested in. Such objects are represented by the fscache_cookie\nstruct and are referred to as cookies.\n\nFS-Cache also maintains a separate in-kernel representation of the objects that\na cache backend is currently actively caching. Such objects are represented by\nthe fscache_object struct. The cache backends allocate these upon request, and\nare expected to embed them in their own representations. These are referred to\nas objects.\n\nThere is a 1:N relationship between cookies and objects. A cookie may be\nrepresented by multiple objects - an index may exist in more than one cache -\nor even by no objects (it may not be cached).\n\nFurthermore, both cookies and objects are hierarchical. The two hierarchies\ncorrespond, but the cookies tree is a superset of the union of the object trees\nof multiple caches:\n\n\t NETFS INDEX TREE : CACHE 1 : CACHE 2\n\t : :\n\t : +-----------+ :\n\t +-----------\u003e| IObject | :\n\t +-----------+ | : +-----------+ :\n\t | ICookie |-------+ : | :\n\t +-----------+ | : | : +-----------+\n\t | +------------------------------\u003e| IObject |\n\t | : | : +-----------+\n\t | : V : |\n\t | : +-----------+ : |\n\t V +-----------\u003e| IObject | : |\n\t +-----------+ | : +-----------+ : |\n\t | ICookie |-------+ : | : V\n\t +-----------+ | : | : +-----------+\n\t | +------------------------------\u003e| IObject |\n\t +-----+-----+ : | : +-----------+\n\t | | : | : |\n\t V | : V : |\n\t+-----------+ | : +-----------+ : |\n\t| ICookie |-------------------------\u003e| IObject | : |\n\t+-----------+ | : +-----------+ : |\n\t | V : | : V\n\t | +-----------+ : | : +-----------+\n\t | | ICookie |--------------------------------\u003e| IObject |\n\t | +-----------+ : | : +-----------+\n\t V | : V : |\n\t+-----------+ | : +-----------+ : |\n\t| DCookie |-------------------------\u003e| DObject | : |\n\t+-----------+ | : +-----------+ : |\n\t | : : |\n\t +-------+-------+ : : |\n\t | | : : |\n\t V V : : V\n\t +-----------+ +-----------+ : : +-----------+\n\t | DCookie | | DCookie |------------------------\u003e| DObject |\n\t +-----------+ +-----------+ : : +-----------+\n\t : :\n\nIn the above illustration, ICookie and IObject represent indices and DCookie\nand DObject represent data storage objects. Indices may have representation in\nmultiple caches, but currently, non-index objects may not. Objects of any type\nmay also be entirely unrepresented.\n\nAs far as the netfs API goes, the netfs is only actually permitted to see\npointers to the cookies. The cookies themselves and any objects attached to\nthose cookies are hidden from it.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nOBJECT MANAGEMENT STATE MACHINE\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nWithin FS-Cache, each active object is managed by its own individual state\nmachine. The state for an object is kept in the fscache_object struct, in\nobject-\u003estate. A cookie may point to a set of objects that are in different\nstates.\n\nEach state has an action associated with it that is invoked when the machine\nwakes up in that state. There are four logical sets of states:\n\n (1) Preparation: states that wait for the parent objects to become ready. The\n representations are hierarchical, and it is expected that an object must\n be created or accessed with respect to its parent object.\n\n (2) Initialisation: states that perform lookups in the cache and validate\n what\u0027s found and that create on disk any missing metadata.\n\n (3) Normal running: states that allow netfs operations on objects to proceed\n and that update the state of objects.\n\n (4) Termination: states that detach objects from their netfs cookies, that\n delete objects from disk, that handle disk and system errors and that free\n up in-memory resources.\n\nIn most cases, transitioning between states is in response to signalled events.\nWhen a state has finished processing, it will usually set the mask of events in\nwhich it is interested (object-\u003eevent_mask) and relinquish the worker thread.\nThen when an event is raised (by calling fscache_raise_event()), if the event\nis not masked, the object will be queued for processing (by calling\nfscache_enqueue_object()).\n\nPROVISION OF CPU TIME\n---------------------\n\nThe work to be done by the various states is given CPU time by the threads of\nthe slow work facility (see Documentation/slow-work.txt). This is used in\npreference to the workqueue facility because:\n\n (1) Threads may be completely occupied for very long periods of time by a\n particular work item. These state actions may be doing sequences of\n synchronous, journalled disk accesses (lookup, mkdir, create, setxattr,\n getxattr, truncate, unlink, rmdir, rename).\n\n (2) Threads may do little actual work, but may rather spend a lot of time\n sleeping on I/O. This means that single-threaded and 1-per-CPU-threaded\n workqueues don\u0027t necessarily have the right numbers of threads.\n\nLOCKING SIMPLIFICATION\n----------------------\n\nBecause only one worker thread may be operating on any particular object\u0027s\nstate machine at once, this simplifies the locking, particularly with respect\nto disconnecting the netfs\u0027s representation of a cache object (fscache_cookie)\nfrom the cache backend\u0027s representation (fscache_object) - which may be\nrequested from either end.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nTHE SET OF STATES\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThe object state machine has a set of states that it can be in. There are\npreparation states in which the object sets itself up and waits for its parent\nobject to transit to a state that allows access to its children:\n\n (1) State FSCACHE_OBJECT_INIT.\n\n Initialise the object and wait for the parent object to become active. In\n the cache, it is expected that it will not be possible to look an object\n up from the parent object, until that parent object itself has been looked\n up.\n\nThere are initialisation states in which the object sets itself up and accesses\ndisk for the object metadata:\n\n (2) State FSCACHE_OBJECT_LOOKING_UP.\n\n Look up the object on disk, using the parent as a starting point.\n FS-Cache expects the cache backend to probe the cache to see whether this\n object is represented there, and if it is, to see if it\u0027s valid (coherency\n management).\n\n The cache should call fscache_object_lookup_negative() to indicate lookup\n failure for whatever reason, and should call fscache_obtained_object() to\n indicate success.\n\n At the completion of lookup, FS-Cache will let the netfs go ahead with\n read operations, no matter whether the file is yet cached. If not yet\n cached, read operations will be immediately rejected with ENODATA until\n the first known page is uncached - as to that point there can be no data\n to be read out of the cache for that file that isn\u0027t currently also held\n in the pagecache.\n\n (3) State FSCACHE_OBJECT_CREATING.\n\n Create an object on disk, using the parent as a starting point. This\n happens if the lookup failed to find the object, or if the object\u0027s\n coherency data indicated what\u0027s on disk is out of date. In this state,\n FS-Cache expects the cache to create\n\n The cache should call fscache_obtained_object() if creation completes\n successfully, fscache_object_lookup_negative() otherwise.\n\n At the completion of creation, FS-Cache will start processing write\n operations the netfs has queued for an object. If creation failed, the\n write ops will be transparently discarded, and nothing recorded in the\n cache.\n\nThere are some normal running states in which the object spends its time\nservicing netfs requests:\n\n (4) State FSCACHE_OBJECT_AVAILABLE.\n\n A transient state in which pending operations are started, child objects\n are permitted to advance from FSCACHE_OBJECT_INIT state, and temporary\n lookup data is freed.\n\n (5) State FSCACHE_OBJECT_ACTIVE.\n\n The normal running state. In this state, requests the netfs makes will be\n passed on to the cache.\n\n (6) State FSCACHE_OBJECT_UPDATING.\n\n The state machine comes here to update the object in the cache from the\n netfs\u0027s records. This involves updating the auxiliary data that is used\n to maintain coherency.\n\nAnd there are terminal states in which an object cleans itself up, deallocates\nmemory and potentially deletes stuff from disk:\n\n (7) State FSCACHE_OBJECT_LC_DYING.\n\n The object comes here if it is dying because of a lookup or creation\n error. This would be due to a disk error or system error of some sort.\n Temporary data is cleaned up, and the parent is released.\n\n (8) State FSCACHE_OBJECT_DYING.\n\n The object comes here if it is dying due to an error, because its parent\n cookie has been relinquished by the netfs or because the cache is being\n withdrawn.\n\n Any child objects waiting on this one are given CPU time so that they too\n can destroy themselves. This object waits for all its children to go away\n before advancing to the next state.\n\n (9) State FSCACHE_OBJECT_ABORT_INIT.\n\n The object comes to this state if it was waiting on its parent in\n FSCACHE_OBJECT_INIT, but its parent died. The object will destroy itself\n so that the parent may proceed from the FSCACHE_OBJECT_DYING state.\n\n(10) State FSCACHE_OBJECT_RELEASING.\n(11) State FSCACHE_OBJECT_RECYCLING.\n\n The object comes to one of these two states when dying once it is rid of\n all its children, if it is dying because the netfs relinquished its\n cookie. In the first state, the cached data is expected to persist, and\n in the second it will be deleted.\n\n(12) State FSCACHE_OBJECT_WITHDRAWING.\n\n The object transits to this state if the cache decides it wants to\n withdraw the object from service, perhaps to make space, but also due to\n error or just because the whole cache is being withdrawn.\n\n(13) State FSCACHE_OBJECT_DEAD.\n\n The object transits to this state when the in-memory object record is\n ready to be deleted. The object processor shouldn\u0027t ever see an object in\n this state.\n\nTHE SET OF EVENTS\n-----------------\n\nThere are a number of events that can be raised to an object state machine:\n\n (*) FSCACHE_OBJECT_EV_UPDATE\n\n The netfs requested that an object be updated. The state machine will ask\n the cache backend to update the object, and the cache backend will ask the\n netfs for details of the change through its cookie definition ops.\n\n (*) FSCACHE_OBJECT_EV_CLEARED\n\n This is signalled in two circumstances:\n\n (a) when an object\u0027s last child object is dropped and\n\n (b) when the last operation outstanding on an object is completed.\n\n This is used to proceed from the dying state.\n\n (*) FSCACHE_OBJECT_EV_ERROR\n\n This is signalled when an I/O error occurs during the processing of some\n object.\n\n (*) FSCACHE_OBJECT_EV_RELEASE\n (*) FSCACHE_OBJECT_EV_RETIRE\n\n These are signalled when the netfs relinquishes a cookie it was using.\n The event selected depends on whether the netfs asks for the backing\n object to be retired (deleted) or retained.\n\n (*) FSCACHE_OBJECT_EV_WITHDRAW\n\n This is signalled when the cache backend wants to withdraw an object.\n This means that the object will have to be detached from the netfs\u0027s\n cookie.\n\nBecause the withdrawing releasing/retiring events are all handled by the object\nstate machine, it doesn\u0027t matter if there\u0027s a collision with both ends trying\nto sever the connection at the same time. The state machine can just pick\nwhich one it wants to honour, and that effects the other.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nAcked-by: Steve Dickson \u003csteved@redhat.com\u003e\nAcked-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nTested-by: Daire Byrne \u003cDaire.Byrne@framestore.com\u003e\n" } ] }