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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 87D7EC43331 for ; Thu, 5 Sep 2019 18:33:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8ADFD20825 for ; Thu, 5 Sep 2019 18:33:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387891AbfIESdU (ORCPT ); Thu, 5 Sep 2019 14:33:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41346 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391294AbfIESdT (ORCPT ); Thu, 5 Sep 2019 14:33:19 -0400 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB4BB7CB80 for ; Thu, 5 Sep 2019 18:33:18 +0000 (UTC) Received: by mail-wr1-f72.google.com with SMTP id f18so1372857wro.19 for ; Thu, 05 Sep 2019 11:33:18 -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=JkgFvZx1SpfRB54bm11+3DOumUuDokZW525XdQCPb+E=; b=q94w1/u/zp7YixExdQAVpEt2NCjW8tXY/mF3W+dVDY9X68x8wVu3woiuFzZTQV0o3x KuTcqQRoDABJknWdkp2mcRhlWsmkF1J1lVT1xw7fTtw8Awyk2YgWfXQzTy8W4h+JecpT 76YN3OniOV4WGKPCZUyhJRByB2Tq7Zz6v1/ojhkyNF/w8PVhL7YqwghfSWmAWltm/WJL vFey36/b50+2UklSOTh4WacV31w7oNcDjIt8aa4UZfwgUWwbPEqYWYGPTYR5zyV1OJQn ardv3wG4YfaHibqP47psVyxxYc/eb4x7r3NBaZJRSfMb8p9R1EdbCyOQUcOMHSinCIUL 8YgA== X-Gm-Message-State: APjAAAUXY2oMXPfdm7GP6QJmed64F72iRgrBhh4H9ZVAhfwXWDEDkAAF Teq+ye1m+h1g2SXKnmHZ+FY14c48/uqZ/hPXRpT2SAzOi2YCwVawOLi1f9RmfW6OXvwt0HsafFD ghqJNGM2FoBjFakAKteBYxKMMyY6fhxI0obU3hGKj X-Received: by 2002:a5d:568c:: with SMTP id f12mr3942180wrv.248.1567708397324; Thu, 05 Sep 2019 11:33:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqzmOECwYwtvafDfOc5sH/mM1xRRq5odIdcrX+xDOVM3wNnjyolmP+riNwHwlSKTnHua2vRyqquS9BP4i+1k7Ig= X-Received: by 2002:a5d:568c:: with SMTP id f12mr3942141wrv.248.1567708396973; Thu, 05 Sep 2019 11:33:16 -0700 (PDT) MIME-Version: 1.0 References: <156763534546.18676.3530557439501101639.stgit@warthog.procyon.org.uk> <17703.1567702907@warthog.procyon.org.uk> In-Reply-To: From: Ray Strode Date: Thu, 5 Sep 2019 14:32:40 -0400 Message-ID: Subject: Re: Why add the general notification queue and its sources To: Linus Torvalds Cc: David Howells , Greg Kroah-Hartman , Steven Whitehouse , Nicolas Dichtel , raven@themaw.net, keyrings@vger.kernel.org, linux-usb@vger.kernel.org, linux-block , Christian Brauner , LSM List , linux-fsdevel , Linux API , Linux List Kernel Mailing , Al Viro , "Ray, Debarshi" , Robbie Harwood Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Sep 5, 2019 at 1:20 PM Linus Torvalds wrote: > You've at least now answered part of the "Why", but you didn't > actually answer the whole "another developer" part. It's certainly something we've wanted in the GNOME world for a long time: See for instance https://bugzilla.redhat.com/show_bug.cgi?id=991110 and https://bugzilla.gnome.org/show_bug.cgi?id=707402 from all the way back 2013. These are the alternatives I can think of: - poll? status quo, but not great for obvious wakeup reasons - use a different credential cache collection type that does support change notification? some of the other types do support change notification, but have their own set of problems. But maybe we should just go back to DIR type credential cache collections and try to figure out the life cycle problems they pose, i don't know... or get more man power behind KCM... - manage change notification entirely from userspace. assume credentials will always be put in place from krb5-libs entry points, and just skip notification if it happens out from under the libraries. maybe upstream kerberos guys would be onboard with this, I don't know. This seems less robust than having the kernel in the loop, though. > I really don't like how nobody else than you seems to even look at any > of the key handling patches. Because nobody else seems to care. I've got no insight here, so i'll just throw a dart... viro, is this something you have any interest in watching closer? > See what I'm saying? This whole "David Howells does his own features > that nobody else uses" needs to stop. You need to have a champion. I > just don't feel safe pulling these kinds of changes from you, because > I get the feeling that ABSOLUTELY NOBODY ELSE ever really looked at it > or really cared. I get the "one man is not enough for proper maintenance" argument, and maybe it's true. I don't know. But I just want to point out, I have been asking dhowells for this change notification API for years, so it's not something he did on his own and for no particularly good reason. It solves a real problem and has a real-world use case. He kindly did it because I (and Robbie Harwood and others) asked him about it, off and on, and he was able to fit it onto his priority list for us. >From this thread, it sounds like he solved a problem for Greg too, killing a couple birds with one stone? --Ray