From: Coly Li <colyli@suse.de>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-bcache@vger.kernel.org, linux-block@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Luis R . Rodriguez" <mcgrof@suse.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Kate Stewart <kstewart@linuxfoundation.org>
Subject: Re: [PATCH 4/4] lib/test_crc: Add test cases for crc calculation
Date: Tue, 17 Jul 2018 12:38:57 +0800 [thread overview]
Message-ID: <687c7f69-b1b4-8d0d-dcda-45da3fa2ca9c@suse.de> (raw)
In-Reply-To: <CAHp75VchQOrUU1pA3GRraXO=gdhr9Uwibxo-ri1W_mwtehRtyw@mail.gmail.com>
On 2018/7/17 4:47 AM, Andy Shevchenko wrote:
> On Mon, Jul 16, 2018 at 7:55 PM, Coly Li <colyli@suse.de> wrote:
>> This patch adds a kernel module to test the consistency of multiple crc
>> calculation in Linux kernel. It is enabled with CONFIG_TEST_CRC enabled.
>>
>> The test results are printed into kernel message, which look like,
>>
>> test_crc: crc64_le: PASSED (0x4e6b> +
> 1ff972fa8c55, expval 0x4e6b1ff972fa8c55)
>> test_crc: crc64_le_bch: PASSED (0x0e4f1391d7a4a62e, expval 0x0e4f1391d7a4a62e)
>> test_crc: crc64_le_update: FAILED (0x03d4d0d85685d9a1, expval 0x3d4d0d85685d9a1f)
>>
>> kernel 0day system has framework to check kernel message, then the above
>> result can be handled by 0day system. If crc calculation inconsistency
>> happens, it can be detected quite soon.
>>
>> lib/test_crc.c can is a testing frame work for all crc consistency
>> testings. For now, there are only test caes for 3 crc routines,
>> - crc64_le()
>> - crc64_le_bch()
>> - crc64_le_update()
>
>> +config TEST_CRC
>> + tristate "CRC calculation test driver"
>
Hi Andy,
>> + default n
>
> Default default is n.
>
I see TEST_FIRMWARE, TEST_SYSCTL, TEST_UDELAY, TEST_STATIC_KEYS arround
TEST_CRC all have 'default n', then I think to follow the style it might
be better to have 'default n' here too.
>> + depends on CRC64
>
>> +#include <linux/init.h>
>> +#include <linux/list.h>
>> +#include <linux/module.h>
>> +#include <linux/printk.h>
>> +#include <linux/fs.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/slab.h>
>> +#include <linux/uaccess.h>
>> +#include <linux/async.h>
>> +#include <linux/delay.h>
>> +#include <linux/vmalloc.h>
>> +#include <linux/crc64.h>
>
> Perhaps in order?
Do you mean in alphabet order of header file names ? I will do it in v2
series.
>
> Moreover, either init.h or module.h depending on the Kconfig (here
> seems module.h is a right choice).
>
Sure I will keep module.h in v2 series.
>> +struct crc_test_record {
>
>> +
>
> Redundant.
Removed.
>
>> + char *name;
>> + __le64 data[4];
>> + __le64 initval;
>> + __le64 expval;
>> + int (*handler)(struct crc_test_record *rec);
>> +};
>> +
>> +static int chk_and_msg(const char *name, __le64 crc, __le64 expval)
>> +{
>> + int ret = 0;
>> +
>> + if (crc == expval) {
>> + pr_info("test_crc: %s: PASSED:(0x%016llx, expval 0x%016llx)",
>> + name, crc, expval);
>> + } else {
>> + pr_err("test_crc: %s: FAILED:(0x%016llx, expval 0x%016llx)",
>> + name, crc, expval);
>> + ret = -EINVAL;
>> + }
>> +
>> + return ret;
>
> Perhaps collect statistics instead how it's done in many other tests?
>
Good idea. I will add this in v2 series.
>> +}
>> +
>> +/* Add your crc test caese here */
>
> caese ?
Fixed.
>
>> +static int test_crc64_le(struct crc_test_record *rec)
>> +{
>> + __le64 crc;
>> +
>> + crc = crc64_le(rec->data, sizeof(rec->data));
>> + return chk_and_msg(rec->name, crc, rec->expval);
>
>> +
>
> Redundant.
>
Fixed.
>> +}
>
>> + { .name = NULL, }
>
> Simple {} would work.
>
Fixed.
>> +static int __init test_crc_init(void)
>> +{
>> + int i;
>> + int v, ret = 0;
>> +
>> + pr_info("Kernel crc consitency testing:");
>> + for (i = 0; test_data[i].name; i++) {
>
>> + v = test_data[i].handler(&test_data[i]);
>> + if (v < 0 && ret == 0)
>> + ret = -EINVAL;
>
> A bit strange. Anyway, better to collect statistics and print it at
> the end with corresponding return code.
>
Sure, I will add this :-)
>> + }
>> +
>> + return ret;
>> +}
>
>> +late_initcall(test_crc_init);
>
> Why?
Oh, IMHO this is a test module, we don't need to occupy boot time and it
should be good to invoke it after other modules loaded. As I see many
other test modules do this.
>
>> +static void __exit test_crc_exit(void) { }
>> +module_exit(test_crc_exit);
>
>> +MODULE_LICENSE("GPL");
>
> It's not the same as in SPDX.
>
Nice catch, I will change it to MODULE_LICENSE("GPL v2").
Thanks for all your review !
Coly Li
next prev parent reply other threads:[~2018-07-17 4:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-16 16:55 [PATCH 0/4] add crc64 calculation as kernel library Coly Li
2018-07-16 16:55 ` [PATCH 1/4] lib/crc64: add crc64 option to lib/Kconfig Coly Li
2018-07-16 17:48 ` Randy Dunlap
2018-07-17 3:16 ` Coly Li
2018-07-16 16:55 ` [PATCH 2/4] lib: add crc64 calculation routines Coly Li
2018-07-16 17:57 ` Randy Dunlap
2018-07-17 3:19 ` Coly Li
2018-07-17 1:27 ` kbuild test robot
2018-07-17 1:27 ` kbuild test robot
2018-07-17 3:34 ` Eric Biggers
2018-07-17 6:25 ` Coly Li
2018-07-17 7:13 ` Eric Biggers
2018-07-17 7:34 ` Coly Li
2018-07-17 14:29 ` Coly Li
2018-07-16 16:55 ` [PATCH 3/4] bcache: use routines from lib/crc64.c for CRC64 calculation Coly Li
2018-07-16 16:55 ` [PATCH 4/4] lib/test_crc: Add test cases for crc calculation Coly Li
2018-07-16 18:05 ` Randy Dunlap
2018-07-17 3:37 ` Coly Li
2018-07-16 20:47 ` Andy Shevchenko
2018-07-17 4:38 ` Coly Li [this message]
2018-07-17 5:46 ` [PATCH 0/4] add crc64 calculation as kernel library Hannes Reinecke
2018-07-17 6:19 ` Coly Li
2018-07-17 8:37 ` Andy Shevchenko
2018-07-17 14:20 ` Coly Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=687c7f69-b1b4-8d0d-dcda-45da3fa2ca9c@suse.de \
--to=colyli@suse.de \
--cc=andy.shevchenko@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kstewart@linuxfoundation.org \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.