netdev - Re: [net-next 1/2] xen-netback: add module parameter to disable ctrl-ring

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] [day] [month] [year] [list]

Message-ID: <3136e73f-d661-6f16-a3ce-1ee814dbedff@suse.com>
Date:   Mon, 29 Mar 2021 07:03:57 +0200
From:   Juergen Gross <jgross@...e.com>
To:     "Hsu, Chiahao" <andyhsu@...zon.com>,
        Leon Romanovsky <leon@...nel.org>
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 28.03.21 22:46, Hsu, Chiahao wrote:
> 
> 
> Leon Romanovsky 於 2021/3/22 08:13 寫道:
>> CAUTION: This email originated from outside of the organization. Do 
>> not click links or open attachments unless you can confirm the sender 
>> and know the content is safe.
>>
>>
>>
>> On Mon, Mar 22, 2021 at 08:01:17AM +0100, Jürgen Groß wrote:
>>> On 22.03.21 07:48, Leon Romanovsky wrote:
>>>> On Mon, Mar 22, 2021 at 06:58:34AM +0100, Jürgen Groß wrote:
>>>>> 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.
>>>> Yes, it will overcome global nature of module parameters, but how does
>>>> it solve backward compatibility concern?
>>> When creating a guest on A the (unknown) feature will not be set to
>>> any value in the guest's config data. A migration stream not having any
>>> value for that feature on B should set it to "false".
>>>
>>> When creating a guest on B it will either have the feature value set
>>> explicitly in the guest config (either true or false), or it will get
>>> the server's default (this value should be configurable in a global
>>> config file, default for that global value would be "true").
>>>
>>> So with the guest created on B with feature specified as "false" (either
>>> for this guest only, or per global config), it will be migratable to
>>> machine A without problem. Migrating it back to B would work the same
>>> way as above. Trying to migrate a guest with feature set to "true" to
>>> B would not work, but this would be the host admin's fault due to not
>>> configuring the guest correctly.
> so the expected changes would be
> 
> 1. remove feature-ctrl-ring & feature-dynamic-multicast-control from 
> netback_probe( )
> 2. consume the backend Xenstore nodes in connect( ) to see if Xen tools 
> set nodes(true/false) or not(unknown)

Yes. I think this is the way to go.


Juergen

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

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