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

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: <20151202222551.GP2355@nanopsycho.orion>
Date:	Wed, 2 Dec 2015 23:25:52 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Or Gerlitz <gerlitz.or@...il.com>
Cc:	Linux Netdev List <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [patch net-next v2 4/6] mlxsw: core: Implement temperature hwmon
 interface

Wed, Dec 02, 2015 at 11:05:48PM CET, gerlitz.or@...il.com wrote:
>On Sun, Nov 29, 2015 at 12:49 PM, Jiri Pirko <jiri@...nulli.us> wrote:
>> Sun, Nov 29, 2015 at 10:04:07AM CET, gerlitz.or@...il.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html