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: <20100828152335.GA2212@khazad-dum.debian.net>
Date:	Sat, 28 Aug 2010 12:23:35 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Cesar Eduardo Barros <cesarb@...arb.net>
Cc:	Joe Perches <joe@...ches.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Matthew Garrett <mjg@...hat.com>,
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] intel_ips: quieten "power or thermal limit exceeded"
 messages

On Sat, 28 Aug 2010, Cesar Eduardo Barros wrote:
> The solution here probably is not less logging. The best solution
> IMO would be to do some sanity checking when loading the module, and
> if the values do not make sense, print something to the log and
> return -ENODEV.

As long as your sanity checking won't make the module fail to load in the
following scenario:

1. environment temperature control fails, room starts to heat up
2. things go south, server reboots due to exceeded temperature limits
3. OS boots in an overheat situation
4. module refuse to load because it expects to never start in a overheating
   situation.

If the sanity checks will cause (4), then don't add them.  rate-limit the
thermal alarms (issue them only once every T, and only if temperature has
increased more than, say, 5°C from the last alarm).

If a given platform is buggy crap (or just el-cheapo trash that overheats
all the time) to the point that the module is useless, blacklist it by DMI
and inform the user.

> I expect that, when it works as it should, the first read while
> loading the module already returns sane values, so a sanity check

well, as long as "sane" does include server-is-too-hot situations...

> there should not have many false positives. OTOH, it is best to not
> load the module when you think things are strange.

What good is an alarm module that refuses to load when there is an alarm
condition happening already?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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