Skip to contentSkip to conversation

drivers/xen/swiotlb-xen: update usage of zone modifiers

RFC PATCH New Huaisheng Ye 1 participant 1 message May 23, 2018

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

RFC PATCH v3 3/9 drivers/xen/swiotlb-xen: update usage of zone modifiers

From: Huaisheng Ye <[email protected]>

Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM).

In function xen_swiotlb_alloc_coherent, it is obvious that __GFP_DMA32 is not the expecting zone type.

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 should not be operated with each others by OR.

Use GFP_NORMAL() to clear bottom 3 bits of GFP bitmaks.

Cc Konrad Rzeszutek Wilk <[email protected]>
Cc Boris Ostrovsky <[email protected]>
Cc Juergen Gross <[email protected]>
Cc Christoph Hellwig <[email protected]>
---
 drivers/xen/swiotlb-xen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/xen/swiotlb-xen.c +1 -1
index e1c6089..3999959 100644
@@ -301,7 +301,7 @@ int __ref xen_swiotlb_init(int verbose, bool early)
 	* machine physical layout.  We can't allocate highmem
 	* because we can't return a pointer to it.
 	*/
-	flags &= ~(__GFP_DMA | __GFP_HIGHMEM);
+	flags = GFP_NORMAL(flags);
 
 	/* On ARM this function returns an ioremap'ped virtual address for
 	 * which virt_to_phys doesn't return the corresponding physical
Signature · 1 line
1.8.3.1