Files
mirror_zfs/module/zfs
Alexander Motin eeca9a91d6 Fix read errors race after block cloning
Investigating read errors triggering panic fixed in #16042 I've
found that we have a race in a sync process between the moment
dirty record for cloned block is removed and the moment dbuf is
destroyed.  If dmu_buf_hold_array_by_dnode() take a hold on a
cloned dbuf before it is synced/destroyed, then dbuf_read_impl()
may see it still in DB_NOFILL state, but without the dirty record.
Such case is not an error, but equivalent to DB_UNCACHED, since
the dbuf block pointer is already updated by dbuf_write_ready().
Unfortunately it is impossible to safely change the dbuf state
to DB_UNCACHED there, since there may already be another cloning
in progress, that dropped dbuf lock before creating a new dirty
record, protected only by the range lock.

Reviewed-by: Rob Norris <robn@despairlabs.com>
Reviewed-by: Robert Evans <evansr@google.com>
Signed-off-by:	Alexander Motin <mav@FreeBSD.org>
Sponsored by:	iXsystems, Inc.
Closes #16052
2024-04-08 12:03:18 -07:00
..
2024-03-25 16:50:35 -07:00
2022-03-15 15:13:42 -07:00
2022-03-15 15:13:42 -07:00
2023-01-10 13:39:22 -08:00
2023-10-24 11:00:07 -07:00
2024-03-27 14:45:27 -07:00
2023-09-28 14:10:07 -07:00
2023-03-14 15:25:50 -07:00
2023-03-14 15:59:58 -07:00
2023-06-09 10:12:52 -07:00
2022-03-15 15:13:42 -07:00
2022-01-07 10:36:49 -08:00
2022-01-12 16:14:36 -08:00
2023-11-17 13:28:32 -08:00
2019-06-19 09:48:12 -07:00
2023-11-07 12:11:48 -08:00
2022-03-15 15:13:42 -07:00
2023-11-08 10:19:41 -08:00
2023-06-27 09:09:48 -07:00
2023-11-08 10:19:41 -08:00
2023-11-08 10:19:41 -08:00
2024-01-17 09:03:58 -08:00
2024-02-08 09:19:52 -08:00
2023-03-14 15:25:50 -07:00
2023-03-14 15:25:50 -07:00
2022-09-02 13:31:19 -07:00
2023-03-14 15:25:50 -07:00
2024-02-08 09:19:52 -08:00
2022-11-29 09:26:03 -08:00