linux-kernel - Re: [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server

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]

Message-ID: <5A0A38B8-B387-436D-B72A-7D8247B6A00D@intel.com>
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.