[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250429065044-mutt-send-email-mst@kernel.org>
Date: Tue, 29 Apr 2025 06:55:53 -0400
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Jason Wang <jasowang@...hat.com>
Cc: Cindy Lu <lulu@...hat.com>, michael.christie@...cle.com,
sgarzare@...hat.com, linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org
Subject: Re: [PATCH v9 4/4] vhost: Add a KConfig knob to enable IOCTL
VHOST_FORK_FROM_OWNER
On Tue, Apr 29, 2025 at 11:39:37AM +0800, Jason Wang wrote:
> On Mon, Apr 21, 2025 at 11:46 AM Jason Wang <jasowang@...hat.com> wrote:
> >
> > On Mon, Apr 21, 2025 at 11:45 AM Jason Wang <jasowang@...hat.com> wrote:
> > >
> > > On Mon, Apr 21, 2025 at 10:45 AM Cindy Lu <lulu@...hat.com> wrote:
> > > >
> > > > Introduce a new config knob `CONFIG_VHOST_ENABLE_FORK_OWNER_IOCTL`,
> > > > to control the availability of the `VHOST_FORK_FROM_OWNER` ioctl.
> > > > When CONFIG_VHOST_ENABLE_FORK_OWNER_IOCTL is set to n, the ioctl
> > > > is disabled, and any attempt to use it will result in failure.
> > >
> > > I think we need to describe why the default value was chosen to be false.
> > >
> > > What's more, should we document the implications here?
> > >
> > > inherit_owner was set to false: this means "legacy" userspace may
> >
> > I meant "true" actually.
>
> MIchael, I'd expect inherit_owner to be false. Otherwise legacy
> applications need to be modified in order to get the behaviour
> recovered which is an impossible taks.
>
> Any idea on this?
>
> Thanks
At this point, as we changed the behaviour, we have two types of legacy applications
- ones expecting inherit_owner false
- ones expecting inherit_owner true
Whatever we do, some of these will have to be changed.
Given current
kernel has it as true, and given it is a cleaner behaviour that will
keep working when we disable CONFIG_VHOST_ENABLE_FORK_OWNER_IOCTL in 10
years, I think it's the better default.
If you want to change it transparently, look for ways to
distinguish between the two types.
The application in question is qemu, is it not?
I do not see how sticking an ioctl call into its source is such
a big deal, if this is what we want to do.
A bit of short term pain but we get clear maintainable semantics.
--
MST
Powered by blists - more mailing lists