[Pvfs2-developers] bmi-tcp doubt
carns at mcs.anl.gov
Mon Nov 24 10:10:29 EST 2008
This patch fixes the code so that it does the right thing if you just
return an error code from the tcp_accept_init() function. It is already
applied to cvs trunk.
Phil Carns wrote:
> For an immediate solution you can just mimic the logic in the "BIG
> KLUDGE" comment block (where the trusted host/port check is similarly
> discarding the request). I was offering to fix that function so the
> error handling works better, but it will be a few days.
> Pai, Ankur G wrote:
>> Disregarding the connection is fine with me. But what do I return
>> from bmi_tcp.c. If I return 0, the client call completes. If I return
>> -1, server crashes. So if I want to disregard the request, what do I
>> return from tcp_accept_init() ?
>> Thanks, Ankur ----- Original Message ----- From: "Phil Carns"
>> <carns at mcs.anl.gov> To: "Ankur G Pai" <paiankur at gatech.edu> Cc:
>> pvfs2-developers at beowulf-underground.org Sent: Thursday, November 20,
>> 2008 1:52:56 PM GMT -05:00 Columbia Subject: Re: [Pvfs2-developers]
>> bmi-tcp doubt
>> The easiest thing would be to just discard the connection, but the
>> downside is the client simply won't get a response back. It would
>> just timeout and report "connection refused" instead.
>> The error path needs to be cleaned up regardless, though. Someone
>> else also ran into this in another context recently. I'll look into
>> it and get a patch to you.
>> Pai, Ankur G wrote:
>>> Hi Phil, All I want is the server not to crash and me not having to
>>> take the request forward since I have already decided into not
>>> servicing it. Could you suggest a reasonable approach?
>>> Thanks, Ankur ----- Original Message ----- From: "Phil Carns"
>>> <carns at mcs.anl.gov> To: "Ankur G Pai" <paiankur at gatech.edu> Cc:
>>> pvfs2-developers at beowulf-underground.org Sent: Thursday, November
>>> 20, 2008 10:07:44 AM GMT -05:00 Columbia Subject: Re:
>>> [Pvfs2-developers] bmi-tcp doubt
>>> Hi Ankur,
>>> I think we could clean up this path some. Just to clarify what you
>>> are looking for though, are you planning to send a response all
>>> the way back to the client? The server does not normally send a
>>> response back for a failed unexpected message. In the case you
>>> describe, you would need to propagate a specific error code out of
>>> testunexpected(), and then add server state machine code to have it
>>> identify that particular error code and send a response.
>>> Assuming that sounds like a reasonable approach, I'll look into
>>> cleaning up the BMI part of that equation.
>>> Pai, Ankur G wrote:
>>>> Guys, I need some help. I am trying to change the function
>>>> tcp_accept_init() inside src/io/bmi/bmi_tcp/bmi-tcp.c. This function
>>>> has the accept() call (ie. it is the first point of contact by the
>>>> pvfs client to the server). At this point I need
>>>> to make some immediate checks and decide if I want to allow this
>>>> client any further access to the server. If I find out that I do NOT
>>>> want to allow access I need to cleanly return an error to the
>>>> client. If I do a return (-1) from this function, however, the
>>>> server's bmi thread simply crashes giving me the foll output:
>>>> [E 11/15 17:24] src/io/bmi/bmi.c line 957: Error: critical
>>>> BMI_testcontext failure. [E 11/15 17:24] [bt]
>>>> pvfs2-server(BMI_testcontext+0x274) [0x807a344] [E 11/15 17:24] [bt]
>>>> pvfs2-server [0x8072971] [E 11/15 17:24] [bt]
>>>> /lib/libpthread.so.0 [0xd4340b] [E 11/15 17:24] [bt]
>>>> /lib/libc.so.6(__clone+0x5e) [0xa03b7e] [E 11/15 17:24] Warning: non
>>>> PVFS2 error code (1): [E 11/15 17:24] critical BMI failure. :
>>>> Operation not permitted [E 11/15 17:24] bmi_thread_function
>>>> thread terminating [E 11/15 17:24] PVFS2 server got signal 2
>>>> (server_status_flag: 262143)
>>>> I am using pvfs-2.6.3. At this point in the code, i see a comment
>>>> which says:
>>>> /* FIXME: * BIG KLUDGE * if we return an error, pvfs2-server's
>>>> bmi thread simply terminates. * hence I am returning 0 here. Need
>>>> to ask Phil or RobR about this... */
>>>> Is there any fix for this problem yet?
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2028 bytes
Desc: not available
Url : http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20081124/9b90d314/bmi-err-handling.bin
More information about the Pvfs2-developers