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:	Sat, 12 Mar 2016 18:32:53 +0000
From:	"Drokin, Oleg" <oleg.drokin@...el.com>
To:	Joe Perches <joe@...ches.com>
CC:	James Simmons <jsimmons@...radead.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"<devel@...verdev.osuosl.org>" <devel@...verdev.osuosl.org>,
	"Dilger, Andreas" <andreas.dilger@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Lustre Development List" <lustre-devel@...ts.lustre.org>,
	"Nunez, James A" <james.a.nunez@...el.com>
Subject: Re: [PATCH 1/6] staging: lustre: Correct missing newline for CERROR
 call in sfw_handle_server_rpc


On Mar 12, 2016, at 1:23 PM, Joe Perches wrote:

> On Sat, 2016-03-12 at 13:00 -0500, James Simmons wrote:
>> From: James Nunez <james.a.nunez@...el.com>
>> 
>> This is one of the fixes broken out of patch 10000 that was
>> missed in the merger. With this fix the CERROR called in
>> sfw_handle_server_rpc will print out correctly.
> 
> Speaking of CERROR and logging, it it really useful
> for each CERROR use to have 2 static structs?
> 
> In CERROR -> CDEBUG_LIMIT there is a:
> 	static struct cfs_debug_limit_state cdls;
> 	(12 or 16 bytes depending on 32/64 bit arch)
> 
> and in CDEBUG_LIMIT -> _CDEBUG
> 	static struct libcfs_debug_msg_data msgdata;
> 	(24 or 36 bytes depending on 32/64 bit arch)
> 
> That seems a largish bit of data and code to initialize
> these structs for over a thousand call sites.
> 
> Wouldn't a single static suffice?

Single static would not work because the code is parallel so it'll
stomp over each other. or do you mean to have a common
structure for every callsite (but instantiated separately)?

This used to be a local structure in the past, but that
caused considerable stack growth for some functions, that added
up along the call chain, and that was the solution we came up with
that did help.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ