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
| ||
|
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/
Powered by blists - more mailing lists