netdev - Re: [PATCH net-next 05/14] bnxt_en: Discover firmware error recovery capabilities.

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: <CACKFLi=j=zzUnWS2_Bf8iW_q==AR9rkQZNo90RJc8zMjwoaDxA@mail.gmail.com>
Date:   Sun, 25 Aug 2019 23:23:56 -0700
From:   Michael Chan <michael.chan@...adcom.com>
To:     David Miller <davem@...emloft.net>
Cc:     Netdev <netdev@...r.kernel.org>,
        Vasundhara Volam <vasundhara-v.volam@...adcom.com>,
        Jiri Pirko <jiri@...lanox.com>, Ray Jui <ray.jui@...adcom.com>
Subject: Re: [PATCH net-next 05/14] bnxt_en: Discover firmware error recovery capabilities.

On Sun, Aug 25, 2019 at 10:49 PM David Miller <davem@...emloft.net> wrote:
>
> From: Michael Chan <michael.chan@...adcom.com>
> Date: Sun, 25 Aug 2019 23:54:56 -0400
>
> > +static int bnxt_hwrm_error_recovery_qcfg(struct bnxt *bp)
> > +{
> > +     struct hwrm_error_recovery_qcfg_output *resp = bp->hwrm_cmd_resp_addr;
> > +     struct bnxt_fw_health *fw_health = bp->fw_health;
> > +     struct hwrm_error_recovery_qcfg_input req = {0};
> > +     int rc, i;
> > +
> > +     if (!(bp->fw_cap & BNXT_FW_CAP_ERROR_RECOVERY))
> > +             return 0;
> > +
> > +     bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_ERROR_RECOVERY_QCFG, -1, -1);
> > +     mutex_lock(&bp->hwrm_cmd_lock);
> > +     rc = _hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
> > +     if (rc) {
> > +             rc = -EOPNOTSUPP;
> > +             goto err_recovery_out;
> > +     }
>
> How is this logically an unsupported operation if you're guarding it's use
> with an appropriate capability check?

The BNXT_FW_CAP_ERROR_RECOVERY flag says that error recovery should be
supported, but if the firmware call to get the recovery parameters
fails, we return -EOPNOTSUPP to let the caller know that error
recovery cannot be supported.  Again, I will try to clean up the error
codes in v2.