On Fri 20-11-20 15:59:56, Matthew Wilcox wrote: > On Fri, Nov 20, 2020 at 04:32:53PM +0100, Christoph Hellwig wrote: > > On Fri, Nov 20, 2020 at 12:21:21PM +0100, Jan Kara wrote: > > > > > AFAICT bd_size_lock is pointless after these changes so we can just remove > > > > > it? > > > > > > > > I don't think it is, as reuqiring bd_mutex for size updates leads to > > > > rather awkward lock ordering problems. > > > > > > OK, let me ask differently: What is bd_size_lock protecting now? Ah, I see, > > > on 32-bit it is needed to prevent torn writes to i_size, right? > > > > Exactly. In theory we could skip it for 64-bit, but as updating the > > size isn't a fast path, and struct block_device isn't super size critical > > I'd rather keep the same code for 32 vs 64-bit builds. > > Is it better to switch to i_size_write() / i_size_read()? The code is already switched to it AFAICT (the lock is really only used in the two places that write i_size). But the problem is that in theory two i_size_write() calls can race in a way that the resulting stored i_size is a mix of two stored sizes. Now I have hard time imagining how this could happen for a block device and if two reconfigurations of a block device could race like that we'd have a large problems anyway... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
