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: <20200331190448.GB9912@SDF.ORG>
Date:   Tue, 31 Mar 2020 19:04:48 +0000
From:   George Spelvin <lkml@....ORG>
To:     Benjamin Block <bblock@...ux.ibm.com>,
        Steffen Maier <maier@...ux.ibm.com>
Cc:     linux-kernel@...r.kernel.org,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        linux-s390@...r.kernel.org, linux-scsi@...r.kernel.org,
        lkml@....org
Subject: Re: [RFC PATCH v1 27/50] drivers/s390/scsi/zcsp_fc.c: Use
 prandom_u32_max() for backoff

On Tue, Mar 31, 2020 at 06:13:21PM +0200, Benjamin Block wrote:
> it would be nice, if you could address the mails to the
> driver-maintainers (`scripts/get_maintainer.pl drivers/s390/scsi/zfcp_fc.c`
> will tell you that this is me and Steffen); I'd certainly have noticed
> it earlier then :-).

How the $%$# did I mess that up?  I know choosing recipients for
this series was mostly manual, becase it didn't fit the usual
pattern of the entire series going to everyone affectrd by any part
of it.

And then there waqs a whole lot of shuffling things into a logical
order and grouping.

But I checked MAINTAINERS originally, I really did.  :-(

> On Fri, Nov 29, 2019 at 03:39:41PM -0500, George Spelvin wrote:
>> diff --git a/drivers/s390/scsi/zfcp_fc.c b/drivers/s390/scsi/zfcp_fc.c
>> index b018b61bd168e..d24cafe02708f 100644
>> --- a/drivers/s390/scsi/zfcp_fc.c
>> +++ b/drivers/s390/scsi/zfcp_fc.c
>> @@ -48,7 +48,7 @@ unsigned int zfcp_fc_port_scan_backoff(void)
>>  {
>>  	if (!port_scan_backoff)
>>  		return 0;
>> -	return get_random_int() % port_scan_backoff;
>> +	return prandom_u32_max(port_scan_backoff);
> 
> I think the change is fine. You are right, we don't need a crypto nonce
> here.
> 
> I think I'd let the zero-check stand as is, because the internal
> behaviour of prandom_u32_max() is, as you say, undocumented. This is not
> a performance critical code-path for us anyway.

I agree.  Sorry, that comment in the commit message was a bit of
a "not to self" that I didn't clean up.  Feel free to rm it when
queueing if you like.

> Steffen, do you have any objections? Otherwise I can queue this up -
> minus the somewhat mangled subject - for when we send something next time.

Thank you, I'll put it in my "accepted" pile.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ