summaryrefslogtreecommitdiffstats
path: root/drivers/pci
diff options
context:
space:
mode:
authorMiquel van Smoorenburg <mikevs@xs4all.net>2008-06-05 18:14:44 +0200
committerIngo Molnar <mingo@elte.hu>2008-06-10 12:22:18 +0200
commitb7f09ae583c49d28b2796d2fa5893dcf822e3a10 (patch)
tree149ba4d9df0eec4c10689d51b33d1e200a512328 /drivers/pci
parentf529626a86d61897862aa1bbbb4537773209238e (diff)
downloadop-kernel-dev-b7f09ae583c49d28b2796d2fa5893dcf822e3a10.zip
op-kernel-dev-b7f09ae583c49d28b2796d2fa5893dcf822e3a10.tar.gz
x86, pci-dma.c: don't always add __GFP_NORETRY to gfp
Currently arch/x86/kernel/pci-dma.c always adds __GFP_NORETRY to the allocation flags, because it wants to be reasonably sure not to deadlock when calling alloc_pages(). But really that should only be done in two cases: - when allocating memory in the lower 16 MB DMA zone. If there's no free memory there, waiting or OOM killing is of no use - when optimistically trying an allocation in the DMA32 zone when dma_mask < DMA_32BIT_MASK hoping that the allocation happens to fall within the limits of the dma_mask Also blindly adding __GFP_NORETRY to the the gfp variable might not be a good idea since we then also use it when calling dma_ops->alloc_coherent(). Clearing it might also not be a good idea, dma_alloc_coherent()'s caller might have set it on purpose. The gfp variable should not be clobbered. [ mingo@elte.hu: converted to delta patch ontop of previous version. ] Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'drivers/pci')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud