Re: [patch net-next v2 4/6] mlxsw: core: Implement temperature hwmon interface

[Jiri Pirko <jiri@resnulli.us>]

Wed, Dec 02, 2015 at 11:05:48PM CET, gerlitz.or@gmail.com wrote:
>On Sun, Nov 29, 2015 at 12:49 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Sun, Nov 29, 2015 at 10:04:07AM CET, gerlitz.or@gmail.com wrote:
>>>[..]
>>>> +enum mlxsw_hwmon_attr_type {
>>>> +       MLXSW_HWMON_ATTR_TYPE_TEMP,
>>>> +       MLXSW_HWMON_ATTR_TYPE_TEMP_MAX,
>>>> +};
>>>> +
>>>> +static void mlxsw_hwmon_attr_add(struct mlxsw_hwmon *mlxsw_hwmon,
>>>> +                                enum mlxsw_hwmon_attr_type attr_type,
>>>> +                                unsigned int type_index, unsigned int num) {
>>>> +       struct mlxsw_hwmon_attr *mlxsw_hwmon_attr;
>>>> +       unsigned int attr_index;
>>>> +
>>>> +       attr_index = mlxsw_hwmon->attrs_count;
>>>> +       mlxsw_hwmon_attr = &mlxsw_hwmon->hwmon_attrs[attr_index];
>>>> +
>>>> +       switch (attr_type) {
>>>> +       case MLXSW_HWMON_ATTR_TYPE_TEMP:
>>>> +               mlxsw_hwmon_attr->dev_attr.show = mlxsw_hwmon_temp_show;
>>>> +               mlxsw_hwmon_attr->dev_attr.attr.mode = S_IRUGO;
>>>> +               snprintf(mlxsw_hwmon_attr->name, sizeof(mlxsw_hwmon_attr->name),
>>>> +                        "temp%u_input", num + 1);
>>>> +               break;
>>>> +       case MLXSW_HWMON_ATTR_TYPE_TEMP_MAX:
>>>> +               mlxsw_hwmon_attr->dev_attr.show = mlxsw_hwmon_temp_max_show;
>>>> +               mlxsw_hwmon_attr->dev_attr.attr.mode = S_IRUGO;
>>>> +               snprintf(mlxsw_hwmon_attr->name, sizeof(mlxsw_hwmon_attr->name),
>>>> +                        "temp%u_highest", num + 1);
>>>> +               break;
>>>> +       default:
>>>> +               BUG();
>>>
>>> Guys, do we really have to crash the whole system just b/c somehow an
>>> unknown value propagated here during **init** time?
>>>
>>> I don't think so.
>
>> "default" case simply *cannot* happen. If it happens, it is a stack
>> corruption or some other fatal problem. I believe that BUG is
>> appropriate at these cases.
>
>Jiri, as Dave commented today on the LAG series,  BUG_ON() is bad and
>is only to ever be used when the kernel's continued operation is
>absolutely impossible, can we change here to WARN_ON() or a like?

In this case, I don't know how to bail out correctly, I believe that
bugon is correct here.

Again, there is no possible way to achieve this bugon, other than a
stack corruption. I don't think we should try to cope with a stack
corruption.

Feel free to send a patch if you think otherwise.

Thanks.