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

Date:   Sun, 21 Mar 2021 18:54:52 +0100
From:   "Hsu, Chiahao" <andyhsu@...zon.com>
To:     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



Leon Romanovsky 於 2021/3/21 18:22 寫道:
> 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 Sun, Mar 21, 2021 at 05:31:08PM +0100, Hsu, Chiahao wrote:
>>
>> Leon Romanovsky 於 2021/3/17 18:22 寫道:
>>> 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 Tue, Mar 16, 2021 at 04:22:21PM +0100, Hsu, Chiahao wrote:
>>>> Leon Romanovsky 於 2021/3/14 11:04 寫道:
>>>>> 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 Fri, Mar 12, 2021 at 09:36:59PM +0100, Andrew Lunn wrote:
>>>>>> On Fri, Mar 12, 2021 at 04:18:02PM +0100, Hsu, Chiahao wrote:
>>>>>>> Andrew Lunn 於 2021/3/12 15:52 寫道:
>>>>>>>> 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 Thu, Mar 11, 2021 at 10:59:44PM +0000, ChiaHao Hsu wrote:
>>>>>>>>> In order to support live migration of guests between kernels
>>>>>>>>> that do and do not support 'feature-ctrl-ring', we add a
>>>>>>>>> module parameter that allows the feature to be disabled
>>>>>>>>> at run time, instead of using hardcode value.
>>>>>>>>> The default value is enable.
>>>>>>>> Hi ChiaHao
>>>>>>>>
>>>>>>>> There is a general dislike for module parameters. What other mechanisms
>>>>>>>> have you looked at? Would an ethtool private flag work?
>>>>>>>>
>>>>>>>>          Andrew
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>> I can survey other mechanisms, however before I start doing that,
>>>>>>>
>>>>>>> could you share more details about what the problem is with using module
>>>>>>> parameters? thanks.
>>>>>> It is not very user friendly. No two kernel modules use the same
>>>>>> module parameters. Often you see the same name, but different
>>>>>> meaning. There is poor documentation, you often need to read the
>>>>>> kernel sources it figure out what it does, etc.
>>>>> +1, It is also global parameter to whole system/devices that use this
>>>>> module, which is rarely what users want.
>>>>>
>>>>> Thanks
>>>> Hi,
>>>> I think I would say the current implementation(modparams) isappropriate
>>>> after reviewing it again.
>>>>
>>>> We are talking about 'feature leveling', a way to support live migrationof
>>>> guest
>>>> between kernels that do and do not support the features. So we want to
>>>> refrain
>>>> fromadding the features if guest would be migrated to the kernel which does
>>>> not support the feature. Everythingshould be done (in probe function) before
>>>> frontend connects, and this is why ethtool is not appropriate for this.
>>> It wouldn't be a surprise to you that feature discovery is not supposed
>>> to be done through module parameters. Instead of asking from user to
>>> randomly disable some feature, the system is expected to be backward
>>> compatible and robust enough to query the list of supported/needed
>>> features.
>>>
>>> Thanks
>>>
>>>> Thanks
>>>>
>>>>
>> 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.

Thanks
> Thanks
>