| Message ID | 57305FD8.7070006@arm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On 05/09/2016 06:00 AM, Robin Murphy wrote: > On 09/05/16 10:37, Robin Murphy wrote: >> Hi Niklas, >> >> On 08/05/16 11:59, Niklas Söderlund wrote: >>> Hi, >>> >>> While using CONFIG_DMA_API_DEBUG i came across this warning which I >>> think is a false positive. As shown dma_sync_single_for_device() are >>> called from the dma_map_single() call path. This triggers the warning >>> since the dma-debug code have not yet been made aware of the mapping. >> >> Almost right ;) The thing being mapped (the SPI device's buffer) and the >> thing being synced (the IOMMU's PTE) are entirely unrelated. Due to the >> current of_iommu_init() setup, the IOMMU is probed long before >> dma_debug_init() gets called, therefore DMA debug is missing entries for >> some of the initial page table mappings and gets confused when we update >> them later. What was the eventual followup/fix for this? We're seeing similar traces to this during internal testing of 4.11 kernels. Jon.
Hi Jon, On Sun, May 7, 2017 at 2:06 AM, Jon Masters <jcm@jonmasters.org> wrote: > On 05/09/2016 06:00 AM, Robin Murphy wrote: >> On 09/05/16 10:37, Robin Murphy wrote: >>> On 08/05/16 11:59, Niklas Söderlund wrote: >>>> While using CONFIG_DMA_API_DEBUG i came across this warning which I >>>> think is a false positive. As shown dma_sync_single_for_device() are >>>> called from the dma_map_single() call path. This triggers the warning >>>> since the dma-debug code have not yet been made aware of the mapping. >>> >>> Almost right ;) The thing being mapped (the SPI device's buffer) and the >>> thing being synced (the IOMMU's PTE) are entirely unrelated. Due to the >>> current of_iommu_init() setup, the IOMMU is probed long before >>> dma_debug_init() gets called, therefore DMA debug is missing entries for >>> some of the initial page table mappings and gets confused when we update >>> them later. > > What was the eventual followup/fix for this? We're seeing similar traces > to this during internal testing of 4.11 kernels. A quick hack is to change arch/arm64/mm/dma-mapping.c:dma_debug_do_init() from fs_initcall() to arch_initcall(). However, then you loose the debugfs features. A proper fix would involve splitting dma_debug_init() in two phases: an early one doing the real work, and a late one registering the debugfs interface. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/05/17 01:06, Jon Masters wrote: > On 05/09/2016 06:00 AM, Robin Murphy wrote: >> On 09/05/16 10:37, Robin Murphy wrote: >>> Hi Niklas, >>> >>> On 08/05/16 11:59, Niklas Söderlund wrote: >>>> Hi, >>>> >>>> While using CONFIG_DMA_API_DEBUG i came across this warning which I >>>> think is a false positive. As shown dma_sync_single_for_device() are >>>> called from the dma_map_single() call path. This triggers the warning >>>> since the dma-debug code have not yet been made aware of the mapping. >>> >>> Almost right ;) The thing being mapped (the SPI device's buffer) and the >>> thing being synced (the IOMMU's PTE) are entirely unrelated. Due to the >>> current of_iommu_init() setup, the IOMMU is probed long before >>> dma_debug_init() gets called, therefore DMA debug is missing entries for >>> some of the initial page table mappings and gets confused when we update >>> them later. > > What was the eventual followup/fix for this? We're seeing similar traces > to this during internal testing of 4.11 kernels. The IOMMU probe-deferral patches queued for the current merge window get rid of the need for early device creation bodges that cause the problem (of IOMMU pagetables being mapped for DMA before dma-debug is up and running). In the meantime, I'd suggest either adjusting the initcall level per 256ff1cf6b44, or turning off the IOMMU driver and/or using dma-debug's driver-filter option if you're doing more targeted debugging. Robin. > > Jon. > -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/lib/dma-debug.c b/lib/dma-debug.c index 4a1515f4b452..e16684a4ce86 100644 --- a/lib/dma-debug.c +++ b/lib/dma-debug.c @@ -107,7 +107,8 @@ static bool dma_debug_initialized __read_mostly; static inline bool dma_debug_disabled(void) { - return global_disable || !dma_debug_initialized; + return global_disable || WARN_ONCE(!dma_debug_initialized, + "early DMA-API call not tracked"); } /* Global error count */