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)
Tue, Jul 14, 3:26 AM
Unknown Object (File)
Tue, Jul 14, 12:52 AM
Unknown Object (File)
Mon, Jul 13, 8:04 PM
Unknown Object (File)
Sun, Jul 12, 9:25 AM
Unknown Object (File)
Sat, Jul 11, 10:55 PM
Unknown Object (File)
Sun, Jul 5, 12:16 PM
Unknown Object (File)
Apr 12 2026, 1:43 AM
Unknown Object (File)
Apr 7 2026, 5:09 AM
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.