Files
mirror_zfs/module/zfs
Alexander Motin 602b5dca7b 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-19 10:13:38 -07:00
..
2024-03-28 13:29:46 -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-06-30 09:42:02 -07:00
2023-07-21 16:35:12 -07:00
2024-04-19 10:13:38 -07:00
2024-04-19 10:13:38 -07:00
2023-09-28 14:28:21 -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
2019-06-19 09:48:12 -07:00
2022-03-15 15:13:42 -07:00
2024-04-19 10:13:38 -07:00
2023-06-27 09:09:48 -07:00
2023-03-14 15:25:50 -07:00
2024-01-18 11:33:29 -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-04-19 10:13:38 -07:00
2022-11-29 09:26:03 -08:00
2024-04-19 10:13:38 -07:00