From: Jason Gunthorpe <jgg@ziepe.ca>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Steven Sistare <steven.sistare@oracle.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH] vfio/type1: Cleanup remaining vaddr removal/update fragments
Date: Mon, 12 Dec 2022 20:11:19 -0400 [thread overview]
Message-ID: <Y5fDJ6KkkAYj7tCQ@ziepe.ca> (raw)
In-Reply-To: <20221212170424.204bdb9a.alex.williamson@redhat.com>
On Mon, Dec 12, 2022 at 05:04:24PM -0700, Alex Williamson wrote:
> > > The decision to revert was based on the current interface being buggy,
> > > abandoned, and re-implemented. It doesn't seem that there's much future
> > > for the current interface, but Steve has stepped up to restrict the
> > > current implementation to non-mdev devices, which resolves your concern
> > > regarding unlimited user blocking of kernel threads afaict, and we'll
> > > see what he does with locked memory.
> >
> > Except nobody has seen this yet, and it can't go into 6.2 at this
> > point (see Linus's rather harsh remarks on late work for v6.2)
>
> We already outlined earlier in this thread the criteria that prompted
> us to tag the revert for stable, which was Steve's primary objection in
> the short term.
I still don't understand this, everyone running a distro deals with
the stuff. Even if you do blindly pull from a -stable branch instead
of cherry picking you only have to do the revert-revert once. Git is
good at this stuff.
Plus I have a doubt after all the backporting required to get vfio to
the required state that -stable patches are even going to work
anyhow..
> I can't in good faith push forward with a revert, including stable,
> if Steve is working on a proposal to resolve the issues prompting us
> to accelerate the code removal. Depending on the scope of Steve's
> proposal, I think we might be able to still consider this a fix for
> v6.2. Thanks,
Well, IMHO, you are better to send it for v6.2-rc1 than try to squeeze
it into this merge window and risk Linus's wrath
Jason
prev parent reply other threads:[~2022-12-13 0:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-07 21:45 [PATCH] vfio/type1: Cleanup remaining vaddr removal/update fragments Alex Williamson
2022-12-07 23:21 ` Jason Gunthorpe
2022-12-08 7:56 ` Tian, Kevin
2022-12-08 16:40 ` Alex Williamson
2022-12-09 18:40 ` Steven Sistare
2022-12-09 19:42 ` Alex Williamson
2022-12-09 19:52 ` Steven Sistare
2022-12-09 21:01 ` Alex Williamson
2022-12-10 14:14 ` Steven Sistare
2022-12-12 13:17 ` Jason Gunthorpe
2022-12-12 13:54 ` Steven Sistare
2022-12-12 15:58 ` Alex Williamson
2022-12-12 20:59 ` Steven Sistare
2022-12-12 21:26 ` Alex Williamson
2022-12-12 23:08 ` Jason Gunthorpe
2022-12-12 23:29 ` Alex Williamson
2022-12-12 23:35 ` Jason Gunthorpe
2022-12-13 0:04 ` Alex Williamson
2022-12-13 0:11 ` Jason Gunthorpe [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y5fDJ6KkkAYj7tCQ@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alex.williamson@redhat.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=steven.sistare@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox