>> Perhaps calls to kmap_atomic can be replaced with a >> kmap_compound(..) that checks >> >> __this_cpu_read(__kmap_atomic_idx) + (1 << compound_order(p)) < KM_TYPE_NR >> >> before calling kmap_atomic on all pages in the compound page. In >> the common case that the page is not high mem, a single call is >> enough, as there is no per-page operation. > > This does not work. Some callers, such as __skb_checksum, cannot > fail, so neither can kmap_compound. Also, vaddr of consecutive > kmap_atomic calls are not guaranteed to be in order. Indeed, on x86 > and arm vaddr appears to grows down: (FIXADDR_TOP - ((x) << PAGE_SHIFT)) > > An alternative is to change the kmap_atomic callers in skbuff.c. To > avoid open coding, we can wrap the kmap_atomic; op; kunmap_atomic > in a macro that loops only if needed I'll send this as RFC. It's not the most elegant solution. The issue only arises with pages allocated with both __GFP_COMP and __GFP_HIGHMEM, which is rare: skb_page_frag_refill, alloc_skb_with_frags, __napi_alloc_skb and most device drivers do not pass the high mem flag. Exceptions are rds, mlx5. And transparent hugepages, which is a problem with zerocopy fragments only (though not only msg_zerocopy, potentially also the existing virtio and xen paths). A simpler solution, then, may be to covert rds and mlx5 to not pass __GFP_HIGHMEM and copy data on all zerocopy requests for this type of pages. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
