Re: [PATCH] rpcbind: don't ignore bind and init_transport errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sep 17, 2010, at 6:22 PM, Jan RÄkorajski wrote:

> On Fri, 17 Sep 2010, Chuck Lever wrote:
> 
>> On Sep 17, 2010, at 3:04 PM, Jan RÄkorajski wrote:
>> 
>>> On Fri, 17 Sep 2010, Chuck Lever wrote:
>>> 
>>>> 
>>>> On Sep 17, 2010, at 2:12 PM, Jan RÄkorajski wrote:

[ ... snipped ... ]

> 
>>> And, besides, behavior for UDP and TCP sockets is currently inconsistent
>>> as init_transport ignores any failed UDP bind and correctly
>>> returns error for TCP.
>> 
>> That _may_ be intentional.  UDP semantics are "unreliable," so an
>> error may be expected even at bind time.  Who knows, it doesn't look
>> very well documented.
> 
> What about TCP then?  My patch was a by-product of trying to make '-h <IP>'
> also work for tcp sockets, so if we skip unbindable addresses for UDP,
> then will it be ok to do the same for TCP?

Interesting.  Now that I've actually looked at the documentation >> blush << rpcbind(8) explicitly says that "-h" is only for UDP.  I seem to recall that the legacy portmapper had a problem on multi-homed hosts where a request was received on one interface, and the reply was sent out another.

This is certainly a problem for datagram transports, but shouldn't be an issue for connection-oriented transports: the reply is always sent on the same connection as the request was received.

Can you say a little more about why do you need "-h" to work for connection-oriented sockets?

-- 
chuck[dot]lever[at]oracle[dot]com




--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux