mirror of
https://git.openafs.org/openafs.git
synced 2025-01-19 15:30:14 +00:00
ihandle: Add a comment on IH_OPEN/IH_REALLYCLOSE
Currently, it's not really 'safe' in ihandle to issue an IH_OPEN against an IHandle_t when an IH_REALLYCLOSE is running at the same time. The reasons for this are explained a bit in ticket 131530 and related commits, but briefly: Say IH_OPEN runs, and drops IH_LOCK to open a new fd on disk. Then IH_REALLYCLOSE runs and closes all fds, or marks them as needing close. The running IH_OPEN then acquires IH_LOCK again and puts the newly-opened fd onto the per-IH list of fds. We now have an fd that effectively "survives" across the IH_REALLYCLOSE; effectively IH_REALLYCLOSE did not close all fds for the ih. This is possibly fixable by maintaining some extra information in IHandle_t's, but this is only a problem if we allow IH_OPEN calls to happen simultaneously with IH_REALLYCLOSE calls. Ever since ih_sync_thread was removed (or changed to not call IH_OPEN), there should be no cases where this is possible. All instances of IH_REALLYCLOSE happen during error recovery for a newly-created file, or happen under a per-vnode write lock, or for volume metadata files only happens when the ref count for a volume drops to zero when we're offlining the volume. So, do not bother trying to fix this, since doing so is currently a waste of time and the resulting complexity could introduce bugs. But in case someone ever tries to do something resulting in IH_OPEN calls executing outside the normal threads of execution, add a comment around the IH_REALLYCLOSE explanations to try and briefly explain that this cannot currently be done. Change-Id: I989806635f3b048b0c084480a4b02dc1902ba031 Reviewed-on: http://gerrit.openafs.org/9709 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Daria Brashear <shadow@your-file-system.com>
This commit is contained in:
parent
d43699173e
commit
71072c2bb3
@ -19,6 +19,16 @@
|
||||
* cached by IO_CLOSE. To make sure a file descriptor is really closed call
|
||||
* IH_REALLYCLOSE.
|
||||
*
|
||||
* Note that IH_REALLYCLOSE does not guarantee that all file descriptors are
|
||||
* closed (or are marked as needing close) by the time it returns, in the case
|
||||
* of an IH_OPEN being executed in parallel. If a separate thread is running
|
||||
* an IH_OPEN on the same IHandle_t at around the same time, it is possible for
|
||||
* it to open the file, then IH_REALLYCLOSE runs, and then IH_OPEN associates
|
||||
* the file handle with the IHandle_t. For this reason, it is probably an
|
||||
* error if it is ever possible to have an IH_OPEN call run at the same time as
|
||||
* an IH_REALLYCLOSE call on the same IHandle_t. If such functionality is
|
||||
* required, ihandle must be changed to accomodate this.
|
||||
*
|
||||
* The IHandle_t also provides a place to do other optimizations. In the
|
||||
* NT user space file system, we keep a separate special file for the
|
||||
* link counts and using the IHandle_t allows keeping the details of
|
||||
|
Loading…
Reference in New Issue
Block a user