Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp4552200imb; Wed, 6 Mar 2019 16:44:03 -0800 (PST) X-Google-Smtp-Source: APXvYqyvrj1hkhSVmLD9UfTRJowqLIEB5EMHwd/rZMrmn8tepMRoqv4RzLpkwMbPhbkYrXFsa77P X-Received: by 2002:a63:5813:: with SMTP id m19mr8925288pgb.294.1551919442991; Wed, 06 Mar 2019 16:44:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551919442; cv=none; d=google.com; s=arc-20160816; b=BraX5rmPHgaT1jWBHTUgE7xgiW3zNOswviFBeK0BthRxIeQwS+EdnhmEYxDaI/HdQf ZvTfYHSyrxoAYwI215LhtKKwjFFyDQd4Zu+YhtfAbBvx39SEgKLb0+I7PcsYTic/iAnS DGDTt416BsYJBZPsKIUmUsm4fLTYU/lxiF4gtrLveUVWu/HRWfgLgpljQgZ5Gs6gtiME +N85t3MOqxuN/EQ4o56+IkSjczrqI2P+sAuTwrcJUd6CvUTqXtJ7tzCN8egCpc3t+hk7 jZ5MhC2hIonsR+oK34pQBkDiLjtt1mLIXJnv62+CFlE0Bqw17uOa5IMr0e9qQi3oxz4O 4Liw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=NgcADOa+4YYJZlXhGKRSCuuBE8tudCXPb0DmswVd3Ig=; b=EkbuQ4enE3GFHeOXJ94A+lzieAkQfp/5hmOq0PX3XukyBp5c6Rg8z2R2KmiopVUhlr QxeyG2gCQZ1b4qkQOXpnK8vROf0BdcxXhYKADpREUDPvyGdEPCCeiMuUuFNEufkBQQSC BkL2QehS8FYcOlcLsctbryugu742AAE8dNIBrP6z+UuqFsdpx8ofjCoMWfNSiIlRhXSS 0ZqmZ94GcQ99wrF+cEdZ32xZXXoEpFZaoH1Ri1KXXMBL2xZFpyZ4OZf4OonzWruGrE9a O9eZ9BsWObx5F5pibjeySZk6qIosNzPXoixifqZvs5F5N4ZwLu4z9a8e3Gpz5Zt6d3o6 R7Eg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ay1si2700113plb.165.2019.03.06.16.43.47; Wed, 06 Mar 2019 16:44:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726441AbfCGAmM (ORCPT + 99 others); Wed, 6 Mar 2019 19:42:12 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:40556 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726127AbfCGAmM (ORCPT ); Wed, 6 Mar 2019 19:42:12 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1h1h6l-0000hR-Vr; Thu, 07 Mar 2019 00:42:00 +0000 Date: Thu, 7 Mar 2019 00:41:59 +0000 From: Al Viro To: Linus Torvalds Cc: Eric Dumazet , David Miller , Jason Baron , kgraul@linux.ibm.com, ktkhai@virtuozzo.com, kyeongdon kim , Linux List Kernel Mailing , Netdev , pabeni@redhat.com, syzkaller-bugs@googlegroups.com, Cong Wang , Christoph Hellwig , zhengbin , bcrl@kvack.org, linux-fsdevel , linux-aio@kvack.org, houtao1@huawei.com, yi.zhang@huawei.com Subject: Re: [PATCH 1/8] aio: make sure file is pinned Message-ID: <20190307004159.GY2217@ZenIV.linux.org.uk> References: <20190307000316.31133-1-viro@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 06, 2019 at 04:23:04PM -0800, Linus Torvalds wrote: > On Wed, Mar 6, 2019 at 4:03 PM Al Viro wrote: > > > > From: Al Viro > > > > "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 ;-/