Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [lttng-dev] [PATCH 2/2] Fix: read subbuffer splice signedness issue
Date: Sat, 8 Feb 2014 15:51:56 +0000 (UTC)	[thread overview]
Message-ID: <1252014966.21031.1391874716079.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <1391805760-30421-2-git-send-email-dgoulet@efficios.com>



----- Original Message -----
> From: "David Goulet" <dgoulet@efficios.com>
> To: lttng-dev at lists.lttng.org
> Sent: Friday, February 7, 2014 3:42:40 PM
> Subject: [lttng-dev] [PATCH 2/2] Fix: read subbuffer splice signedness issue
> 
> Same issue as the previous fix in the mmap read subbuffer. However, this
> patch keeps looping on the len since splice() does NOT give any
> guarantee that it will splice the full count.
> 
> Signed-off-by: David Goulet <dgoulet at efficios.com>
> ---
>  src/common/consumer.c | 41 ++++++++++++++++++++++++++---------------
>  1 file changed, 26 insertions(+), 15 deletions(-)
> 
> diff --git a/src/common/consumer.c b/src/common/consumer.c
> index 59d4366..798e22e 100644
> --- a/src/common/consumer.c
> +++ b/src/common/consumer.c
> @@ -1796,17 +1796,24 @@ ssize_t lttng_consumer_on_read_subbuffer_splice(
>  	}
>  
>  	while (len > 0) {
> +		/*
> +		 * Set the len value to a signed value so the if/else statement can
> +		 * evaluate it against the signed returned value from lttng_write since
> +		 * -1 can be returned indicating a communication failure.
> +		 */
> +		ssize_t signed_len = len;
> +
>  		DBG("splice chan to pipe offset %lu of len %lu (fd : %d, pipe: %d)",
>  				(unsigned long)offset, len, fd, splice_pipe[1]);
>  		ret_splice = splice(fd, &offset, splice_pipe[1], NULL, len,
>  				SPLICE_F_MOVE | SPLICE_F_MORE);
>  		DBG("splice chan to pipe, ret %zd", ret_splice);
> -		if (ret_splice < 0) {
> -			PERROR("Error in relay splice");
> +		if (ret_splice < signed_len) {
> +			ret = errno;
>  			if (written == 0) {
>  				written = ret_splice;
>  			}
> -			ret = errno;
> +			PERROR("Error in relay splice");
>  			goto splice_error;
>  		}
>  
> @@ -1824,6 +1831,8 @@ ssize_t lttng_consumer_on_read_subbuffer_splice(
>  				 * argument to this function.
>  				 */
>  				written -= metadata_payload_size;
> +				/* Take back a signed reference of the updated len. */
> +				signed_len = len;
>  			}
>  		}
>  
> @@ -1831,28 +1840,33 @@ ssize_t lttng_consumer_on_read_subbuffer_splice(
>  		ret_splice = splice(splice_pipe[0], NULL, outfd, NULL,
>  				ret_splice, SPLICE_F_MOVE | SPLICE_F_MORE);
>  		DBG("Consumer splice pipe to file, ret %zd", ret_splice);
> -		if (ret_splice < 0) {
> -			PERROR("Error in file splice");
> +		if (ret_splice < signed_len) {

similar comment than the other patch: we should first check if ret_splice < 0,
and then in the else of that check, we can do a cast and assume that the value
is not negative (because we already tested it).

Thanks,

Mathieu

> +			ret = errno;
>  			if (written == 0) {
>  				written = ret_splice;
>  			}
>  			/* Socket operation failed. We consider the relayd dead */
> -			if (errno == EBADF || errno == EPIPE) {
> +			if (errno == EBADF || errno == EPIPE || errno == ESPIPE) {
>  				WARN("Remote relayd disconnected. Stopping");
>  				relayd_hang_up = 1;
>  				goto write_error;
>  			}
> -			ret = errno;
> +			PERROR("Error in file splice");
>  			goto splice_error;
> -		} else if (ret_splice > len) {
> -			errno = EINVAL;
> -			PERROR("Wrote more data than requested %zd (len: %lu)",
> -					ret_splice, len);
> +		} else if (ret_splice > signed_len) {
> +			/*
> +			 * We don't expect this code path to be executed but you never know
> +			 * so this is an extra protection agains a buggy splice().
> +			 */
>  			written += ret_splice;
>  			ret = errno;
> +			PERROR("Wrote more data than requested %zd (len: %lu)", ret_splice,
> +					len);
>  			goto splice_error;
> +		} else {
> +			/* All good, update current len and continue. */
> +			len -= ret_splice;
>  		}
> -		len -= ret_splice;
>  
>  		/* This call is useless on a socket so better save a syscall. */
>  		if (!relayd) {
> @@ -1865,9 +1879,6 @@ ssize_t lttng_consumer_on_read_subbuffer_splice(
>  		written += ret_splice;
>  	}
>  	lttng_consumer_sync_trace_file(stream, orig_offset);
> -
> -	ret = ret_splice;
> -
>  	goto end;
>  
>  write_error:
> --
> 1.8.5.3
> 
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com



  reply	other threads:[~2014-02-08 15:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-07 20:42 [lttng-dev] [PATCH 1/2] Fix: read subbuffer mmap " David Goulet
2014-02-07 20:42 ` [lttng-dev] [PATCH 2/2] Fix: read subbuffer splice " David Goulet
2014-02-08 15:51   ` Mathieu Desnoyers [this message]
2014-02-08 15:50 ` [lttng-dev] [PATCH 1/2] Fix: read subbuffer mmap " Mathieu Desnoyers

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=1252014966.21031.1391874716079.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox