linux-kernel - Re: [PATCH 1/2] Add partition resize function to BLKPG ioctl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Jan 2012 15:35:42 -0500
From:	Phillip Susi <psusi@...ntu.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Maxim Patlasov <maxim.patlasov@...il.com>, joe@...ches.com,
	kzak@...hat.com, linux-kernel@...r.kernel.org, jaxboe@...ionio.com
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-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/