There are four places, all in cam_xpt.c, where ccbs are malloc'ed. Two use M_ZERO and two don't. Use M_ZERO in all cases.
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Don't see why this would cause problems, but get Scott or Mav to give the nod before committing.
CCB structure is quite large. I worry that zeroing it on every request can be too heavy and pointless.
For the sake of safety, it needs to be done. It's likely to not be as expensive as you fear, though. Many of the data fields get written to immediately after the allocation and zeroing, so the multiple writes will collect and collapse together in the caches.
What needs to be done long-term is for the CCB allocation scheduler to go away so that CCBs can be allocated based on the needed sub-type, and thus have a dynamic size. That allocation can then be moved to a custom UMA zone with a constructor that zeros fields in a more intelligent way.
All places we alloc a CCB use M_ZERO in today's code for malloc and uma_zalloc.
So this is no longer relevant. Closing to cleanup old, stale reviews.
d3995fdd6a2652a4ffc9753cc49aa16b641511ef / r280388 landed this...
commit d3995fdd6a2652a4ffc9753cc49aa16b641511ef
Author: Benno Rice <benno@FreeBSD.org>
Date: Mon Mar 23 18:45:37 2015 +0000
Be consistent with M_ZERO when allocating ccbs. There are four places, all in cam_xpt.c, where ccbs are malloc'ed. Two of these use M_ZERO, two don't. The two that don't meant that allocated ccbs had trash in them making it hard to debug errors where they showed up. Due to this, use M_ZERO all the time when allocating ccbs. Submitted by: Scott Ferris <scott.ferris@isilon.com> Sponsored by: EMC/Isilon Storage Division Reviewed by: scottl, imp Differential: https://reviews.freebsd.org/D2120