On 2/26/19 6:59 PM, Al Viro wrote:
> On Tue, Feb 26, 2019 at 03:35:39PM -0500, Jason Baron wrote:
>
>>> I understand what the unix_dgram_peer_wake_me() is doing; I understand
>>> what unix_dgram_poll() is using it for. What I do not understand is
>>> what's the point of doing that in unix_dgra
On Tue, Feb 26, 2019 at 03:35:39PM -0500, Jason Baron wrote:
> > I understand what the unix_dgram_peer_wake_me() is doing; I understand
> > what unix_dgram_poll() is using it for. What I do not understand is
> > what's the point of doing that in unix_dgram_sendmsg()...
> >
>
> Hi,
>
> So the u
On 2/26/19 2:03 PM, Al Viro wrote:
> On Tue, Feb 26, 2019 at 03:31:32PM +, Rainer Weikusat wrote:
>> Al Viro writes:
>>> On Tue, Feb 26, 2019 at 06:28:17AM +, Al Viro wrote:
>>
>> [...]
>>
>>
* if after relocking we see that unix_peer(sk) now
is equal to other, we arrange f
On Tue, Feb 26, 2019 at 03:31:32PM +, Rainer Weikusat wrote:
> Al Viro writes:
> > On Tue, Feb 26, 2019 at 06:28:17AM +, Al Viro wrote:
>
> [...]
>
>
> >>* if after relocking we see that unix_peer(sk) now
> >> is equal to other, we arrange for wakeup forwarding from other's
> >> pee
Al Viro writes:
> On Tue, Feb 26, 2019 at 06:28:17AM +, Al Viro wrote:
[...]
>> * if after relocking we see that unix_peer(sk) now
>> is equal to other, we arrange for wakeup forwarding from other's
>> peer_wait *and* if that has (likely) succeeded we fail with -EAGAIN.
>> Huh?
This r
On Tue, Feb 26, 2019 at 06:28:17AM +, Al Viro wrote:
> 2) the logics in sendmsg is very odd:
> * if we'd detected n:1 send *and* found that we need to
> wait, do so (not using the peer_wake - other's peer_wait is not
> going away). No questions there.
> * if we'd detected n:1 send
On Mon, Feb 25, 2019 at 03:51:21AM +, Al Viro wrote:
> PS: unix_dgram_sendmsg() is really much too subtle for its own good -
> AFAICS, it *does* avoid blocking operations under sk->lock, but proof
> is considerably more complex than one would like it to be...
Several questions about the whole
Consider the following scenario: sendmsg() with explicit ->msg_name
on unconnected SOCK_DGRAM AF_UNIX socket finds the recepient just about to
die. We go through
sk_locked = 0;
unix_state_lock(other);
restart_locked:
err = -EPERM;
if (!unix_may_send(sk, othe
