netdev - Re: "af_unix: conditionally use freezable blocking calls in read" is wrong

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMbhsRSJq2WsOiT=Cw+OoO4EFX7ipr9pejECvVfec2k3HGmkdQ@mail.gmail.com>
Date:   Tue, 6 Dec 2016 10:37:52 -0800
From:   Colin Cross <ccross@...roid.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        David Miller <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: "af_unix: conditionally use freezable blocking calls in read" is wrong

On Mon, Dec 5, 2016 at 8:24 PM, Cong Wang <xiyou.wangcong@...il.com> wrote:
> On Sun, Dec 4, 2016 at 7:52 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>> On Sun, Dec 04, 2016 at 09:42:14PM -0500, David Miller wrote:
>>> >     I've run into that converting AF_UNIX to generic_file_splice_read();
>>> > I can kludge around that ("freezable unless ->msg_iter is ITER_PIPE"), but
>>> > that only delays trouble.
>>> >
>>> >     Note that the only other user of freezable_schedule_timeout() is
>>> > a very different story - it's a kernel thread, which *does* have a guaranteed
>>> > locking environment.  Making such assumptions in unix_stream_recvmsg(),
>>> > OTOH, is insane...
>>>
>>> We have to otherwise Android phones drain their batteries in 10
>>> minutes.
>>>
>>> I'm not going to revert this and be responsible for that.

This is an optimization for going in and out of suspend without
context switching through blocked processes, reverting it will not
cause batteries to drain in 10 minutes.  On my phone, it would cause
~83 context switches on each transition in and out of suspend, which
sometimes happens every 1-5 seconds on noisy networks, but more
normally happens on the order of minutes.

>>>
>>> So you have to find a way to make the freezable calls legitimate.
>>
>> Oh, well...  As I said, I can kludge around that - call from
>> generic_file_splice_read() can be distinguished by looking at the
>> ->msg_iter->type; it still means unpleasantness for kernel_recvmsg()
>> users - in effect, it can only be called with locks held if you know that
>> the socket is not an AF_UNIX one.
>>
>> BTW, how do they deal with plain pipes?
>
> I suppose this question is for Colin. ;)

The original patch set is at https://lkml.org/lkml/2013/4/29/495.  It
was targeted to the sites on which many threads were blocked on an
Android device, pipe_wait didn't show up high on the list (there is
only 1 thread blocked on pipe_wait on my phone right now), so I didn't
look at it.