Merge tag 'gfs2-v6.8-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 (2024-03-25 10:53:39 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-v6.9-rc2
for you to fetch changes up to 6999f8229e5998e8286e6a960779b6c202d878da:
keys: Fix overwrite of key expiration on instantiation (2024-03-26 16:24:53 +0200)
----------------------------------------------------------------
Hi,
This pull request contains just a couple of unintrusive changes for
v6.9.
Note that "keys: update key quotas in key_put()" makes quotas less racy
by updating qnkeys and qnbytes already in key_put(). It is not exactly a
bug fix but does make overall kerrnel behaviour more stable and
consistent. Just adding this because I try to keep follow-up PR's for
kernel releases bug fix only but I think here it makes sense to make an
exception.
BR, Jarkko
----------------------------------------------------------------
Luis Henriques (1):
keys: update key quotas in key_put()
Silvio Gissi (1):
keys: Fix overwrite of key expiration on instantiation
security/keys/gc.c | 8 --------
security/keys/key.c | 35 ++++++++++++++++++++++++-----------
security/keys/keyctl.c | 11 ++++++-----
3 files changed, 30 insertions(+), 24 deletions(-)
On Tue, 26 Mar 2024 at 07:38, Jarkko Sakkinen <[email protected]> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-v6.9-rc2
So I haven't pulled this, because the subject line (and tag name)
talks about tpmdd, but this is clearly about key handling.
Also, the actual contents seem to be very much an "update", not fixes.
And it doesn't seem to be an actual improvement, in how it now does
things from interrupts. That seems to be going backward rather than
forward.
Linus
On Sun Mar 31, 2024 at 12:32 AM EET, Linus Torvalds wrote:
> On Tue, 26 Mar 2024 at 07:38, Jarkko Sakkinen <[email protected]> wrote:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-v6.9-rc2
>
> So I haven't pulled this, because the subject line (and tag name)
> talks about tpmdd, but this is clearly about key handling.
OK, point taken and it is evolutionary issue really but definitely
needs to be fixed.
I review and test most of the stuff that goes to keyring but other
than trusted keys, I usually pick only few patches every now and
then to my tree.
So obviously we need better grounds for putting this content together.
So probably fastest path to that would be if e.g. David just opens me
push rights to his tree, and then i push the stuff that makes sense
to me to some branch in that tree.
In other words: David would take care of sending the final PR.
As per trusted keys, should I start to make a separate "trusted keys
PR" with its own separate tag? It's fine with me but I just need to
know how to move forward. E.g. now there is one new hardware backend
upcoming for trusted keys so now it is good to realig if any need.
>
> Also, the actual contents seem to be very much an "update", not fixes.
> And it doesn't seem to be an actual improvement, in how it now does
> things from interrupts. That seems to be going backward rather than
> forward.
That's fine and can cope with this np but yeah the first paragraph is
something we need to tackle now :-)
>
> Linus
BR, Jarkko
On Sun Mar 31, 2024 at 8:57 AM EEST, Jarkko Sakkinen wrote:
> On Sun Mar 31, 2024 at 12:32 AM EET, Linus Torvalds wrote:
> > On Tue, 26 Mar 2024 at 07:38, Jarkko Sakkinen <[email protected]> wrote:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-v6.9-rc2
> >
> > So I haven't pulled this, because the subject line (and tag name)
> > talks about tpmdd, but this is clearly about key handling.
>
> OK, point taken and it is evolutionary issue really but definitely
> needs to be fixed.
>
> I review and test most of the stuff that goes to keyring but other
> than trusted keys, I usually pick only few patches every now and
> then to my tree.
>
> So obviously we need better grounds for putting this content together.
> So probably fastest path to that would be if e.g. David just opens me
> push rights to his tree, and then i push the stuff that makes sense
> to me to some branch in that tree.
>
> In other words: David would take care of sending the final PR.
>
> As per trusted keys, should I start to make a separate "trusted keys
> PR" with its own separate tag? It's fine with me but I just need to
> know how to move forward. E.g. now there is one new hardware backend
> upcoming for trusted keys so now it is good to realig if any need.
Also using separate tag works for me. These changes are synced
in all cases (I sync up with David or vice-versa) so that is
equally good as far as I'm concerned.
BR, Jarkko
On Sat, 30 Mar 2024 at 22:57, Jarkko Sakkinen <[email protected]> wrote:
>
> OK, point taken and it is evolutionary issue really but definitely
> needs to be fixed.
>
> I review and test most of the stuff that goes to keyring but other
> than trusted keys, I usually pick only few patches every now and
> then to my tree.
It's perfectly fine if you send me key updates - you're listed as
maintainer etc, that's not a problem.
But when I get a tag name that says "tpmdd" and a subject that says
"tpmdd", I'm noty expecting to then see key updates in the pull.
So that part of my issue was literally just that your subject line and
tag name didn't match the contents, and that just makes me go "there's
something wrong here".
So keys coming through your tree is fine per se, it's just that I want
the subject line etc to actually make sense.
Linus
On Sun Mar 31, 2024 at 8:01 PM EEST, Linus Torvalds wrote:
> On Sat, 30 Mar 2024 at 22:57, Jarkko Sakkinen <[email protected]> wrote:
> >
> > OK, point taken and it is evolutionary issue really but definitely
> > needs to be fixed.
> >
> > I review and test most of the stuff that goes to keyring but other
> > than trusted keys, I usually pick only few patches every now and
> > then to my tree.
>
> It's perfectly fine if you send me key updates - you're listed as
> maintainer etc, that's not a problem.
>
> But when I get a tag name that says "tpmdd" and a subject that says
> "tpmdd", I'm noty expecting to then see key updates in the pull.
>
> So that part of my issue was literally just that your subject line and
> tag name didn't match the contents, and that just makes me go "there's
> something wrong here".
>
> So keys coming through your tree is fine per se, it's just that I want
> the subject line etc to actually make sense.
>
> Linus
OK, I'll we'll address no problem :-) I think separate tag and
appropriate subject line is sufficient change as we always sync
up with these (through IRC channel), i.e. David is aware when
I send anything keyring specific.
BR, Jarkko