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: <20120924191736.GA31118@mudshark.cambridge.arm.com>
Date:	Mon, 24 Sep 2012 20:17:36 +0100
From:	Will Deacon <will.deacon@....com>
To:	Stephen Boyd <sboyd@...eaurora.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: hw_breakpoint: Clear breakpoints before enabling
 monitor mode

On Mon, Sep 24, 2012 at 07:04:56PM +0100, Stephen Boyd wrote:
> On 09/24/12 10:19, Will Deacon wrote:
> > Ok, I've pushed a bunch of patches to my hw-breakpoint branch (head commit
> > 55cb726797c7). I'll post them to the list after the merge window, but please
> > do take them for a spin if you get a chance.
> >
> 
> Sure, I'll try them later today. I would say just send them out so
> people can add tested and reviewed tags. Otherwise we should all start
> planning week long vacations every 7 to 8 weeks to coincide with the
> merge window.

I like the idea of that! However, it's more that most people are worrying
about getting their trees into shape rather than reviewing new code at
the moment, so I suspect that posting it now will go largely un-noticed
and I don't think this is a critical fix (see below).

> Also, it would be nice if we could fix this in 3.7 or even 3.6. Booting
> on an MSM8660 is very fragile right now and this patch fixes it for me.

Whilst I appreciate that it solves your problem, I'm *really* wary about
changing this stuff without giving it a thorough airing beforehand. The
debug reset path is extremely error-prone and its behaviour is tangled
up with the state of various external signals into the core, meaning that
different platforms with the same CPU can take different paths at runtime.

I can definitely CC stable once we're happy with this, but I'd rather
avoid rushing the patches in before 3.8.

Cheers,

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