linux-kernel - Re: [PATCH v3 1/4] fsi: occ: Use a large buffer for responses

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]

Message-ID: <eed5470f-f186-4ff0-607b-e90fceb52d15@linux.ibm.com>
Date:   Tue, 19 Oct 2021 15:22:26 -0500
From:   Eddie James <eajames@...ux.ibm.com>
To:     Joel Stanley <joel@....id.au>
Cc:     linux-fsi@...ts.ozlabs.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-hwmon@...r.kernel.org, Jeremy Kerr <jk@...abs.org>,
        Alistair Popple <alistair@...ple.id.au>,
        Guenter Roeck <linux@...ck-us.net>,
        Jean Delvare <jdelvare@...e.com>
Subject: Re: [PATCH v3 1/4] fsi: occ: Use a large buffer for responses


On 10/15/21 12:05 AM, Joel Stanley wrote:
> On Mon, 27 Sept 2021 at 15:59, Eddie James <eajames@...ux.ibm.com> wrote:
>> Allocate a large buffer for each OCC to handle response data. This
>> removes memory allocation during an operation, and also allows for
>> the maximum amount of SBE FFDC.
> Why do we need this change? (is it fixing a bug, did the host change,
> is it an unimplemented feature, etc)


It allows for the maximum amount of SBE FFDC, so an unimplemented 
feature. Previously for the putsram and attn commands, only 32 words 
would have been available, and for getsram, only up to the size of the 
transfer. SBE FFDC might be up to 8Kb.


>
>> Signed-off-by: Eddie James <eajames@...ux.ibm.com>
>> ---
>>   drivers/fsi/fsi-occ.c   | 109 ++++++++++++++++------------------------
>>   include/linux/fsi-occ.h |   2 +
>>   2 files changed, 45 insertions(+), 66 deletions(-)
>>
>> diff --git a/drivers/fsi/fsi-occ.c b/drivers/fsi/fsi-occ.c
>> index b0c9322078a1..ace3ec7767e5 100644
>> --- a/drivers/fsi/fsi-occ.c
>> +++ b/drivers/fsi/fsi-occ.c
>> @@ -10,6 +10,7 @@
>>   #include <linux/kernel.h>
>>   #include <linux/list.h>
>>   #include <linux/miscdevice.h>
>> +#include <linux/mm.h>
>>   #include <linux/module.h>
>>   #include <linux/mutex.h>
>>   #include <linux/fsi-occ.h>
>> @@ -42,13 +43,6 @@
>>
>>   #define OCC_P10_SRAM_MODE      0x58    /* Normal mode, OCB channel 2 */
>>
>> -/*
>> - * Assume we don't have much FFDC, if we do we'll overflow and
>> - * fail the command. This needs to be big enough for simple
>> - * commands as well.
>> - */
>> -#define OCC_SBE_STATUS_WORDS   32
>> -
>>   #define OCC_TIMEOUT_MS         1000
>>   #define OCC_CMD_IN_PRG_WAIT_MS 50
>>
>> @@ -60,6 +54,7 @@ struct occ {
>>          char name[32];
>>          int idx;
>>          u8 sequence_number;
>> +       void *buffer;
>>          enum versions version;
>>          struct miscdevice mdev;
>>          struct mutex occ_lock;
>> @@ -250,8 +245,10 @@ static int occ_verify_checksum(struct occ *occ, struct occ_response *resp,
>>   static int occ_getsram(struct occ *occ, u32 offset, void *data, ssize_t len)
>>   {
>>          u32 data_len = ((len + 7) / 8) * 8;     /* must be multiples of 8 B */
>> -       size_t cmd_len, resp_len, resp_data_len;
>> -       __be32 *resp, cmd[6];
>> +       size_t cmd_len, resp_data_len;
>> +       size_t resp_len = OCC_MAX_RESP_WORDS;
>> +       __be32 *resp = occ->buffer;
>> +       __be32 cmd[6];
>>          int idx = 0, rc;
>>
>>          /*
>> @@ -278,19 +275,19 @@ static int occ_getsram(struct occ *occ, u32 offset, void *data, ssize_t len)
>>          cmd[1] = cpu_to_be32(SBEFIFO_CMD_GET_OCC_SRAM);
>>          cmd[4 + idx] = cpu_to_be32(data_len);
>>
>> -       resp_len = (data_len >> 2) + OCC_SBE_STATUS_WORDS;
>> -       resp = kzalloc(resp_len << 2, GFP_KERNEL);
> Previously the driver would zero the buffer before using it. Should
> you add a memset here?


Based on the rest of the code, I don't see that it's necessary for it be 
initialized to 0.


>
>> @@ -635,6 +605,10 @@ static int occ_probe(struct platform_device *pdev)
>>          if (!occ)
>>                  return -ENOMEM;
>>
>> +       occ->buffer = kvmalloc(OCC_MAX_RESP_WORDS * 4, GFP_KERNEL);
> Why do you allocate WORDS * 4?


I suppose it's an assumption that words are 4 bytes, but the SBE 
operates that way. I will add a #define for it at least. I didn't want 
to define 8192 because the SBE expects the length in words, so I'd 
rather multiply in one place than divide in several places.


>
>> diff --git a/include/linux/fsi-occ.h b/include/linux/fsi-occ.h
>> index d4cdc2aa6e33..7ee3dbd7f4b3 100644
>> --- a/include/linux/fsi-occ.h
>> +++ b/include/linux/fsi-occ.h
>> @@ -19,6 +19,8 @@ struct device;
>>   #define OCC_RESP_CRIT_OCB              0xE3
>>   #define OCC_RESP_CRIT_HW               0xE4
>>
>> +#define OCC_MAX_RESP_WORDS             2048
> Does this need to go in the header?


Yes, the hwmon driver needs it.