Bio read race with different ranges inside the same page?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Is it possible that multiple ranges of the same page are submitted to
one or more bios, and such ranges race with each other and cause data
corruption.

Recently I'm trying to add subpage read/write support for btrfs, and
notice one strange false data corruption.

E.g, there is a 64K page to be read from disk:

0	16K	32K	48K	64K
|///////|       |///////|       |

Where |///| means data which needs to be read from disk.
And |   | means hole, we just zeroing the range.

Currently the code will:

- Submit bio for [0, 16K)
- Zero [16K, 32K)
- Submit bio for [32K, 48K)
- Zero [48K, 64k)

Between bio submission and zero, there is no need to wait for submitted
bio to finish, as I assume the submitted bio won't touch any range of
the page, except the one specified.

But randomly (not reliable), btrfs csum verification at the endio time
reports errors for the data read from disk mismatch from csum.

However the following things show it's read path has something wrong:
- On-disk data matches with csum

- If fully serialized the read path, the error just disappera
  If I changed the read path to be fully serialized, e.g:
  - Submit bio for [0, 16K)
  - Wait bio for [0, 16K) to finish
  - Zero [16K, 32K)
  - Submit bio for [32K, 48K)
  - Wait bio for [32K, 48K) to finish
  - Zero [48K, 64k)
  Then the problem just completely disappears.

So this looks like that, the read path hole zeroing and bio submission
is racing with each other?

Shouldn't bios only touch the range specified and not touching anything
else?

Or is there something I missed like off-by-one bug?

Thanks,
Qu




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux