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-next>] [day] [month] [year] [list]
Date:	Fri, 28 Aug 2009 14:58:49 +0200
From:	Joachim Fenkes <FENKES@...ibm.com>
To:	Hal Rosenstock <hal.rosenstock@...il.com>
Cc:	Christoph Raisch <raisch@...ibm.com>,
	OF-EWG <ewg@...ts.openfabrics.org>,
	OF-General <general@...ts.openfabrics.org>,
	Hal Rosenstock <hnrose@...cast.net>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	LKML <linux-kernel@...r.kernel.org>,
	LinuxPPC-Dev <linuxppc-dev@...abs.org>,
	Roland Dreier <rolandd@...co.com>,
	Stefan Roscher <stefan.roscher@...ibm.com>
Subject: Re: [ewg] [PATCH] IB/ehca: Construct MAD redirect replies from 	request MAD

Hal Rosenstock <hal.rosenstock@...il.com> wrote on 27.08.2009 15:31:40:

> I don't think it should be hard coded. IMO it would be better to default 
to 18
> and somehow able to be adjusted (via a (dynamic) module parameter ?).

I don't see how making this a parameter would benefit any end user, while 
on the other hand it clutters up our parameter list.

Changing RespTimeValue won't influence the IB performance or user-visible 
behavior of our driver in any way, and in fact, all RespTimeValue says is 
"Please use a timeout of one second for all future MADs you send me", only 
there won't be any more MADs in the future because we just redirected the 
client to someone else. So, the RespTimeValue field is a don't care in the 
redirection scenario. Setting it to an arbitrary, but legal value isn't 
much more than a concession towards any broken clients that may be out 
there.

Given that you seem to like the rest of the code and Jason hasn't spoken 
up yet, I think we can have Roland merge this patch. Roland, what do you 
think?

Regards,
  Joachim

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ