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: <20090311121007.GC13835@in.ibm.com>
Date:	Wed, 11 Mar 2009 17:41:46 +0530
From:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Roland McGrath <roland@...hat.com>
Subject: Re: [patch 00/11] Hardware Breakpoint interfaces

On Tue, Mar 10, 2009 at 02:46:55PM +0100, Ingo Molnar wrote:
> 
> * prasad@...ux.vnet.ibm.com <prasad@...ux.vnet.ibm.com> wrote:
> 
> > Hi Ingo,
> 
> > 	Please find the revised set of patches that implement 
> > Hardware Breakpoint (or watchpoint) registers and an 
> > arch-specific implementation for x86/x86_64.
> 
> General structure looks good, with a good deal of details 
> that need to be addressed.
>

Thanks to Alan Stern for answering most of the questions....I am
pitching in to fill  the gaps and do any re-write based on the
comments.

> Firstly, as far as i can see this should work on 32-bit too, 
> correct?
> 

Yes. It's been tested on 32-bit x86 all throughout.

> Secondly, what about other architectures - will they build just 
> fine without any arch level glue code? kernel/hw_breakpoint.o 
> get build unconditionally - without any benefit to non-x86 code. 
> Perhaps an ARCH_HAS_HW_BREAKPOINTS Kconfig method would be 
> useful to add.

The hardware breakpoint interfaces haven't been put under any CONFIG_
till now, but I think we should bring them under a new config, say
CONFIG_HW_BREAKPOINT. It would help create a dependancy for
CONFIG_KSYM_TRACER too.

> 
> There's also a number of (small) style issues. 
> kernel/hw_breakpoint.c and other new .c files dont comply to the 
> customary comment style of:
> 
>   /*
>    * Comment .....
>    * ...... goes here:
>    */
> 
> also, the #include files section style should match that of 
> arch/x86/mm/fault.c - it's a conflict-avoidance style.
> 
> also, things like this:
> 
> static struct notifier_block hw_breakpoint_exceptions_nb = {
>         .notifier_call = hw_breakpoint_exceptions_notify,
>         .priority = 0x7fffffff /* we need to be notified first */
> };
> 
> should be:
> 
> static struct notifier_block hw_breakpoint_exceptions_nb = {
>         .notifier_call		= hw_breakpoint_exceptions_notify,
> 	/* We need to be notified first: */
>         .priority		= 0x7fffffff,
> };
> 
> 	Ingo

Sure, will look at the comment styling before I re-send the patchset.

Thanks,
K.Prasad

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