+/*
+ * -- The Truncate Lock --
+ *
+ * The truncate lock is used for a few purposes (more than its name
+ * might suggest). The first thing to note is that the cnode lock
+ * cannot be held whilst issuing any I/O other than metadata changes,
+ * so the truncate lock, in either shared or exclusive form, must
+ * usually be held in these cases. This includes calls to ubc_setsize
+ * where the new size is less than the current size known to the VM
+ * subsystem (for two reasons: a) because reaping pages can block
+ * (e.g. on pages that are busy or being cleaned); b) reaping pages
+ * might require page-in for tasks that have that region mapped
+ * privately). The same applies to other calls into the VM subsystem.
+ *
+ * Here are some (but not necessarily all) cases that the truncate
+ * lock protects for:
+ *
+ * + When reading and writing a file, we hold the truncate lock
+ * shared to ensure that the underlying blocks cannot be deleted
+ * and on systems that use content protection, this also ensures
+ * the keys remain valid (which might be being used by the
+ * underlying layers).
+ *
+ * + We need to protect against the following sequence of events:
+ *
+ * A file is initially size X. A thread issues an append to that
+ * file. Another thread truncates the file and then extends it
+ * to a a new size Y. Now the append can be applied at offset X
+ * and then the data is lost when the file is truncated; or it
+ * could be applied after the truncate, i.e. at offset 0; or it
+ * can be applied at offset Y. What we *cannot* do is apply the
+ * append at offset X and for the data to be visible at the end.
+ * (Note that we are free to choose when we apply the append
+ * operation.)
+ *
+ * To solve this, we keep things simple and take the truncate lock
+ * exclusively in order to sequence the append with other size
+ * changes. Therefore any size change must take the truncate lock
+ * exclusively.
+ *
+ * (N.B. we could do better and allow readers to run concurrently
+ * during the append and other size changes.)
+ *
+ * So here are the rules:
+ *
+ * + If you plan to change ff_size, you must take the truncate lock
+ * exclusively, *but* be careful what I/O you do whilst you have
+ * the truncate lock exclusively and try and avoid it if you can:
+ * if the VM subsystem tries to do something with some pages on a
+ * different thread and you try and do some I/O with those same
+ * pages, we will deadlock. (See #16620278.)
+ *
+ * + If you do anything that requires blocks to not be deleted or
+ * encryption keys to remain valid, you must take the truncate lock
+ * shared.
+ *
+ * + And it follows therefore, that if you want to delete blocks or
+ * delete keys, you must take the truncate lock exclusively. Note
+ * that for asynchronous writes, the truncate lock will be dropped
+ * after issuing I/O but before the I/O has completed which means
+ * that before manipulating keys, you *must* issue
+ * vnode_wait_for_writes in addition to holding the truncate lock.
+ *
+ * N.B. ff_size is actually protected by the cnode lock and so you
+ * must hold the cnode lock exclusively to change it and shared to
+ * read it.
+ *
+ */
+
+enum hfs_locktype {
+ HFS_SHARED_LOCK = 1,
+ HFS_EXCLUSIVE_LOCK = 2
+};
+
+/* Option flags for cnode and truncate lock functions */
+enum hfs_lockflags {
+ HFS_LOCK_DEFAULT = 0x0, /* Default flag, no options provided */
+ HFS_LOCK_ALLOW_NOEXISTS = 0x1, /* Allow locking of all cnodes, including cnode marked deleted with no catalog entry */
+ HFS_LOCK_SKIP_IF_EXCLUSIVE = 0x2, /* Skip locking if the current thread already holds the lock exclusive */
projects / apple / xnu.git / blobdiff