All of lore.kernel.org
 help / color / mirror / Atom feed
From: leroy christophe <christophe.leroy@c-s.fr>
To: Stephan Mueller <smueller@chronox.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	linux-crypto <linux-crypto@vger.kernel.org>,
	'LKML' <linux-kernel@vger.kernel.org>
Subject: Re: algif_hash: splice of data > 2**16
Date: Wed, 24 Dec 2014 15:10:14 +0100	[thread overview]
Message-ID: <549AC946.2000909@c-s.fr> (raw)
In-Reply-To: <11733044.fQnf94a6to@tachyon.chronox.de>


Le 24/12/2014 10:03, Stephan Mueller a écrit :
> Am Dienstag, 23. Dezember 2014, 18:16:01 schrieb leroy christophe:
>
> Hi leroy,
>
>> Le 20/12/2014 07:37, Stephan Mueller a écrit :
>>> Am Donnerstag, 18. Dezember 2014, 13:22:20 schrieb leroy christophe:
>>>
>>> Hi Christophe,
>>>
>>>> Le 18/12/2014 13:15, Stephan Mueller a écrit :
>>>>> Hi Herbert,
>>>>>
>>>>> While testing the vmsplice/splice interface of algif_hash I was made
>>>>> aware of the problem that data blobs larger than 16 pages do not seem to
>>>>> be hashed properly.
>>>>>
>>>>> For testing, a file is mmap()ed and handed to vmsplice / splice. If the
>>>>> file is smaller than 2**16, the interface returns the proper hash.
>>>>> However, when the file is larger, only the first 2**16 bytes seem to be
>>>>> used.
>>>>>
>>>>> When adding printk's to hash_sendpage, I see that this function is
>>>>> invoked exactly 16 times where the first 15 invocations have the
>>>>> MSG_MORE flag set and the last invocation does not have MSG_MORE.
>>>> Hi Stephan,
>>>>
>>>> I have already noticed the same issue and proposed a patch, but I never
>>>> got any feedback and it has never been merged, allthought I pinged it a
>>>> few times.
>>>>
>>>> See https://lkml.org/lkml/2014/4/18/276
>>> After testing, this patch does not work for me. The operation still stops
>>> after 16 pages.
>> Yes, it looks like the function I fixed is exclusively used by
>> sendfile() system call.
>> So there is probably the same kind of fix to be done in another function.
> I do not believe that is the case. IMHO the blocking issue is found in the
> following code:
>
> splice_from_pipe_feed walks the pipe->nrbufs. And vmsplice_to_pipe defines the
> maximum number of nrbufs as PIPE_DEF_BUFFERS -- which is 16. As subsequent
> functions allocate memory based on PIPE_DEF_BUFFERS, there is no trivial way
> to increase the number of pages to be processed.
>
> Thus I see that the vmsplice/splice combo can at most operate on a chunk of 16
> pages. Thus, you have to segment your input buffer into chunks of that size
> and invoke the vmsplice/splice syscalls for each segment.
>
Yes your are probably right. There splice needs to be called with 
SPLICE_F_MORE flag, hope that works.

  reply	other threads:[~2014-12-24 14:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18 12:15 algif_hash: splice of data > 2**16 Stephan Mueller
2014-12-18 12:22 ` leroy christophe
2014-12-18 12:37   ` Stephan Mueller
2014-12-20  6:37   ` Stephan Mueller
2014-12-23 17:16     ` leroy christophe
2014-12-24  9:03       ` Stephan Mueller
2014-12-24 14:10         ` leroy christophe [this message]
2014-12-24 15:12           ` Stephan Mueller
2014-12-25 22:08             ` Stephan Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=549AC946.2000909@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smueller@chronox.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.