Messages in this thread | | | Date | Thu, 26 Jan 2012 15:35:42 -0500 | From | Phillip Susi <> | Subject | Re: [PATCH 1/2] Add partition resize function to BLKPG ioctl |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 1/26/2012 2:01 PM, Vivek Goyal wrote: > I thought update will always happen with mutex lock held. That's > what sequence counter expects so that two updaters don't race. Just > that while updating under mutex lock, we still need to use sequence > counter mecahinsm to update values so that any readers out there > not holding mutex don't get confused.
Yes, but holding the mutex while writing does no good for the reader. When the writer doesn't use the seqcounter, then the reader that is using it is not actually protected.
> Right now readers can afford not to take lock. Introducing mutex on > read side with just add to the cost. Especially IO submission path > where we map IO to a partitiona and we wouldn't want to take > mutexes there?
Yes, it does look like readers can't afford that overhead.
> Are you still pursuing this pathset? Sounds like a useful > functionality to have.
Yes, but I hadn't yet heard back about my question about this being a broader issue that is already a bug in the kernel because things like loop and md already change nr_sects ( on the whole disk partition ) without any protection.
Maybe what we need is a read/write lock on struct genhd, then all readers need to acquire the read lock, which should only slow them down if they collide with a writer.
Another idea that I had but have not yet checked to see if it is actually feasible is to copy the struct genhd, change the size of the copy, and replace the existing one since updating the pointer will be atomic. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPIbkeAAoJEJrBOlT6nu75Bx8IAKgTgA4czpng+JaQkja7n8j9 8B+e+9Asnyp/ND3qkxdUHwmRwJxmC+fJV9PVT84neoBHugN63rX3afc4KGJp5elg k21kziCy46cbIOOeYQDkTZnkHoqHL3dd1sJhO6tv7bDjtRKW0PVY855sKQKW8cNk zjX0WA+iaePs0+Yhd921MwKisRyWtpUr5Sm3Ib0h4kTjRKL7Nyk6cHNH516HpuD2 mXTDCbK5eRhljiadd7igCbbUQNVyFNHm3JGcgLLw35dnarzobZFDlrN1ybXoPExC 31FhDG2Vbo5kLlUNibIsuuf9DoYzBilMTyE/aHN1EtjkTk8bKMg3lZoUi1sVV7c= =TMsc -----END PGP SIGNATURE-----
| |