Messages in this thread | | | Date | Wed, 5 Jan 2022 09:45:17 -0800 | From | "Darrick J. Wong" <> | Subject | Re: [PATCH v9 01/10] dax: Use percpu rwsem for dax_{read,write}_lock() |
| |
On Tue, Jan 04, 2022 at 02:44:08PM -0800, Dan Williams wrote: > On Sun, Dec 26, 2021 at 6:35 AM Shiyang Ruan <ruansy.fnst@fujitsu.com> wrote: > > > > In order to introduce dax holder registration, we need a write lock for > > dax. > > As far as I can see, no, a write lock is not needed while the holder > is being registered. > > The synchronization that is needed is to make sure that the device > stays live over the registration event, and that any in-flight holder > operations are flushed before the device transitions from live to > dead, and that in turn relates to the live state of the pgmap. > > The dax device cannot switch from live to dead without first flushing > all readers, so holding dax_read_lock() over the register holder event > should be sufficient.
...and perhaps add a comment describing that this is what the synchronization primitive is really protecting against? The first time I read through this patchset, I assumed the rwsem was protecting &dax_hosts and was confused when I saw the one use of dax_write_lock.
--D
> If you are worried about 2 or more potential > holders colliding at registration time, I would expect that's already > prevented by block device exclusive holder synchronization, but you > could also use cmpxchg and a single pointer to a 'struct dax_holder { > void *holder_data, struct dax_holder_operations *holder_ops }'. If you > are worried about memory_failure triggering while the filesystem is > shutting down it can do a synchronize_srcu(&dax_srcu) if it really > needs to ensure that the notify path is idle after removing the holder > registration. > > ...are there any cases remaining not covered by the above suggestions?
| |