On Tue, May 13, 2025 at 12:08:51PM +0800, Jason Wang wrote:

On Wed, Apr 30, 2025 at 5:27 PM Michael S. Tsirkin [off-list ref] wrote:

quoted

On Wed, Apr 30, 2025 at 11:34:49AM +0800, Jason Wang wrote:

quoted

On Tue, Apr 29, 2025 at 6:56 PM Michael S. Tsirkin [off-list ref] wrote:

quoted

On Tue, Apr 29, 2025 at 11:39:37AM +0800, Jason Wang wrote:

quoted

On Mon, Apr 21, 2025 at 11:46 AM Jason Wang [off-list ref] wrote:

quoted

On Mon, Apr 21, 2025 at 11:45 AM Jason Wang [off-list ref] wrote:

quoted

On Mon, Apr 21, 2025 at 10:45 AM Cindy Lu [off-list ref] wrote:

quoted

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

So, let's say we had a modparam? Enough for this customer?
WDYT?

Just to make sure I understand the proposal.

Did you mean a module parameter like "inherit_owner_by_default"? I
think it would be fine if we make it false by default.

Thanks

I think we should keep it true by default, changing the default
risks regressing what we already fixes. The specific customer can
flip the modparam and be happy.

quoted

--
MST