linux-kernel - Re: [RFC Patch] use MTRR for write combining if PAT is not available

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

Date:	Mon, 19 Oct 2009 16:47:10 +0200
From:	Thomas Schlichter <thomas.schlichter@....de>
To:	Jan Beulich <JBeulich@...ell.com>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	dri-devel@...ts.sourceforge.net,
	Robert Hancock <hancockrwd@...il.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	"H. Peter Anvin" <hpa@...or.com>, jbarnes@...tuousgeek.org,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Thomas Hellstrom <thellstrom@...are.com>,
	Tejun Heo <tj@...nel.org>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	x86@...nel.org, Yinghai Lu <yinghai@...nel.org>
Subject: Re: [RFC Patch] use MTRR for write combining if PAT is not  available

Jan Beulich wrote:
> >>> Thomas Schlichter <thomas.schlichter@....de> 17.10.09 21:48 >>>
> >What do you think about these patches?
> 
> Functionality-wise this looks fine to me; whether the core sysfs changes
> are acceptable I can't judge, though.

OK, who can? Or shall I simply ask get_maintainer.pl again?

> However, I would recommend folding the last two arguments of
> mtrr_add_unaligned(), i.e. use mtrr_usage != NULL as the increment
> argument passed to mtrr_add().

Good idea, I will do so this evening...

> And patches 5 and 6 would apparently not build right now, as they're
> failing to pass the new 5th argument to mtrr_add_unaligned().

*Grml* you are of course right. But I am not sure if these both patches
are a goot idea at all.

> Also, why do you add x86-specific code to drivers/pci-sysfs.c when the
> function called there (pci_mmap_page_range()) already is arch-specific?
> Moving your addition there would also allow covering the related
> (legacy?) procfs based functionality... pci_release() could also become
> arch-specific, with a fall-back definition to NULL.

You are right, I should do that...

> Additionally, I would suggest making those code portions depend on
> CONFIG_X86_MTRR rather than CONFIG_X86, so that you don't
> needlessly (try to) allocate the mtrr_usage vector.

Good idea, I will do so.

Thank you very much for your feedback, I'll hopefully come up with an
even better version tonight...

Kind regards,
  Thomas
--
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/