On Thu, Apr 21, 2016 at 09:14:51AM +0200, Steffen Klassert wrote: > The network layer tries to allocate high order pages for skb_buff > fragments, this leads to problems if we pass such a buffer to > crypto because crypto assumes to have always order null pages > in the scatterlists.
I don't understand. AFAICS the crypto API assumes no such thing. Of course there might be a bug there since we probably don't get too many superpages coming in normally. > Herbert, I could not find out why this PAGE_SIZE limit is in place. > So not sure if this is the right fix. Also, would it be ok to merge > this, or whatever is the right fix through the IPsec tree? We need > this before we can change esp to avoid linearization. Your patch makes no sense. When you do a kmap you can only do one page at a time. So if you have a "superpage" (an SG list entry with multiple contiguous pages) then you must walk it one page at a time. That's why we cap it at PAGE_SIZE. Is it not walking the superpage properly? Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
