[Pvfs2-developers] bmi-tcp doubt

[Phil Carns]

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.

-Phil

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.
> 
> -Phil
> 
> 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.
>> 
>> -Phil
>> 
>> 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?
>>> 
>>> 
>> 
>> 
> 
>