aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-06-28au1100fb: remove a bogus dma_free_nonconsistent callChristoph Hellwig1-4/+0
au1100fb is using managed dma allocations, so it doesn't need to explicitly free the dma memory in the error path (and if it did it would have to use the managed version). Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-06-28MAINTAINERS: add entry for dma mapping helpersChristoph Hellwig1-0/+15
This code has been spread between getting in through arch trees, the iommu tree, -mm and the drivers tree. There will be a lot of work in this area, including consolidating various arch implementations into more common code, so ensure we have a proper git tree that facilitates cooperation with the architecture maintainers. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28powerpc: merge __dma_set_mask into dma_set_maskChristoph Hellwig2-10/+4
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma-mapping: remove the set_dma_mask methodChristoph Hellwig2-10/+0
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28powerpc/cell: use the dma_supported method for ops switchingChristoph Hellwig1-16/+9
Besides removing the last instance of the set_dma_mask method this also reduced the code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28powerpc/cell: clean up fixed mapping dma_ops initializationChristoph Hellwig1-20/+7
By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can have the fixed map_ops set yet as it's only set by the set_dma_mask method. So move the setup for the fixed case to be only called in that place instead of indirecting through cell_dma_dev_setup. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28tile: remove dma_supported and mapping_error methodsChristoph Hellwig1-30/+0
These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28xen-swiotlb: remove xen_swiotlb_set_dma_maskChristoph Hellwig1-12/+0
This just duplicates the generic implementation. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28arm: implement ->dma_supported instead of ->set_dma_maskChristoph Hellwig1-4/+3
Same behavior, less code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28mips/loongson64: implement ->dma_supported instead of ->set_dma_maskChristoph Hellwig1-14/+5
Same behavior, less code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma-mapping: remove HAVE_ARCH_DMA_SUPPORTEDChristoph Hellwig1-2/+0
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28x86: remove arch specific dma_supported implementationChristoph Hellwig9-11/+13
And instead wire it up as method for all the dma_map_ops instances. Note that this also means the arch specific check will be fully instead of partially applied in the AMD iommu driver. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28arm: remove arch specific dma_supported implementationChristoph Hellwig4-5/+8
And instead wire it up as method for all the dma_map_ops instances. Note that the code seems a little fishy for dmabounce and iommu, but for now I'd like to preserve the existing behavior 1:1. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28openrisc: remove arch-specific dma_supported implementationChristoph Hellwig1-7/+0
This implementation is simply bogus - openrisc only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28hexagon: remove the unused dma_is_consistent prototypeChristoph Hellwig1-1/+0
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28hexagon: remove arch-specific dma_supported implementationChristoph Hellwig2-11/+0
This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Kuo <rkuo@codeaurora.org>
2017-06-28dma-virt: remove dma_supported and mapping_error methodsChristoph Hellwig1-12/+0
These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma-noop: remove dma_supported and mapping_error methodsChristoph Hellwig1-12/+0
These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28sparc: remove arch specific dma_supported implementationsChristoph Hellwig4-43/+39
Usually dma_supported decisions are done by the dma_map_ops instance. Switch sparc to that model by providing a ->dma_supported instance for sbus that always returns false, and implementations tailored to the sun4u and sun4v cases for sparc64, and leave it unimplemented for PCI on sparc32, which means always supported. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
2017-06-28sparc: remove leon_dma_opsChristoph Hellwig2-6/+2
We can just use pci32_dma_ops directly. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
2017-06-28dma-mapping: remove DMA_ERROR_CODEChristoph Hellwig2-31/+5
And update the documentation - dma_mapping_error has been supported everywhere for a long time. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28arm: implement ->mapping_errorChristoph Hellwig4-19/+38
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28x86: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
All dma_map_ops instances now handle their errors through ->mapping_error. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28x86/calgary: implement ->mapping_errorChristoph Hellwig1-8/+16
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28x86/pci-nommu: implement ->mapping_errorChristoph Hellwig1-1/+9
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28powerpc: implement ->mapping_errorChristoph Hellwig6-19/+27
DMA_ERROR_CODE is going to go away, so don't rely on it. Instead define a ->mapping_error method for all IOMMU based dma operation instances. The direct ops don't ever return an error and don't need a ->mapping_error method. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
2017-06-28sparc: implement ->mapping_errorChristoph Hellwig4-9/+21
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
2017-06-28s390: implement ->mapping_errorChristoph Hellwig2-7/+13
s390 can also use noop_dma_ops, and while that currently does not return errors it will so in the future. Implementing the mapping_error method is the proper way to have per-ops error conditions. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
2017-06-28iommu/amd: implement ->mapping_errorChristoph Hellwig1-5/+13
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28hexagon: switch to use ->mapping_error for error reportingChristoph Hellwig3-6/+9
Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Kuo <rkuo@codeaurora.org>
2017-06-20arm64: remove DMA_ERROR_CODEChristoph Hellwig2-3/+1
The dma alloc interface returns an error by return NULL, and the mapping interfaces rely on the mapping_error method, which the dummy ops already implement correctly. Thus remove the DMA_ERROR_CODE define. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
2017-06-20xtensa: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
xtensa already implements the mapping_error method for its only dma_map_ops instance. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20sh: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
sh does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20openrisc: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
openrisc does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20microblaze: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
microblaze does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20m32r: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
dma-noop is the only dma_mapping_ops instance for m32r and does not return errors. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20ia64: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
All ia64 dma_mapping_ops instances already have a mapping_error member. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20c6x: remove DMA_ERROR_CODEChristoph Hellwig1-5/+0
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20xen-swiotlb: implement ->mapping_errorChristoph Hellwig1-2/+10
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2017-06-20xen-swiotlb: consolidate xen_swiotlb_dma_opsChristoph Hellwig4-137/+49
ARM and x86 had duplicated versions of the dma_ops structure, the only difference is that x86 hasn't wired up the set_dma_mask, mmap, and get_sgtable ops yet. On x86 all of them are identical to the generic version, so they aren't needed but harmless. All the symbols used only for xen_swiotlb_dma_ops can now be marked static as well. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2017-06-20iommu/dma: don't rely on DMA_ERROR_CODEChristoph Hellwig1-8/+10
DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu driver already implements a proper ->mapping_error method, so it's only using the value internally. Add a new local define using the value that arm64 which is the only current user of dma-iommu. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20drm/armada: don't abuse DMA_ERROR_CODEChristoph Hellwig3-4/+4
dev_addr isn't even a dma_addr_t, and DMA_ERROR_CODE has never been a valid driver API. Add a bool mapped flag instead. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20drm/exynos: don't use DMA_ERROR_CODEChristoph Hellwig1-2/+2
DMA_ERROR_CODE already isn't a valid API to user for drivers and will go away soon. exynos_drm_fb_dma_addr uses it a an error return when the passed in index is invalid, but the callers never check for it but instead pass the address straight to the hardware. Add a WARN_ON instead and just return 0. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20dmaengine: ioat: don't use DMA_ERROR_CODEChristoph Hellwig1-17/+7
DMA_ERROR_CODE is not a public API and will go away. Instead properly unwind based on the loop counter. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Dave Jiang <dave.jiang@intel.com> Acked-By: Vinod Koul <vinod.koul@intel.com>
2017-06-20ibmveth: properly unwind on init errorsChristoph Hellwig1-85/+74
That way the driver doesn't have to rely on DMA_ERROR_CODE, which is not a public API and going away. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
2017-06-20firmware/ivc: use dma_mapping_errorChristoph Hellwig1-2/+2
DMA_ERROR_CODE is not supposed to be used by drivers. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Thierry Reding <treding@nvidia.com>
2017-06-19Linux 4.12-rc6Linus Torvalds1-1/+1
2017-06-19mm: larger stack guard gap, between vmasHugh Dickins23-163/+152
Stack guard page is a useful feature to reduce a risk of stack smashing into a different mapping. We have been using a single page gap which is sufficient to prevent having stack adjacent to a different mapping. But this seems to be insufficient in the light of the stack usage in userspace. E.g. glibc uses as large as 64kB alloca() in many commonly used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX] which is 256kB or stack strings with MAX_ARG_STRLEN. This will become especially dangerous for suid binaries and the default no limit for the stack size limit because those applications can be tricked to consume a large portion of the stack and a single glibc call could jump over the guard page. These attacks are not theoretical, unfortunatelly. Make those attacks less probable by increasing the stack guard gap to 1MB (on systems with 4k pages; but make it depend on the page size because systems with larger base pages might cap stack allocations in the PAGE_SIZE units) which should cover larger alloca() and VLA stack allocations. It is obviously not a full fix because the problem is somehow inherent, but it should reduce attack space a lot. One could argue that the gap size should be configurable from userspace, but that can be done later when somebody finds that the new 1MB is wrong for some special case applications. For now, add a kernel command line option (stack_guard_gap) to specify the stack gap size (in page units). Implementation wise, first delete all the old code for stack guard page: because although we could get away with accounting one extra page in a stack vma, accounting a larger gap can break userspace - case in point, a program run with "ulimit -S -v 20000" failed when the 1MB gap was counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK and strict non-overcommit mode. Instead of keeping gap inside the stack vma, maintain the stack guard gap as a gap between vmas: using vm_start_gap() in place of vm_start (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few places which need to respect the gap - mainly arch_get_unmapped_area(), and and the vma tree's subtree_gap support for that. Original-patch-by: Oleg Nesterov <oleg@redhat.com> Original-patch-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Tested-by: Helge Deller <deller@gmx.de> # parisc Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-19Merge tag 'armsoc-fixes' of ↵Linus Torvalds5-13/+10
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "Stream of fixes has slowed down, only a few this week: - Some DT fixes for Allwinner platforms, and addition of a clock to the R_CCU clock controller that had been missed. - A couple of small DT fixes for am335x-sl50" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: arm64: allwinner: a64: Add PLL_PERIPH0 clock to the R_CCU ARM: sunxi: h3-h5: Add PLL_PERIPH0 clock to the R_CCU ARM: dts: am335x-sl50: Fix cannot claim requested pins for spi0 ARM: dts: am335x-sl50: Fix card detect pin for mmc1 arm64: allwinner: h5: Remove syslink to shared DTSI ARM: sunxi: h3/h5: fix the compatible of R_CCU
2017-06-18Merge tag 'sunxi-fixes-for-4.12' of ↵Olof Johansson4-7/+8
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes Allwinner fixes for 4.12 A few fixes around the PRCM support that got in 4.12 with a wrong compatible, and a missing clock in the binding. * tag 'sunxi-fixes-for-4.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: arm64: allwinner: a64: Add PLL_PERIPH0 clock to the R_CCU ARM: sunxi: h3-h5: Add PLL_PERIPH0 clock to the R_CCU arm64: allwinner: h5: Remove syslink to shared DTSI ARM: sunxi: h3/h5: fix the compatible of R_CCU Signed-off-by: Olof Johansson <olof@lixom.net>
Powered by cgit, Gruvboxed by Blaster4385.