On Mon, 2013-11-25 at 00:42 +0100, Richard Weinberger wrote: > Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once) > added an internal flag MSG_SENDPAGE_NOTLAST. > We have to ensure that MSG_MORE is also set if we set MSG_SENDPAGE_NOTLAST. > Otherwise users that check against MSG_MORE will not see it. > > This fixes sendfile() on AF_ALG. > > Cc: Tom Herbert <therbert@xxxxxxxxxx> > Cc: Eric Dumazet <eric.dumazet@xxxxxxxxx> > Cc: David S. Miller <davem@xxxxxxxxxxxxx> > Cc: <stable@xxxxxxxxxxxxxxx> # 3.4.x > Reported-and-tested-by: Shawn Landden <shawnlandden@xxxxxxxxx> > Signed-off-by: Richard Weinberger <richard@xxxxxx> > --- > fs/splice.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/splice.c b/fs/splice.c > index 3b7ee65..b93f1b8 100644 > --- a/fs/splice.c > +++ b/fs/splice.c > @@ -701,7 +701,7 @@ static int pipe_to_sendpage(struct pipe_inode_info *pipe, > more = (sd->flags & SPLICE_F_MORE) ? MSG_MORE : 0; > > if (sd->len < sd->total_len && pipe->nrbufs > 1) > - more |= MSG_SENDPAGE_NOTLAST; > + more |= MSG_SENDPAGE_NOTLAST | MSG_MORE; > > return file->f_op->sendpage(file, buf->page, buf->offset, > sd->len, &pos, more); I do not think this patch is right. It looks like a revert of a useful patch for TCP zero copy. Given the time it took to discover this regression, I bet tcp zero copy has more users than AF_ALG, by 5 or 6 order of magnitude ;) Here we want to make the difference between the two flags, not merge them. If AF_ALG do not care of the difference, try instead : diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c index ef5356cd280a..850246206b12 100644 --- a/crypto/algif_hash.c +++ b/crypto/algif_hash.c @@ -114,6 +114,9 @@ static ssize_t hash_sendpage(struct socket *sock, struct page *page, struct hash_ctx *ctx = ask->private; int err; + if (flags & MSG_SENDPAGE_NOTLAST) + flags |= MSG_MORE; + lock_sock(sk); sg_init_table(ctx->sgl.sg, 1); sg_set_page(ctx->sgl.sg, page, size, offset); -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html