Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1293986

Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

From Hannes Frederic Sowa <hannes@stressinduktion.org>
Newsgroups linux.kernel
Subject Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code
Date 2015-12-17 16:50 +0100
Message-ID <qGIYy-1kc-7@gated-at.bofh.it> (permalink)
References <qGqyB-6n7-7@gated-at.bofh.it> <qGD2O-5Sl-9@gated-at.bofh.it> <qGIFc-1cH-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 17.12.2015 16:28, Rainer Weikusat wrote:
> Hannes Frederic Sowa <hannes@stressinduktion.org> writes:
>> On 16.12.2015 21:09, Rainer Weikusat wrote:
>>> With b3ca9b02b00704053a38bfe4c31dbbb9c13595d0, the AF_UNIX SOCK_STREAM
>>> receive code was changed from using mutex_lock(&u->readlock) to
>>> mutex_lock_interruptible(&u->readlock) to prevent signals from being
>>> delayed for an indefinite time if a thread sleeping on the mutex
>>> happened to be selected for handling the signal. But this was never a
>>> problem with the stream receive code (as opposed to its datagram
>>> counterpart) as that never went to sleep waiting for new messages with the
>>> mutex held and thus, wouldn't cause secondary readers to block on the
>>> mutex waiting for the sleeping primary reader. As the interruptible
>>> locking makes the code more complicated in exchange for no benefit,
>>> change it back to using mutex_lock.
>>>
>>> Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
>>> ---
>>>
>>> Considering that the datagram receive routine also doesn't go the sleep
>>> with the mutex held anymore, the 37ab4fa7844a044dc21fde45e2a0fc2f3c3b6490
>>> change to unix_autobind is now similarly purposeless.
>>
>> I wouldn't do this conversion, yet. There is still a deadlock lingering
>> around which should be solved earlier:
>>
>> http://lists.openwall.net/netdev/2015/11/10/4
>>
>> Unfortunately I haven't found a good way how to solve it, yet.
> 
> Judging from the link, that's not related to the stream receive code.
> 

No, but to commit 37ab4fa7844a044dc21fde45e2a0fc2f3c3b6490 where the
mutexes of unix_bind and unix_autobind got changed.

The unix_stream_read_generic conversion is fine.

Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>

Thanks,
Hannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] af_unix: Revert 'lock_interruptible' in stream receive code Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2015-12-16 21:10 +0100
  Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive  code Hannes Frederic Sowa <hannes@stressinduktion.org> - 2015-12-17 10:30 +0100
    Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2015-12-17 16:30 +0100
      Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive  code Hannes Frederic Sowa <hannes@stressinduktion.org> - 2015-12-17 16:50 +0100
    Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2015-12-18 00:30 +0100
      splice-bind deadlock (was: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code) Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2015-12-18 17:10 +0100
  Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive  code David Miller <davem@davemloft.net> - 2015-12-17 21:40 +0100

csiph-web