On Fri, Nov 20, 2020 at 09:05:48PM +0100, Jan Kara wrote:
> 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 t
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?
> > > >
>
On Fri, Nov 20, 2020 at 03:59:56PM +, Matthew Wilcox wrote:
> > 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 swit
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 upd
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 different
On Fri 20-11-20 10:08:20, Christoph Hellwig wrote:
> On Thu, Nov 19, 2020 at 01:05:25PM +0100, Jan Kara wrote:
> > > @@ -613,7 +613,7 @@ void guard_bio_eod(struct bio *bio)
> > > rcu_read_lock();
> > > part = __disk_get_part(bio->bi_disk, bio->bi_partno);
> > > if (part)
> > > - maxse
On Thu, Nov 19, 2020 at 01:05:25PM +0100, Jan Kara wrote:
> > @@ -613,7 +613,7 @@ void guard_bio_eod(struct bio *bio)
> > rcu_read_lock();
> > part = __disk_get_part(bio->bi_disk, bio->bi_partno);
> > if (part)
> > - maxsector = part_nr_sects_read(part);
> > + maxsec
On Wed 18-11-20 09:47:54, Christoph Hellwig wrote:
> Now that the hd_struct always has a block device attached to it, there is
> no need for having two size field that just get out of sync.
>
> Additional the field in hd_struct did not use proper serializiation,
> possibly allowing for torn writes
Now that the hd_struct always has a block device attached to it, there is
no need for having two size field that just get out of sync.
Additional the field in hd_struct did not use proper serializiation,
possibly allowing for torn writes. By only using the block_device field
this problem also get
