linux-btrace.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Question: blktrace server mode & orderly shut down
@ 2009-02-03 22:30 Alan D. Brunelle
  2009-02-06  8:03 ` Jens Axboe
  2009-02-06 11:36 ` Alan D. Brunelle
  0 siblings, 2 replies; 3+ messages in thread
From: Alan D. Brunelle @ 2009-02-03 22:30 UTC (permalink / raw)
  To: linux-btrace

According to the recv(2) man page:

The return value will be 0 when the peer has performed an orderly
shutdown.

Yet the code in read_data_net and net_get_header both attempt to re-read
from a socket that will _never_ have data. (I hit this problem today on
blktrace2 - I've got orderly shut downs in place.)

Does this pseudo-patch break something?

diff --git a/blktrace.c b/blktrace.c
index c55b491..9ef7313 100644
--- a/blktrace.c
+++ b/blktrace.c
@@ -550,7 +550,7 @@ static int read_data_net(struct thread_information
*tip, voi
                ret = recv(nc->in_fd, buf, bytes_left, MSG_WAITALL);

                if (!ret)
-                       continue;
+                       return 0;
                else if (ret < 0) {
                        if (errno != EAGAIN) {
                                perror(tip->fn);
@@ -1466,8 +1466,7 @@ static int net_get_header(struct net_connection *nc,
                        usleep(1000);
                        continue;
                } else if (!ret) {
-                       usleep(1000);
-                       continue;
+                       return 0;
                } else {
                        p += ret;
                        bytes_left -= ret;


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: Question: blktrace server mode & orderly shut down
  2009-02-03 22:30 Question: blktrace server mode & orderly shut down Alan D. Brunelle
@ 2009-02-06  8:03 ` Jens Axboe
  2009-02-06 11:36 ` Alan D. Brunelle
  1 sibling, 0 replies; 3+ messages in thread
From: Jens Axboe @ 2009-02-06  8:03 UTC (permalink / raw)
  To: linux-btrace

On Tue, Feb 03 2009, Alan D. Brunelle wrote:
> According to the recv(2) man page:
> 
> The return value will be 0 when the peer has performed an orderly
> shutdown.
> 
> Yet the code in read_data_net and net_get_header both attempt to re-read
> from a socket that will _never_ have data. (I hit this problem today on
> blktrace2 - I've got orderly shut downs in place.)
> 
> Does this pseudo-patch break something?
> 
> diff --git a/blktrace.c b/blktrace.c
> index c55b491..9ef7313 100644
> --- a/blktrace.c
> +++ b/blktrace.c
> @@ -550,7 +550,7 @@ static int read_data_net(struct thread_information
> *tip, voi
>                 ret = recv(nc->in_fd, buf, bytes_left, MSG_WAITALL);
> 
>                 if (!ret)
> -                       continue;
> +                       return 0;
>                 else if (ret < 0) {
>                         if (errno != EAGAIN) {
>                                 perror(tip->fn);
> @@ -1466,8 +1466,7 @@ static int net_get_header(struct net_connection *nc,
>                         usleep(1000);
>                         continue;
>                 } else if (!ret) {
> -                       usleep(1000);
> -                       continue;
> +                       return 0;
>                 } else {
>                         p += ret;
>                         bytes_left -= ret;

My bad, I think the patch looks correct. Feel free to commit it, you can
add my acked-by to it.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Question: blktrace server mode & orderly shut down
  2009-02-03 22:30 Question: blktrace server mode & orderly shut down Alan D. Brunelle
  2009-02-06  8:03 ` Jens Axboe
@ 2009-02-06 11:36 ` Alan D. Brunelle
  1 sibling, 0 replies; 3+ messages in thread
From: Alan D. Brunelle @ 2009-02-06 11:36 UTC (permalink / raw)
  To: linux-btrace

Jens Axboe wrote:
> On Tue, Feb 03 2009, Alan D. Brunelle wrote:
>> According to the recv(2) man page:
>>
>> The return value will be 0 when the peer has performed an orderly
>> shutdown.
>>
>> Yet the code in read_data_net and net_get_header both attempt to re-read
>> from a socket that will _never_ have data. (I hit this problem today on
>> blktrace2 - I've got orderly shut downs in place.)
>>
>> Does this pseudo-patch break something?
>>
>> diff --git a/blktrace.c b/blktrace.c
>> index c55b491..9ef7313 100644
>> --- a/blktrace.c
>> +++ b/blktrace.c
>> @@ -550,7 +550,7 @@ static int read_data_net(struct thread_information
>> *tip, voi
>>                 ret = recv(nc->in_fd, buf, bytes_left, MSG_WAITALL);
>>
>>                 if (!ret)
>> -                       continue;
>> +                       return 0;
>>                 else if (ret < 0) {
>>                         if (errno != EAGAIN) {
>>                                 perror(tip->fn);
>> @@ -1466,8 +1466,7 @@ static int net_get_header(struct net_connection *nc,
>>                         usleep(1000);
>>                         continue;
>>                 } else if (!ret) {
>> -                       usleep(1000);
>> -                       continue;
>> +                       return 0;
>>                 } else {
>>                         p += ret;
>>                         bytes_left -= ret;
> 
> My bad, I think the patch looks correct. Feel free to commit it, you can
> add my acked-by to it.
> 

OK, but this patch may not be sufficient: need to look at it some more
(in particular, just doing this causes other errors to occur because the
connections still try to be read - typically an infinite hang (reading
0)). In blktrace2 I'm adding in orderly shutdowns on both ends of the
socket.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-02-06 11:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-03 22:30 Question: blktrace server mode & orderly shut down Alan D. Brunelle
2009-02-06  8:03 ` Jens Axboe
2009-02-06 11:36 ` Alan D. Brunelle

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).