From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Michael Thayer <michael.thayer@oracle.com>,
"Knut St . Osmundsen" <knut.osmundsen@oracle.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] virt: vbox: Implement passing requestor info to the host for VirtualBox 6.0.x
Date: Wed, 20 Mar 2019 19:19:34 +0100 [thread overview]
Message-ID: <20190320181934.GA3907@kroah.com> (raw)
In-Reply-To: <29c6e212-6233-364f-5a90-564f91bca989@redhat.com>
On Wed, Mar 20, 2019 at 10:52:05AM +0100, Hans de Goede wrote:
> Hi,
>
> On 20-03-19 10:46, Greg Kroah-Hartman wrote:
> > On Wed, Mar 20, 2019 at 10:35:19AM +0100, Hans de Goede wrote:
> > > VirtualBox 6.0.x has a new feature where the guest kernel driver passes
> > > info about the origin of the request (e.g. userspace or kernelspace) to
> > > the hypervisor.
> > >
> > > If we do not pass this information then when running the 6.0.x userspace
> > > guest-additions tools on a 6.0.x host, some requests will get denied
> > > with a VERR_VERSION_MISMATCH error, breaking vboxservice.service and
> > > the mounting of shared folders marked to be auto-mounted.
> > >
> > > This commit implements passing the requestor info to the host, fixing this.
> > >
> > > Cc: stable@vger.kernel.org
> >
> > This feels like support for a "new feature", so why would this need to
> > go to older kernels?
> >
> > It's not our fault that vb implemented a non-backwards-compatible change
> > for their new release, right? So why should we be forced to add new
> > features to stable kernels?
>
> From a technical point of view I completely agree with you and I'm unhappy
> with this breakage after vb agreed with me to keep ABI compatibility so
> that we could add a version of the vboxguest driver to the mainline kernel.
So they broke that agreement, ugh. That implies they will do it again?
> OTOH this is going to bite users out there, which is why I added the Cc:
> stable. But this is entirely your call.
Let me think about it...
> > I have no problem to add this for 5.2, but not for older stuff.
>
> Can we at least at it as a fix to 5.1 ? It is not very adventurous.
Sure, let me go review it now.
thanks,
greg k-h
next prev parent reply other threads:[~2019-03-20 18:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 9:35 [PATCH] virt: vbox: Implement passing requestor info to the host for VirtualBox 6.0.x Hans de Goede
2019-03-20 9:46 ` Greg Kroah-Hartman
2019-03-20 9:52 ` Hans de Goede
2019-03-20 18:19 ` Greg Kroah-Hartman [this message]
2019-03-20 19:52 ` Hans de Goede
2019-03-20 18:26 ` Greg Kroah-Hartman
2019-03-22 7:58 ` Hans de Goede
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=20190320181934.GA3907@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=hdegoede@redhat.com \
--cc=knut.osmundsen@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.thayer@oracle.com \
--cc=stable@vger.kernel.org \
/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 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.