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)
Mon, Jun 23, 6:51 AM
Unknown Object (File)
Sun, Jun 22, 11:46 AM
Unknown Object (File)
Fri, Jun 20, 7:52 PM
Unknown Object (File)
Fri, Jun 20, 5:27 PM
Unknown Object (File)
Tue, Jun 17, 3:19 PM
Unknown Object (File)
Sat, Jun 14, 10:59 PM
Unknown Object (File)
May 29 2025, 3:43 PM
Unknown Object (File)
May 29 2025, 2:33 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.