linux-kernel - Re: [PATCH 2/2] x86 platform driver: intelligent power sharing driver

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] [day] [month] [year] [list]

Message-ID: <20100515092908.02cc71ba@blake>
Date:	Sat, 15 May 2010 09:29:08 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Andy Isaacson <adi@...apodia.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [PATCH 2/2] x86 platform driver: intelligent power sharing
 driver

On Sat, 15 May 2010 01:54:56 -0700
Andy Isaacson <adi@...apodia.org> wrote:

> On Mon, May 10, 2010 at 10:00:46PM -0400, Andrew Morton wrote:
> > > +	int i;
> > > +	u16 avg;
> > > +
> > > +	for (i = 0; i < IPS_SAMPLE_COUNT; i++)
> > > +		total += (u64)(array[i] * 100);
> > 
> > Actually, that does work.  Somehow the compiler will promote
> > array[i] to u64 _before_ doing the multiplication.  I think.
> > Still, it looks like a deliberate attempt to trick the compiler
> > into doing a multiplicative overflow ;)
> 
> It seems to promote to int, probably due to the implicit type of
> "100".  Aind since array is u16, * 100 can't overflow int.  So yes,
> it's safe, but it does catch the eye as potentially unsafe.

Newest version uses do_div, I think I got it right there.

> 
> > > +		cur_seqno = (thm_readl(THM_ITV) &
> > > ITV_ME_SEQNO_MASK) >>
> > > +			ITV_ME_SEQNO_SHIFT;
> > > +		if (cur_seqno == last_seqno &&
> > > +		    time_after(jiffies, seqno_timestamp + HZ)) {
> > > +			dev_warn(&ips->dev->dev, "ME failed to
> > > update for more than 1s, likely hung\n");
> > > +		} else {
> > > +			seqno_timestamp = get_jiffies_64();
> > > +			last_seqno = cur_seqno;
> > > +		}
> > > +
> > > +		last_msecs = jiffies_to_msecs(jiffies);
> 
> Once it triggers, this will print the "likely hung" message every
> second until the end of time, won't it?

The ME should eventually reset itself, but in the interim we can't
trust its data.  So I should add some better handling for that case
(e.g. disable turbo); however this was more of a debug feature for
early MEs, I don't think it'll happen on production hardware.

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