linux-kernel - Re: [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN

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: <20131109155428.GA15649@redhat.com>
Date:	Sat, 9 Nov 2013 16:54:28 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	suravee.suthikulpanit@....com, mingo@...nel.org, mingo@...hat.com,
	jacob.w.shin@...il.com, a.p.zijlstra@...llo.nl,
	acme@...stprotocols.net, hpa@...or.com, tgl@...ain.invalid,
	linux-kernel@...r.kernel.org, sherry.hurwitz@....com
Subject: Re: [PATCH 1/3] perf/x86/amd: AMD support for bp_len >
	HW_BREAKPOINT_LEN_8

Just in case let me repeat, I can be easily wrong because I forgot
how this series actually look and I don't have the patches now ;)

On 11/09, Frederic Weisbecker wrote:
>
> On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov wrote:
> > On 11/08, Frederic Weisbecker wrote:
> > >
> > >
> > > Does this feature only work on data breakpoint or is instruction breakpoint
> > > address range supported as well?
> >
> > IIRC, execute range is supported as well.
> >
> > But. I can't look at the code now, but iirc this can't really work until
> > we fix the (already discussed) problems with bp_len && X86_BREAKPOINT_LEN_X.
> > IOW, we should not blame these patches if it doesn't work.
>
> Yeah, don't worry I don't plan to push back these patches for the sake of that bug,
> that would be definetly unfair, especially as I introduced that issue :)
>
> And the patchset looks good overall, except for a few details but it's mostly ok,

OK,

> I just would like to fix that issue along the way. It would be really nice if we can
> avoid having a mask _and_ a len for breakpoints.

Up to you and Suravee, but can't we cleanup this later?

This series was updated many times to address a lot of (sometimes
contradictory) complaints.

> I mean, that doesn't look right to me,
> it's two units basically measuring the same thing, so that's asking for conflicting troubles.

Yes. And we can kill either _len or _mask, not sure what would be more
clean.

At least with the current implementation (again, iirc) mask == len -1.
Although amd supports the more generic masks (but I can't recall the
details).

> I'm just not sure how to reuse the len to express breakpoint ranges (that was in fact the
> initial purpose of it) without breaking the tools.

Confused... user-space still uses len to express the range? Just
the kernel "switches" to mask if len > 8 ?

Oleg.

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