mbox series

[GIT,PULL] XArray for 6.6

Message ID ZPtdbS6FTadc3LVA@casper.infradead.org (mailing list archive)
State New
Headers show
Series [GIT,PULL] XArray for 6.6 | expand

Pull-request

git://git.infradead.org/users/willy/xarray.git tags/xarray-6.6

Message

Matthew Wilcox Sept. 8, 2023, 5:44 p.m. UTC
I had to update the expiration on my signing key.  I don't know if you
pay attention to that, or whether my attempts to get my updated expiration
date into the system were successful.

The following changes since commit f837f0a3c94882a29e38ff211a36c1c8a0f07804:

  Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux (2023-07-28 11:21:57 -0700)

are available in the Git repository at:

  git://git.infradead.org/users/willy/xarray.git tags/xarray-6.6

for you to fetch changes up to 2a15de80dd0f7e04a823291aa9eb49c5294f56af:

  idr: fix param name in idr_alloc_cyclic() doc (2023-09-05 19:01:38 -0400)

----------------------------------------------------------------
XArray/IDA updates for 6.6

 - Fix a bug encountered by people using bittorrent where they'd get
   NULL pointer dereferences on page cache lookups when using XFS

 - Two documentation fixes

----------------------------------------------------------------
Ariel Marcovitch (1):
      idr: fix param name in idr_alloc_cyclic() doc

Matthew Wilcox (Oracle) (1):
      XArray: Do not return sibling entries from xa_load()

Philipp Stanner (1):
      xarray: Document necessary flag in alloc functions

 include/linux/xarray.h                | 18 ++++++++++
 lib/idr.c                             |  2 +-
 lib/xarray.c                          |  8 ++++-
 tools/testing/radix-tree/multiorder.c | 68 +++++++++++++++++++++++++++++++++--
 4 files changed, 92 insertions(+), 4 deletions(-)

Comments

Linus Torvalds Sept. 9, 2023, 4:57 a.m. UTC | #1
On Fri, 8 Sept 2023 at 10:44, Matthew Wilcox <willy@infradead.org> wrote:
>
> I had to update the expiration on my signing key.  I don't know if you
> pay attention to that, or whether my attempts to get my updated expiration
> date into the system were successful.

I'm sadly much too used (resigned?) to pgp keys being expired, so I
mostly ignore it, apart from the occasional internal swearing at
people who thought it was ever a good idea.

So exactly because the pgp key server infrastructure works so badly
these days, may I suggest either getting rid of expiration dates, or
at least putting them *far* in the future?

Honestly, the argument for expiration dates was never very strong, and
with how badly updates work, the constant low-grade annoyance from
them isn't worth it.

Because no, a "gpg --refresh" certainly did *not* get any expiration
day updates here. So your key does indeed show that it is expired for
me.

Which just should drive home how #$!* useless those expiration dates
are. Really.

So again - please stop expiring your keys, at least in any foreseeable
near future. The pgp key infrastructure isn't set up for it.

Make the expiration date go away, or make it a decade or two in the
future, and maybe it will show as active and valid some day.

               Linus
pr-tracker-bot@kernel.org Sept. 9, 2023, 5:05 a.m. UTC | #2
The pull request you sent on Fri, 8 Sep 2023 18:44:13 +0100:

> git://git.infradead.org/users/willy/xarray.git tags/xarray-6.6

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3095dd99dd759a5cab8bb81674bc133b1365fb6b

Thank you!