linux-kernel - Re: [PATCH] dmatest: add ability to disable pq and xor

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]

Date:	Tue, 4 Jun 2013 10:25:12 +0300
From:	Andy Shevchenko <andy.shevchenko@...il.com>
To:	Jon Mason <jon.mason@...el.com>
Cc:	Dan Williams <djbw@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dave Jiang <dave.jiang@...el.com>,
	Vinod Koul <vinod.koul@...el.com>
Subject: Re: [PATCH] dmatest: add ability to disable pq and xor

On Tue, Jun 4, 2013 at 2:29 AM, Jon Mason <jon.mason@...el.com> wrote:
> On Fri, May 31, 2013 at 11:22:10AM +0300, Andy Shevchenko wrote:
>> On Fri, May 17, 2013 at 8:54 PM, Jon Mason <jon.mason@...el.com> wrote:
>> > dmatest would create a thread to stress XOR and PQ, if the capability is
>> > present in the hardware.  Add the ability to disable XOR and PQ by
>> > disabling it if *_sources are set to zero.
>>
>> Sorry, didn't comment this earlier.
>>
>> Those threads are independent including MEMCPY stuff.
>> I think it's better to have one additional parameter let's say
>> type_of_test where you can set
>> 1 for MEMCPY
>> 2 for XOR
>> 4 for PQ
>>
>> Share this parameter via debugfs and use 0x07 as default value.
>> I doubt we need this as a module parameter.
>
> This is using the existing module parameter, so there is nothing new
> added.

That's why it's a bit confusing. User can more easily forget the
'magic' numbers. And I see no reason to prevent user to enter 0 as a
number of sources.
Moreover, your patch doesn't cover the case when user doesn't want to
run MEMCPY thread.

>  Since the testing is started immediately upon module
> insertion,

It used to be so, but nowadays it's true only when dmatest is compiled in.
If someone wants to compile in that module they probably want to run
stress tests, where XOR and PQ might be useful.

> there needs to be a way to prevent it from ever starting.

My opinion I already shared, new node under debugfs. There is might be
a good reason to add a new module parameter as well.

--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/