On 29/09/15 22:27, Andrew Morton wrote:
[...]
If I'm understanding things correctly, some allocators zero the memory
by default and others do not. And we have an unknown number of drivers
which are assuming that the memory is zeroed.
Correct?
That's precisely the motivation here, yes.
If so, our options are
a) audit all callers, find the ones which expect zeroed memory but
aren't passing __GFP_ZERO and fix them.
b) convert all allocators to zero the memory by default.
Obviously, a) is better. How big a job is it?
This I'm not so sure of, hence the very tentative first step. For a very
crude guess at an an upper bound:
$ git grep -E '(dma|pci)_alloc_co(her|nsist)ent' drivers/ | wc -l
1148
vs.
$ git grep -E '(dma|pci)_zalloc_co(her|nsist)ent' drivers/ | wc -l
234
noting that the vast majority of the former are still probably benign,
but picking out those which aren't from the code alone without knowledge
of and/or access to the hardware might be non-trivial.
This patch will help the process, if people use it.
+ if (IS_ENABLED(CONFIG_DMA_API_DEBUG_POISON) && !(flags & __GFP_ZERO))
+ memset(virt, DMA_ALLOC_POISON, size);
+
This is likely to be slow in the case of non-cached memory and large
allocations. The config option should come with a warning.
It depends on DMA_API_DEBUG, which already has a stern performance
warning, is additionally hidden behind EXPERT, and carries a slightly
flippant yet largely truthful warning that actually using it could break
pretty much every driver in your system; is that not enough?
It might be helpful to provide a runtime knob as well - having to
rebuild&reinstall just to enable/disable this feature is a bit painful.
Good point - there's always the global DMA debug disable knob, but this
particular feature probably does warrant finer-grained control to be
really practical. Having thought about it some more, it's also probably
wrong that this doesn't respect the dma_debug_driver filter, given that
it is actually invasive; in fixing that, how about if it also *only*
applied when a specific driver is filtered? Then there would be no
problematic "break anything and everything" mode, and the existing
debugfs controls should suffice.
Robin.
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html