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

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

[Al Viro]

	Could we please kill that kludge?  "af_unix: use freezable blocking
calls in read" had been wrong to start with; having a method make assumptions
of that sort ("nobody will call me while holding locks I hadn't thought of")
is asking for serious trouble.  splice is just a place where lockdep has
caught that - we *can't* assume that nobody will ever call kernel_recvmsg()
while holding some locks.

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

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

[David Miller]

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Sun, 4 Dec 2016 21:04:55 +0000

> 	Could we please kill that kludge?  "af_unix: use freezable blocking
> calls in read" had been wrong to start with; having a method make assumptions
> of that sort ("nobody will call me while holding locks I hadn't thought of")
> is asking for serious trouble.  splice is just a place where lockdep has
> caught that - we *can't* assume that nobody will ever call kernel_recvmsg()
> while holding some locks.
> 
> 	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.

So you have to find a way to make the freezable calls legitimate.

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

[Al Viro]

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

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

[Cong Wang]

On Sun, Dec 4, 2016 at 7:52 PM, Al Viro <viro@zeniv.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.
>>
>> 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. ;)

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

[Colin Cross]

On Mon, Dec 5, 2016 at 8:24 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Sun, Dec 4, 2016 at 7:52 PM, Al Viro <viro@zeniv.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.