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:	Thu, 17 Oct 2013 17:35:29 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Chen Gong <gong.chen@...ux.intel.com>, tony.luck@...el.com,
	joe@...ches.com, naveen.n.rao@...ux.vnet.ibm.com,
	arozansk@...hat.com, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/9] Extended H/W error log driver

On Thu, Oct 17, 2013 at 11:25:41AM -0400, Steven Rostedt wrote:
> On Thu, 17 Oct 2013 10:33:48 -0400
> Chen Gong <gong.chen@...ux.intel.com> wrote:
> 
> 
> > > Gong, can you try moving the CREATE_TRACE_POINTS line to a new file -
> > > arch/x86/ras/ras.c and define it there and not anywhere else, i.e. move
> > > it away from edac_mc.c. Does that help?
> > 
> > In current kernel we haven't arch/x86/ras/ras.c. You mean I create
> > a new one there and just add some trace macro definition?
> 
> The CREATE_TRACE_POINTS will cause the TRACE_EVENT() macro to define
> the functions used for tracing. If you have it defined more than once,
> it will either cause a kernel compile error (variables declared more
> than once), or if used in modules, will cause confusion (as well as
> bloat) because different functions and variables will be defined for
> the same tracepoint.
> 
> If you need to create a separate file that you can have it defined in a
> single place, then please do so!

Yes, the plan was this all along to have arch/x86/ras/ras.c or
arch/x86/ras/core.c where CREATE_TRACE_POINTS is done, among other
things.

Btw, Gong, there's an easier way to test this, if you wanna:

simply make sure EDAC is disabled in the kernel with your patches -
i.e., CONFIG_EDAC is not set in your config. It should work then.

But, the final solution should be what Steve says with the file I'm
suggesting :)

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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