Wed, Dec 02, 2015 at 11:05:48PM CET, gerlitz...@gmail.com wrote:
>On Sun, Nov 29, 2015 at 12:49 PM, Jiri Pirko <j...@resnulli.us> wrote:
>> Sun, Nov 29, 2015 at 10:04:07AM CET, gerlitz...@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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
