Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp347539ybt; Sat, 13 Jun 2020 06:26:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+v7XegfqA5vD14qOtHv9Th2DLIhTWgss3gbQIdQGdbDfD+7uJOWMv/KA2hKlvrz3wbSnB X-Received: by 2002:a17:906:4702:: with SMTP id y2mr17447456ejq.87.1592054783838; Sat, 13 Jun 2020 06:26:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592054783; cv=none; d=google.com; s=arc-20160816; b=ySTluwORyMT3KMqJ9SmSDgFVTgJSvEZIci8F/dt7f8mJolcekXJUYyZLpErA7AU8nR g3nAVq2Dhaa5hduB19nSP8EPLueNTMhWy9sKxCqZDT2GVLDOUxVZX5sfnpNJpSBhs9z3 qP46yKvj1Goxuc4tjBjhWbANCgJwZaewh+HvkT7PhmVXtXANaWMUP4rIYS0jwiAlQSyW YYhwVVmbs9ubVuIJRJIvXwjM+GdRTJQHV/GD17gGBL33baJ2QeuBaGwT0s/eupd4Vmub G66gNUDo2OPbJ7BkGQLL6lCZDIFMEsySkNF7+gbchtPw9PEfQZclBkjurJal9v0UgMIW SlgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:content-id:mime-version :subject:cc:to:references:in-reply-to:from:organization :dkim-signature; bh=njgs1r9galiF3MoU+Zrmic02k4Poj3Y0WKSsIgqKRd0=; b=neuIchJBOdXPdz0OrahiAkRaWT5px/l5jll8tU5KejNweC35uwfrsfAbZR9QchaEnX KdLpihoVLiC8wcdpf8kiqQkRNb19JY6ZETK5+vAS5sdWUiEVyFV1hyr20k9Dmc/b14iQ +KuDIqPlKBUlt4eUmp5gHSw5XGeaAJ39UU8RRyuXi7X/ardjz8YpXoWqinsLvjryNnjq mHYLAm43NymytAgOZr8Oh1cWCpz1qgCeOfI95yvuwbcz32c1x9n7axwnJKirXnXs9lho IblD7sIQ6eJk2/r9t9fPpH8iiMJTudNecy9KMKXn0AHFV/DV8npjpnH4xq9fOWW+JtXk ++vQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NnITedHc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z23si5635175ejw.331.2020.06.13.06.26.01; Sat, 13 Jun 2020 06:26:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NnITedHc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726407AbgFMNYL (ORCPT + 99 others); Sat, 13 Jun 2020 09:24:11 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:58612 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726392AbgFMNYL (ORCPT ); Sat, 13 Jun 2020 09:24:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592054649; 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=njgs1r9galiF3MoU+Zrmic02k4Poj3Y0WKSsIgqKRd0=; b=NnITedHc+l5kM/MvglHmWI1IZ52Z1XmiAW9SNDm58eVS7RbTuQcQc8KSIbesSmnYl0bAqc CRvT+SuY+uyCNW/vqS+xqQ3eaPAqYIkV+27RuHEu9lN1KRcDdT+T65fZPncW0Gl1RBYZMW yjUPlTJgFFWZ983wXK+rQg+knXlEhmI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-356-6lltXHwEPeyB9Co1zx3NPA-1; Sat, 13 Jun 2020 09:24:06 -0400 X-MC-Unique: 6lltXHwEPeyB9Co1zx3NPA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 690CA835B44; Sat, 13 Jun 2020 13:24:04 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-114-66.rdu2.redhat.com [10.10.114.66]) by smtp.corp.redhat.com (Postfix) with ESMTP id 06FBB60F88; Sat, 13 Jun 2020 13:24:01 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <1503686.1591113304@warthog.procyon.org.uk> <20200610111256.s47agmgy5gvj3zwz@ws.net.home> To: Linus Torvalds Cc: dhowells@redhat.com, Karel Zak , Al Viro , dray@redhat.com, Miklos Szeredi , Steven Whitehouse , Jeff Layton , Ian Kent , andres@anarazel.de, Christian Brauner , Jarkko Sakkinen , keyrings@vger.kernel.org, linux-fsdevel , Linux Kernel Mailing List Subject: Re: [GIT PULL] General notification queue and key notifications MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3986608.1592054641.1@warthog.procyon.org.uk> Date: Sat, 13 Jun 2020 14:24:01 +0100 Message-ID: <3986609.1592054641@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds wrote: > > All the next operations are done with "fd". It's nowhere used as a > > pipe, and nothing uses pipefd[1]. > > As an aside, that isn't necessarily true. > > In some of the examples, pipefd[1] is used for configuration (sizing > and adding filters), although I think right now that's not really > enforced, and other examples seem to have pipefd[0] do that too. The configuration can happen on either end of the pipe. I just need to be able to find the pipe object. > DavidH: should that perhaps be a hard rule, so that you can pass a > pipefd[0] to readers, while knowing that they can't then change the > kinds of notifications they see. You can argue that the other way: that it should be a hard rule that you can pass pipefd[1] to writers, whilst knowing that they can't then change the kind of notifications that the kernel can insert into the pipe. My feeling is that it's more likely that you would keep the read end yourself and give the write end away - if at all. Most likely, IMO, would be that you attach notification sources and never use the write end directly. There is some argument for making it so that the notification sources belong to the read end only and that they keep the write side alive internally - meaning that you can just close the write end. All the notification sources just then disappear when the read end is closed - but dup() might make this kind of tricky as there is only one pipe object and its shared between both ends. The existence of O_RDWR FIFOs might also make this tricky. > In the "pipe: Add general notification queue support" commit message, > the code example uses pipefd[0] for IOC_WATCH_QUEUE_SET_SIZE, but then > in the commit message for "watch_queue: Add a key/keyring notification > facility" it uses pipefd[1]. > > And that latter example does make sense: using the write-side > pipefd[1] for configuration, while the read-side pipefd[0] is the side > that sees the results. That is also how it would work if you have a > user-mode pipe with the notification source controlling the writing > side - the reading side can obviously not add filters or change the > semantics of the watches. > > So that allows a trusted side to add and create filters, while some > untrusted entity can then see the results. As stated above, I think you should be looking at this the other way round - you're more likely to keep the read end for yourself. If you attach multiple sources to a pipe, everything they produce comes out mixed together from the read end of the pipe. You might even pass the write end to multiple userspace-side event generators, but I'm not sure it would make sense to pass the read end around unless you have sufficient flow that you need multiple consumers to keep up with it. David