netdev - Re: [PATCH net-next 12/15] net: hns3: refactor dump qs shaper of debugfs

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]

Date:   Fri, 23 Jul 2021 21:56:25 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Huazhong Tan <tanhuazhong@...wei.com>
Cc:     David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Networking <netdev@...r.kernel.org>,
        Salil Mehta <salil.mehta@...wei.com>, yisen.zhuang@...wei.com,
        huangdaode@...wei.com, Linuxarm <linuxarm@...wei.com>,
        Guangbin Huang <huangguangbin2@...wei.com>
Subject: Re: [PATCH net-next 12/15] net: hns3: refactor dump qs shaper of debugfs

On Thu, May 20, 2021 at 4:22 AM Huazhong Tan <tanhuazhong@...wei.com> wrote:
>  static int hclge_dbg_dump_tm_qset(struct hclge_dev *hdev, char *buf, int len)
>  {
> +       char data_str[ARRAY_SIZE(tm_qset_items)][HCLGE_DBG_DATA_STR_LEN];
> +       char *result[ARRAY_SIZE(tm_qset_items)], *sch_mode_str;
>         u8 priority, link_vld, sch_mode, weight;
> -       char *sch_mode_str;
> +       struct hclge_tm_shaper_para shaper_para;
> +       char content[HCLGE_DBG_TM_INFO_LEN];
> +       u16 qset_num, i;
>         int ret, pos;
> -       u16 qset_num;
> -       u16 i;
> +       u8 j;

These variables are too large to put on the stack of a function, as pointed out
by this compiler warning:

drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c: In
function 'hclge_dbg_dump_tm_pg':
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c:782:1:
error: the frame size of 1416 bytes is larger than 1400 bytes
[-Werror=frame-larger-than=]

I couldn't find an obvious way to fix it. Using kmalloc to dynamically
allocate them
would work, but it's probably better to use a seq_file here and change the loop
to multiple calls.

        Arnd