On 11/10/2017 1:23 PM, Herbert Xu wrote: > On Fri, Nov 10, 2017 at 09:17:33AM +0000, Horia Geantă wrote: >> >>> I must be missing something. In the case rem == 0, let's say >>> the original value of np is npo. Then at the start of the loop, >>> np = npo - 1, and at the last iteration, k = npo - 2, so we do >> IIUC at the start of the loop np = npo (and not npo - 1), since np is no >> longer decremented in the rem == 0 case: >> - np--; >> + if (rem) >> + np--; >> >>> >>> sg_set_buf(&sg[npo - 1], xbuf[npo - 2], PAGE_SIZE); >>> >> and accordingly last iteration is for k = npo - 1: >> sg_set_buf(&sg[npo], xbuf[npo - 1], PAGE_SIZE); >> >>> While the sg_init_table call sets the end-of-table at >>> >>> sg_init_table(sg, npo + 1); >>> >> while this marks sg[npo] as last SG table entry. > > OK, we're both sort of right. You're correct that this generates > a valid SG list in that the number of entries match the end-of-table > marking. > > But the thing that prompted to check this patch in the first place > is the semantics behind it. For the case rem == 0, it means that > buflen is a multiple of PAGE_SIZE. In that case, the code with > your patch will create an SG list that's one page longer than > buflen. > SG table always has 1 entry more than what's needed strictly for input data. Let's say buflen = npo * PAGE_SIZE. SG table generated by the code will have npo + 1 entries: -sg[0] - (1 entry) reserved for associated data, filled outside sg_init_aead() -sg[1]..sg[npo] (npo entries) - input data, entries pointing to xbuf[0]..xbuf[npo-1] Horia
