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 71644C43331 for ; Thu, 5 Sep 2019 18:33:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7943A20825 for ; Thu, 5 Sep 2019 18:33:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730223AbfIESdU (ORCPT ); Thu, 5 Sep 2019 14:33:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25294 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388188AbfIESdT (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 A8F5F8830E for ; Thu, 5 Sep 2019 18:33:18 +0000 (UTC) Received: by mail-wr1-f72.google.com with SMTP id o11so1362240wrq.22 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=EluxUkl8JR2Eg2uV/ecZBTjnW9dyT2cqzx0MScUM0t6hcSAyN+/CrOhJ73uMquFEjp bifwxUNgcbilbPPo5SpYcAEDsR0cekPdZg+3VXHEzoguTwkb5ShtULETZ5rJzPyoiAqY RhU8eSx+mO+7P/IJ1pk/n0zdw2UkPt++ZvhCY40BxN2PQU/G2smf/mNDYKBK2GzURf/s fmUaK+mzTD55WldhbL7y5RCJfYLbLhxATQg8mLQdFSkJoDQ2G9O9IWzHuf0f94ooZvHP mvHpP8XgqzSCGA4iAFbCYGA62L1pMOuOFkwK3BG+b1htr5PfU0GMXEwOUFrM5QG506fE vNvA== X-Gm-Message-State: APjAAAXvtgPKi9qQrsSaYrFnbrgDhl2+xekeOOYpLYfm6t43VtZaAjMl aYgXN4EaRqKg/LZ1Fu7vlloEZNYicspGO0C+jPzD/2MGM2IbM4ooArnmavwyDCXwzeuTGtn3Pkb zgLLvN/+5Z+jgqSq1vbmIitcy8YpaYS31Nt9R8DVKJg== X-Received: by 2002:a5d:568c:: with SMTP id f12mr3942169wrv.248.1567708397318; 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-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@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