[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190307004159.GY2217@ZenIV.linux.org.uk>
Date: Thu, 7 Mar 2019 00:41:59 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>,
Jason Baron <jbaron@...mai.com>, kgraul@...ux.ibm.com,
ktkhai@...tuozzo.com, kyeongdon kim <kyeongdon.kim@....com>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>, pabeni@...hat.com,
syzkaller-bugs@...glegroups.com,
Cong Wang <xiyou.wangcong@...il.com>,
Christoph Hellwig <hch@....de>,
zhengbin <zhengbin13@...wei.com>, bcrl@...ck.org,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-aio@...ck.org, houtao1@...wei.com, yi.zhang@...wei.com
Subject: Re: [PATCH 1/8] aio: make sure file is pinned
On Wed, Mar 06, 2019 at 04:23:04PM -0800, Linus Torvalds wrote:
> On Wed, Mar 6, 2019 at 4:03 PM Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > From: Al Viro <viro@...iv.linux.org.uk>
> >
> > "aio: remove the extra get_file/fput pair in io_submit_one" was
> > too optimistic - not dereferencing file pointer after e.g.
> > ->write_iter() returns is not enough; that reference might've been
> > the only thing that kept alive objects that are referenced
> > *before* the method returns. Such as inode, for example...
>
> I still; think that this is actually _worse_ than just having the
> refcount on the req instead.
>
> As it is, we have that completely insane "ref can go away from under
> us", because nothing keeps that around, which then causes all those
> other crazy issues with "woken" etc garbage.
>
> I think we should be able to get rid of those entirely. Make the
> poll() case just return zero if it has added the entry successfully to
> poll queue. No need for "woken", no need for all that odd "oh, but
> now the req might no longer exist".
Not really. Sure, you can get rid of "might no longer exist"
considerations, but you still need to decide which way do we want to
handle it. There are 3 cases:
* it's already taken up; don't put on the list for possible
cancel, don't call aio_complete().
* will eventually be woken up; put on the list for possible
cancle, don't call aio_complete().
* wanted to be on several queues, fortunately not woken up
yet. Make sure it's gone from queue, return an error.
* none of the above, and ->poll() has reported what we wanted
from the very beginning. Remove from queue, call aio_complete().
You'll need some logics to handle that. I can buy the "if we know
the req is still alive, we can check if it's still queued instead of
separate woken flag", but but it won't win you much ;-/
Powered by blists - more mailing lists