On Mon, Mar 19, 2007 at 07:55:08PM -0400, J. Bruce Fields wrote: > In the loop in scatterwalk_copychunks(), if walk->offset is zero, > then scatterwalk_pagedone rounds that up to the nearest page boundary: > > walk->offset += PAGE_SIZE - 1; > walk->offset &= PAGE_MASK; > > which is a no-op in this case, so we don't advance to the next element > of the scatterlist array: > > if (walk->offset >= walk->sg->offset + walk->sg->length) > scatterwalk_start(walk, sg_next(walk->sg)); > > and we end up copying the same data twice. Thanks for the patch. However I still have a question as to why this is happening. As far as I can see scatterwalk_copychunks is only called in two places. In both spots it only processes one block of data. Since we set the maximum block size to PAGE_SIZE/8 I don't see how you can get an offset of zero and still roll over to the next page in scatterwalk_copychunks. So perhaps the bug is elsewhere in the original patch? Your patch looks like a good clean-up anyway but I just wanted to make sure that I understand what the problem is first. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
