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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 C763AC433DF for ; Fri, 3 Jul 2020 09:45:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C71020723 for ; Fri, 3 Jul 2020 09:45:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="irV5u50v" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C71020723 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1A9628D0065; Fri, 3 Jul 2020 05:45:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 132498D0036; Fri, 3 Jul 2020 05:45:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3BAB8D0065; Fri, 3 Jul 2020 05:45:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by kanga.kvack.org (Postfix) with ESMTP id D9DFE8D0036 for ; Fri, 3 Jul 2020 05:45:44 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 60449181AC9CB for ; Fri, 3 Jul 2020 09:45:44 +0000 (UTC) X-FDA: 76996282608.29.land07_35038f126e90 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 37CA718086CA8 for ; Fri, 3 Jul 2020 09:45:44 +0000 (UTC) X-HE-Tag: land07_35038f126e90 X-Filterd-Recvd-Size: 4774 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Fri, 3 Jul 2020 09:45:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593769543; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=AA5KODddQ3HbG0ydkjTXDrfB0iva22PrfbR0RkgNHDk=; b=irV5u50vm0VEkKTDPDqhOwE/2mle/q8T9ktqBXfYGub35k1UVJvVFNQdmeBrzHm7Ky4CW1 MpsUWja6eP4MI39oCH0pYROBsZvQEYKLi5l2ntO/8naTsy2xUMjs00/gyQPKCKCs0aN0Vt GDm06/NxBaFKo3c236sZNLWbAoeddPU= Received: from mail-ot1-f71.google.com (mail-ot1-f71.google.com [209.85.210.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-489-3yS-KxQcMLSI5ryGoBpIGw-1; Fri, 03 Jul 2020 05:45:41 -0400 X-MC-Unique: 3yS-KxQcMLSI5ryGoBpIGw-1 Received: by mail-ot1-f71.google.com with SMTP id i4so3550855otr.22 for ; Fri, 03 Jul 2020 02:45:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AA5KODddQ3HbG0ydkjTXDrfB0iva22PrfbR0RkgNHDk=; b=n5R6/rN8e4xqnlLk10ajjKPd4WZRKDPTDQ3xkWykLf7G0yAqOQbnKwnMte2qhuYC66 K1B4EF990+8HKqe5RzI+ekmR4EHOeQgUkoE6AABsab0Vekmg+3wIsOPH3wkLRg7Hh1mZ Aw+JwXAP0V1nqige+xyDQX1QlYPkaiRVULIQ4RNmKMj2J7a+kg4IdSHY0TsdLaYUOftJ zMLR96kfFtBtfTNDi0IHLPXnlEUX/apUy4ab2IqFMckeXWOI396eMa1GH/czOrN8g0GS hOmyIobX4JYETP6iZO9xwP1OioDXkUb4IdfCGTa0YbJJM5HnLgSsrgxiJwEUJLZn+kFK hh0g== X-Gm-Message-State: AOAM531MbNeTi0PcWuo5ybmlJsnuMEx0Ml9DSlXfPYud9PSTQYIAzzHu cb1VjveK1Adx2Faqxw7271CL4vhVASG8OYH3jPmX3wK0KFaMJpoyHkSyGjfac634Lkngi5Ops7V 6wMbHQowdAIx+B09+8ntwhmdTCIY= X-Received: by 2002:a05:6830:1c6e:: with SMTP id s14mr25164698otg.58.1593769540776; Fri, 03 Jul 2020 02:45:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+Ce/YV4Ri2FhaSPK6PoutDZUmwdOzBUZOLe5RemGei+boqUpH8/2S5wzAt2YXKDn+6fKVwICp10PF4itwpMQ= X-Received: by 2002:a05:6830:1c6e:: with SMTP id s14mr25164681otg.58.1593769540566; Fri, 03 Jul 2020 02:45:40 -0700 (PDT) MIME-Version: 1.0 References: <20200702165120.1469875-1-agruenba@redhat.com> <20200702165120.1469875-3-agruenba@redhat.com> In-Reply-To: From: Andreas Gruenbacher Date: Fri, 3 Jul 2020 11:45:29 +0200 Message-ID: Subject: Re: [RFC 2/4] fs: Add IOCB_NOIO flag for generic_file_read_iter To: Linus Torvalds Cc: Matthew Wilcox , Dave Chinner , linux-fsdevel , Linux-MM , Linux Kernel Mailing List Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=agruenba@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 37CA718086CA8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 2, 2020 at 10:18 PM Linus Torvalds wrote: > On Thu, Jul 2, 2020 at 12:58 PM Andreas Gruenbacher wrote: > > > Of course, if you want to avoid both new reads to be submitted _and_ > > > avoid waiting for existing pending reads, you should just set both > > > flags, and you get the semantics you want. So for your case, this may > > > not make any difference. > > > > Indeed, in the gfs2 case, waiting for existing pending reads should be > > fine. I'll send an update after some testing. > > Do note that "wait for pending reads" very much does imply "wait for > those reads to _complete_". > > And maybe the IO completion handler itself ends up having to finalize > something and take the lock to do that? > > So in that case, even just "waiting" will cause a deadlock. Not > because the waiter itself needs the lock, but because the thing it > waits for might possibly need it. > > But in many simple cases, IO completion shouldn't need any filesystem > locks. I just don't know the gfs2 code at all, so I'm not even going > to guess. I just wanted to mention it. Yes, that makes sense. Luckily gfs2 doesn't do any such locking on IO completion. Thanks, Andreas