linux-kernel - Re: [PATCH] ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode

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