RxRPC: 3 issues found in my example code

[Leon Liu]

> -----Original Message-----
> From: Tim Smith [mailto:tim at electronghost.co.uk]
> Sent: Sunday, May 04, 2014 8:02 PM
> To: Leon Liu
> Cc: linux-afs at lists.infradead.org; dhowells at redhat.com
> Subject: Re: RxRPC: 3 issues found in my example code
> 
> On Monday 28 April 2014 13:47:42 Leon Liu wrote:
> > Hi Tim,
> >
> > Thank you so much for your very quick response and patch!
> >
> > I've tried the patch. It did fixed the issue #1. I know it maybe a
> > temporary fixing, whatever, I observed two new issues:
> >
> > 1. The fixing increases probability of hitting issue #2 (rxrpc stack
> > return "local error 103, rx busy") dramatically. Probability changes
> > from 1/100000 to 1/5000. You have to turn rxrpc log off to reproduce the
> issue.
> 
> I can generate plenty of "BUSY" packets out of the server by turning the
client
> logging off and leaving the server logging on, and making lots and lots of
calls.
> Actually about 1 in 10 new calls gets me a "BUSY". These are happening
> because the accept queue is full, but I don't get the same symptom at the
> client side that you do.
>
> Your logs go "Rx BUSY" followed by "protocol error" which suggests
> out_clientflag is true on the connection. Which is really odd.

What I did is turning both side logging off. The client side invokes
comm_rw_test.c (in attachment), it sends out several calls in a loop (10000
circles). The server side read and write a memory block pre-allocated at the
offset what the client sent . In this way, it should go very fast. I also
tried turning client side logging on, so I can get the log I sent to you.

> I just get the local connection abort I expect.
> 
> > Occasionally, this can be fixed by re-insmod af-rxrpc.ko at sender.
> > 2. After hitting issue #2 a lot of times, receiver kernel hangs. This
> > was reproduced 3 times.
> 
> On the other hand, if I turn off all the logging and blast it with calls,
I can
> reliably hang the *server* after a while. Methinks that bears
investigation... a
> lockup that manifests one way can manifest another.
> 

I tried using kgdb to connect the server, reproduced the hang issue, but
kgdb could not get response and stack trace at that moment. kgdb is no
problem at other moment.

Anyway, it is good news and progress that you can reproduce these issues.
Very thanks.

Leon

> --
> Tim Smith <tim at electronghost.co.uk>
> Oh, marvelous. You're going to kill me. What a finely-tuned response to
the
> situation.
>     -- The Doctor
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: comm_rw_test.c
Type: application/octet-stream
Size: 6491 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20140505/e7994b07/attachment.obj>