Bug #696
closed
Incorrect check dma_attr_sgllen <= 0 in rootnex_valid_alloc_parms
0%
Description
The check in question:
/*
* rootnex_valid_alloc_parms()
* Called in ddi_dma_alloc_handle path to validate its parameters.
*/
static int
rootnex_valid_alloc_parms(ddi_dma_attr_t *attr, uint_t maxsegmentsize)
...
if ((attr->dma_attr_seg & MMU_PAGEOFFSET) != MMU_PAGEOFFSET ||
MMU_PAGESIZE & (attr->dma_attr_granular - 1) ||
==> attr->dma_attr_sgllen <= 0) { <===
return (DDI_DMA_BADATTR);
}
...
dmi_dma_attr(9S) does specify values < 0 as correct, so the check looks incorrect, breaking vmxnet3 driver when DEBUG is defined, at least.
The fix is to to remove the check or make it == 0 (0 is reserved, per manpage).
Updated by Yuri Pankov over 11 years ago
That should read ddi_dma_attr(9S), of course.
Updated by Garrett D'Amore over 11 years ago
- Category set to kernel
- Assignee set to Garrett D'Amore
The check should just include == 0... clearly negative values are legal.
Updated by Rich Lowe over 11 years ago
The check's been there for a long, long time. I must be missing how vmxnet3 worked previously, if this has thought its attributes invalid for so long?
Also, a quick glance over the code doesn't find other drivers using negative values and also doesn't really find evidence of negative values behaving as documented.
Am I missing where the magic happens?
Updated by Garrett D'Amore over 11 years ago
It only gets used in debug kernels.
Strangely, I don't see any drivers in ON that have -1 set. I thought for sure that there were others.... I do see some that have "big" values ... dnet for example has it set to 0x7fff in one instance. tavor has it set to 0x7FFFFFFF in another.
Updated by Rich Lowe over 11 years ago
WDD just documents it as the maximum scatter/gather length, no mention of negative values.
Updated by Garrett D'Amore about 11 years ago
- Status changed from New to Resolved
- Difficulty set to Medium
- Tags set to needs-triage