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: <20150521141259.GU3644@twins.programming.kicks-ass.net>
Date:	Thu, 21 May 2015 16:12:59 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Vince Weaver <vincent.weaver@...ne.edu>,
	Jiri Olsa <jolsa@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 09/10] perf/x86: Remove intel_excl_states::init_state

On Thu, May 21, 2015 at 06:39:29AM -0700, Stephane Eranian wrote:
> On Thu, May 21, 2015 at 4:17 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > For some obscure reason intel_{start,stop}_scheduling() copy the HT
> > state to an intermediate array. This would make sense if we ever were
> > to make changes to it which we'd have to discard.
> >
> > Except we don't. By the time we call intel_commit_scheduling() we're;
> > as the name implies; committed to them. We'll never back out.
> >
> Well, I remember there was a reason why this state was introduced. I thought
> we could do it without initially but had to add it to solve a problem.
> We do backtrack
> in the scheduling algorithm because of the tincremental transaction between the
> generic layer and the x86 layer. I'll have to remember the exact case where this
> happens.
> 
> Now, it may be that because you changed the logic of the xl vs. xlo, this saved
> state is not needed anymore. I'll have to look at that some more.

Another hint its pointless is that stop does an unconditional copy back.

So no matter what we did, all changes are always published.
--
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