lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c7b2a12d-bf81-3d5f-40ae-f70e6cfa1637@suse.com>
Date:   Mon, 22 Mar 2021 06:58:34 +0100
From:   Jürgen Groß <jgross@...e.com>
To:     Leon Romanovsky <leon@...nel.org>,
        "Hsu, Chiahao" <andyhsu@...zon.com>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        wei.liu@...nel.org, paul@....org, davem@...emloft.net,
        kuba@...nel.org, xen-devel@...ts.xenproject.org
Subject: Re: [net-next 1/2] xen-netback: add module parameter to disable
 ctrl-ring

On 22.03.21 06:39, Leon Romanovsky wrote:
> On Sun, Mar 21, 2021 at 06:54:52PM +0100, Hsu, Chiahao wrote:
>>
> 
> <...>
> 
>>>> Typically there should be one VM running netback on each host,
>>>> and having control over what interfaces or features it exposes is also
>>>> important for stability.
>>>> How about we create a 'feature flags' modparam, each bits is specified for
>>>> different new features?
>>> At the end, it will be more granular module parameter that user still
>>> will need to guess.
>> I believe users always need to know any parameter or any tool's flag before
>> they use it.
>> For example, before user try to set/clear this ctrl_ring_enabled, they
>> should already have basic knowledge about this feature,
>> or else they shouldn't use it (the default value is same as before), and
>> that's also why we use the 'ctrl_ring_enabled' as parameter name.
> 
> It solves only forward migration flow. Move from machine A with no
> option X to machine B with option X. It doesn't work for backward
> flow. Move from machine B to A back will probably break.
> 
> In your flow, you want that users will set all module parameters for
> every upgrade and keep those parameters differently per-version.

I think the flag should be a per guest config item. Adding this item to
the backend Xenstore nodes for netback to consume it should be rather
easy.

Yes, this would need a change in Xen tools, too, but it is the most
flexible way to handle it. And in case of migration the information
would be just migrated to the new host with the guest's config data.


Juergen

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3092 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ