From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6811C433E2 for ; Fri, 11 Sep 2020 01:12:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B38BA2083B for ; Fri, 11 Sep 2020 01:12:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725468AbgIKBMK (ORCPT ); Thu, 10 Sep 2020 21:12:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725300AbgIKBMJ (ORCPT ); Thu, 10 Sep 2020 21:12:09 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E5EAC061573; Thu, 10 Sep 2020 18:12:08 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGXbh-00E2kB-Ba; Fri, 11 Sep 2020 01:12:05 +0000 Date: Fri, 11 Sep 2020 02:12:05 +0100 From: Al Viro To: Jens Axboe Cc: linux-fsdevel , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] pipe: honor IOCB_NOWAIT Message-ID: <20200911011205.GG1236603@ZenIV.linux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Sep 07, 2020 at 09:21:02AM -0600, Jens Axboe wrote: > Pipe only looks at O_NONBLOCK for non-blocking operation, which means that > io_uring can't easily poll for it or attempt non-blocking issues. Check for > IOCB_NOWAIT in locking the pipe for reads and writes, and ditto when we > decide on whether or not to block or return -EAGAIN. > > Signed-off-by: Jens Axboe > > --- > > If this is acceptable, then I can add S_ISFIFO to the whitelist on file > descriptors we can IOCB_NOWAIT try for, then poll if we get -EAGAIN > instead of using thread offload. Will check. In the meanwhile, blacklist eventpoll again. Because your attempts at "nonblocking" there had been both ugly as hell *AND* fail to prevent blocking. And frankly, I'm very tempted to rip that crap out entirely. Seriously, *look* at the code you've modified in do_epoll_ctl(). And tell me why the hell is grabbing ->mtx in that function needs to be infested with trylocks, while exact same mutex taken in loop_check_proc() called under those is fine with mutex_lock(). Ditto for calls of vfs_poll() inside ep_insert(), GFP_KERNEL allocations in ep_ptable_queue_proc(), synchronize_rcu() callable from ep_modify() (from the same function), et sodding cetera. No, this is _not_ an invitation to spread the same crap over even more places in there; I just want to understand where had that kind of voodoo approach comes from. And that's directly relevant for this patch, because it looks like the same kind of thing. What is your semantics for IOCB_NOWAIT? What should and what should _not_ be waited for?