Thread (28 messages) 28 messages, 4 authors, 2025-05-19

Re: [PATCH v9 4/4] vhost: Add a KConfig knob to enable IOCTL VHOST_FORK_FROM_OWNER

From: Jason Wang <hidden>
Date: 2025-05-19 07:35:05
Also in: lkml, netdev

On Fri, May 16, 2025 at 6:39 PM Michael S. Tsirkin [off-list ref] wrote:
On Fri, May 16, 2025 at 09:31:42AM +0800, Jason Wang wrote:
quoted
On Thu, May 15, 2025 at 2:14 PM Michael S. Tsirkin [off-list ref] wrote:
quoted
On Wed, May 14, 2025 at 10:52:58AM +0800, Jason Wang wrote:
quoted
On Tue, May 13, 2025 at 3:09 PM Michael S. Tsirkin [off-list ref] wrote:
quoted
On Tue, May 13, 2025 at 12:08:51PM +0800, Jason Wang wrote:
quoted
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.
I think it's not a regression since it comes since the day vhost is
introduced. To my understanding the real regression is the user space
noticeable behaviour changes introduced by vhost thread.
quoted
The specific customer can
flip the modparam and be happy.
If you stick to the false as default, I'm fine.

Thanks
That would be yet another behaviour change.
Back to the original behaviour.
yes but the original was also a bugfix.
quoted
quoted
I think one was enough, don't you think?
I think such kind of change is unavoidable if we want to fix the
usersapce behaviour change.

Thanks
I feel it is too late to "fix". the new behaviour is generally ok, and I
feel the right thing so to give management control knobs do pick the
desired behaviour.
And really modparam is wrong here because different userspace
can have different requirements, and in ~10 years I want to see us
disable the legacy behaviour altogether.
But given your time constraints, a modparam knob as a quick workaround
for the specific customer is kind of not very terrible.
Ok, that makes sense.

Thanks
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help