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: <20090527142108.GC14090@in.ibm.com>
Date:	Wed, 27 May 2009 19:51:08 +0530
From:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [Patch 01/12] Prepare the code for Hardware Breakpoint
	interfaces

On Wed, May 27, 2009 at 01:48:30PM +0200, Frederic Weisbecker wrote:
> On Wed, May 27, 2009 at 02:19:17PM +0530, K.Prasad wrote:
> > On Wed, May 27, 2009 at 03:01:15AM +0200, Frederic Weisbecker wrote:
> > > On Thu, May 21, 2009 at 07:30:33PM +0530, K.Prasad wrote:
> > > > This patch introduces header files containing constants, structure definitions
> > > > and declaration of functions used by the hardware breakpoint interface code.
> > > > 
> > > > Original-patch-by: Alan Stern <stern@...land.harvard.edu>
> > > > Signed-off-by: K.Prasad <prasad@...ux.vnet.ibm.com>
> > > > Reviewed-by: Alan Stern <stern@...land.harvard.edu>
> > > > ---
> > > > Index: linux-2.6-tip.hbkpt/arch/x86/include/asm/processor.h
> > > > ===================================================================
> > > > --- linux-2.6-tip.hbkpt.orig/arch/x86/include/asm/processor.h
> > > > +++ linux-2.6-tip.hbkpt/arch/x86/include/asm/processor.h
> > > > @@ -29,6 +29,7 @@ struct mm_struct;
> > > >  #include <linux/threads.h>
> > > >  #include <linux/init.h>
> > > >  
> > > > +#define HBP_NUM 4
> > > >  /*
> > > >   * Default implementation of macro that returns current
> > > >   * instruction pointer ("program counter").
> > > > @@ -433,12 +434,11 @@ struct thread_struct {
> > > >  #endif
> > > >  	unsigned long		gs;
> > > >  	/* Hardware debugging registers: */
> > > > -	unsigned long		debugreg0;
> > > > -	unsigned long		debugreg1;
> > > > -	unsigned long		debugreg2;
> > > > -	unsigned long		debugreg3;
> > > > +	unsigned long		debugreg[HBP_NUM];
> > > 
> > > 
> > > 
> > > Note that each patches must leave a buildable kernel, even
> > > if these patches are contained in a set logic.
> > > 
> > > I haven't tried yet, but I suspect this patch, if applied
> > > without the rest, will cause a build error.
> > > 
> > > There are still some sites that use the removed fields above.
> > > 
> > > A solution would be to temporarily fix these sites in this patch
> > > by using the new debugreg array interface. Even if you remove
> > > some of them in further patches in this series, for example
> > > by using the new load_debug_registers() helper, it will follow
> > > the logic step by step and leave a buildable kernel at each
> > > middle step.
> > > 
> > > That implies to modify also some of the other patches of this
> > > series, but all of these changes should be trivial.
> > > 
> > > Thanks,
> > > 
> > > Frederic.
> > >
> > 
> > The debugreg<n> removal patches were correct, even as recent as
> > http://lkml.org/lkml/2009/5/11/160 and I guess I messed-up meanwhile.
> > Thanks for pointing it out - I've now moved them to Patch 8/12 along
> > with the ptrace changes.
> > 
> > The rest of the patches allow the kernel tree to be compiled though.
> > Would you prefer a new iteration with these changes, or can I send
> > individual patches with the changes discussed above?
> > 
> > Thanks,
> > K.Prasad
> >  
> 
> 
> Yeah you can resend those two individual patches. That's fine.
> Just increase the version number and keep their place (1/12 and 8/12)
> so that I won't run into confusion :)
> 
> Thanks!
>

Hi Frederic,
	Please find the updated Patch 1/12 here:
http://lkml.org/lkml/2009/5/27/345/ and Patch 8/12 here:
http://lkml.org/lkml/2009/5/27/346/.

Without much foresight, I didnot track the changes in the patchset
through version numbering (I'm doing it for the PPC64 patchset atleast),
and wasn't very comfortable to call these new patches as ver II at this
late a stage. Hope that would be acceptable to you!

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