Page MenuHomeFreeBSD

stand: evict zfs_alloc/zfs_free
Needs ReviewPublic

Authored by kevans on May 31 2019, 6:59 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 12 2024, 11:19 PM
Unknown Object (File)
Jan 28 2024, 11:57 AM
Unknown Object (File)
Dec 20 2023, 1:04 AM
Unknown Object (File)
Sep 9 2023, 9:56 AM
Unknown Object (File)
Aug 2 2023, 6:14 PM
Unknown Object (File)
Jul 15 2023, 10:13 PM
Unknown Object (File)
Dec 31 2022, 11:28 PM
Unknown Object (File)
Dec 23 2022, 2:04 PM
Subscribers

Details

Summary

zfs_alloc/zfs_free were meant to be for temporary allocations, but they were occasionally used for more long-lasting allocations (e.g. vdev_raidz_map_alloc). This has problems, as one must carefully free() memory in the exact opposite order that it was allocated (size-wise) due to the error checking done by zfs_free (freed_ptr == zfs_temp_ptr - sz, i.e. removing sz bytes from our block of memory better put us back at the address we're freeing).

Rectify this by removing them and just replacing uses with malloc/free. We weren't gaining much from the panic anyways, and it's error-prone.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 24632

Event Timeline

There is problem now. The zfs_alloc was "always" succeeding but malloc can fail, therefore we can not just replace here, but we also need to add checks.

Take two, a little better... some of the raidz verification stuff needs a small API revamp or reconsideration if we want to try and recover from those, and we may want to improve diagnostics a little bit in other areas.