On Thu, Feb 02, 2023 at 11:50:37AM -0500, Mike Snitzer wrote: > On Wed, Jan 25 2023 at 10:33P -0500, > Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > This work aims to allow userspace to create and destroy block devices > > in a race-free and leak-free way, > > "race-free and leak-free way" implies there both races and leaks in > existing code. You're making claims that are likely very specific to > your Xen use-case. Please explain more carefully. Will do in v2. > > and to allow them to be exposed to > > other Xen VMs via blkback without leaks or races. It’s marked as RFC > > for a few reasons: > > > > - The code has been only lightly tested. It might be unstable or > > insecure. > > > > - The DM_DEV_CREATE ioctl gains a new flag. Unknown flags were > > previously ignored, so this could theoretically break buggy userspace > > tools. > > Not seeing a reason that type of DM change is needed. If you feel > strongly about it send a separate patch and we can discuss it. Patch 2/7 is the diskseq change. v2 will contain a revised and tested version with a greatly expanded commit message. > > - I have no idea if I got the block device reference counting and > > locking correct. > > Your headers and justifcation for this line of work are really way too > terse. Please take the time to clearly make the case for your changes > in both the patch headers and code. I will expand the commit message in v2, but I am not sure what you want me to add to the code comments. Would you mind explaining? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
