All of
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Thomas Gleixner <>,
	Zhangfei Gao <>,
	Fenghua Yu <>,
	Jean-Philippe Brucker <>,
	Jacob Pan <>,
	Dave Hansen <>
Cc: Linux Kernel Mailing List <>,
	"the arch/x86 maintainers" <>
Subject: Re: [GIT pull] core/urgent for v5.18-rc6
Date: Sun, 8 May 2022 11:00:17 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <165201148069.536527.1960632033331546251.tglx@xen13>

On Sun, May 8, 2022 at 5:05 AM Thomas Gleixner <> wrote:
> A single bugfix for the PASID management code, which freed the PASID too
> early. The PASID needs to be tied to the mm lifetime, not to the address
> space lifetime.

So I have to once more complain about the -tip tree "Link:" usage.

Again, the commit has a link to the patch *submission*, which is
almost entirely useless. There's no link to the actual problem the
patch fixes.

It does have a "Fixes:" link, and it has an "explanation", but the
explanation doesn't actually make much sense to me.

The *sensible* thing for an iommu driver to do is to just do a
mmget/mmput, and then the whole "drop PASIX on last mmput() (ie in
__mmput)" makes lots of sense.

The commit claims that's not what the iommu drivers do, but it's
really hard to tell *what* it is that does a mmgrab. It just says

  "the IOMMU driver holds a reference on the mm itself, not the address space"

but then I tried to see where such references are held, and I couldn't find it.

*Must* users do mmget/mmput, and the commit even says that's the
logical thing to do. Apparently something that the iommu code relies
on does the mmgrab/mmdrop thing, but I really would have liked to know
what that is.

Yes, "mmgab" is the right thing to do if all you want is the "struct
mm_struct", and don't actually care about the page tables themselves,
and don't want to have the refcount keep page tables alive. But you'd
think the iommu code really does want the page tables.

So it would have been really nice to have an explanation for what it
was that did the mmgrab, especially since the commit itself makes it
clear that the logical thing to do seems to be just mmget/put. No?

I _really_ wish the -tip tree had more links to the actual problem
reports and explanations, rather than links to the patch submission.

One has the actual issue. The other just has the information that is
already in the commit, and the "Link:" adds almost no actual value
(yes, yes, you can see late "Acked-by" etc, but that really isn't
worth it).

I've pulled this, because I definitely believe the issue is real. I
just wish I could see _what_ the issue was.

Put another way: I can see that

    Reported-by: Zhangfei Gao <>

in the commit, but I don't have a clue what the actual report was, and
there really isn't enough information in the commit itself, except for
a fairly handwavy "Device drivers might, for instance, still need to
flush operations.."

I don't want to know what device drivers _might_ do. I would want to
have an actual pointer to what they do and where.

I suspect it's related to mmu_notifiers or something, but I really
would have liked a more exact "this is where things go wrong".

I also *suspect* that this is all about that _loong_ thread (picking
one email almost at random) here:

but if so, the confusion I see in that thread is even more reason to
have more background for what is going on.

Anyway, this is merged in my tree, but I'm having trouble following
the logic, which is why I'm writing this long email to complain about
lack of context.


  parent reply	other threads:[~2022-05-08 19:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-08 12:05 [GIT pull] core/urgent for v5.18-rc6 Thomas Gleixner
2022-05-08 12:05 ` [GIT pull] irq/urgent " Thomas Gleixner
2022-05-08 18:40   ` pr-tracker-bot
2022-05-08 12:05 ` [GIT pull] locking/urgent " Thomas Gleixner
2022-05-08 18:40   ` pr-tracker-bot
2022-05-08 12:05 ` [GIT pull] timers/urgent " Thomas Gleixner
2022-05-08 18:40   ` pr-tracker-bot
2022-05-08 12:07 ` [GIT pull] x86/urgent " Thomas Gleixner
2022-05-08 18:40   ` pr-tracker-bot
2022-05-08 18:00 ` Linus Torvalds [this message]
2022-05-08 18:09   ` [GIT pull] core/urgent " Linus Torvalds
2022-05-08 18:36     ` Linus Torvalds
2022-05-09 15:02       ` Jean-Philippe Brucker
2022-05-10 11:27   ` Link: tag and links to submission and reports (was: Re: [GIT pull] core/urgent for v5.18-rc6) Thorsten Leemhuis
2022-05-11  8:37     ` Borislav Petkov
2022-05-11 13:48       ` Michael Ellerman
2022-05-11 15:50       ` Theodore Ts'o
2022-05-11 15:55         ` Linus Torvalds
2022-05-11 19:35           ` Borislav Petkov
2022-05-12  8:43             ` Thorsten Leemhuis
2022-08-04  9:29               ` Borislav Petkov
2022-05-11 22:37           ` Theodore Ts'o
2022-05-08 18:40 ` [GIT pull] core/urgent for v5.18-rc6 pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.