linux-kernel - Re: x86/hwmon: conditionalize coretemp's dependency on PCI

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100928091759.421b5bf2@endymion.delvare>
Date:	Tue, 28 Sep 2010 09:17:59 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Guenter Roeck <guenter.roeck@...csson.com>
Cc:	Jan Beulich <JBeulich@...ell.com>,
	"r.marek@...embler.cz" <r.marek@...embler.cz>,
	"fenghua.yu@...el.com" <fenghua.yu@...el.com>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: x86/hwmon: conditionalize coretemp's dependency on PCI

Hi Guenter,

On Mon, 27 Sep 2010 06:02:20 -0700, Guenter Roeck wrote:
> On Mon, Sep 27, 2010 at 08:46:54AM -0400, Jan Beulich wrote:
> > Guenter Roeck <guenter.roeck@...csson.com> wrote:
> > > Seems to me the dependency should not exist in the first place, then.
> > > Otherwise, the driver would still be disabled for GENERIC_CPU, which isn't
> > > good either.
> > 
> > Oh, not having a dependency on PCI at all would be even better.
> > I didn't dare to suggest that.
> > 
> > > Are there examples of other drivers which are not defining the PCI 
> > > dependency
> > > but are conditionally calling pci functions ?
> > 
> > I'm not aware of any, but also didn't explicitly look for such.
>
> It still compiles if I remove the PCI dependency and disable PCI. So that is one plus.
> 
> That whole dependency is just to get the host bridge ID which is then used
> to determine tjmax. Personally I would prefer to have a wrong tjmax over not having 
> coretemp at all,

No! Reporting broken monitoring values is worse than not returning any
value at all. The coretemp (and k8/k10temp) driver(s) already have a
very bad reputation for presenting relative temperature readings as
absolute ones, please let's not add to it.

At this point there are 2 things which can be done:
* If building a kernel for the Atom platform without PCI support is
  something relatively common, which makes sense, then we should look
  for an alternative way to determine the TjMax value for these CPUs,
  which doesn't require PCI support.
* If building a kernel for the Atom platform without PCI support is
  something rare, which makes little sense, then we can simply either
  prevent the driver from building at all in this case, or have it
  print a big fat warning (with suggestion to rebuild the kernel with
  PCI support) when it can't determine the TjMax value.

> and the means to determine tjmax through the bridge ID is kind
> of bogus anyway.

Do you mean it is strange from a technical perspective, or do you have
evidences that it doesn't work properly? This trick come from Intel
themselves, I would guess they know their business.

> So at least in this case it would make sense for me to remove
> the dependency completely. Actually, we won't even change functionality,
> since tjmax is only set to a higher value for specific bridge IDs.

Higher or lower doesn't make a difference. As long as the coretemp
driver doesn't properly report the temperature values as being
relative, users don't expect the value to change depending on the
kernel version or configuration options. We have had dozens of user
reports because of this.

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