Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1197081

Re: [tip:x86/mm] x86/mm/mtrr: Clean up mtrr_type_lookup()

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [tip:x86/mm] x86/mm/mtrr: Clean up mtrr_type_lookup()
Date 2015-07-31 17:10 +0200
Message-ID <pSk6B-Yx-13@gated-at.bofh.it> (permalink)
References <pqsQi-8cH-19@gated-at.bofh.it> <puiz0-71G-9@gated-at.bofh.it> <puKvg-6dj-35@gated-at.bofh.it> <pSio9-6zT-1@gated-at.bofh.it> <pSjNg-mz-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Jul 31, 2015 at 04:44:52PM +0200, Borislav Petkov wrote:
> On Fri, Jul 31, 2015 at 03:18:02PM +0200, Peter Zijlstra wrote:
> > Using these functions with preemption enabled is racy against MTRR
> > updates. And if that race is ok, at the very least explain that it is
> > indeed racy and why this is not a problem.
> 
> Right, so Luis has been working on burying direct MTRR access so
> after that work is done, we'll be using only PAT for changing memory
> attributes. Look at arch_phys_wc_add() and all those fbdev users of
> mtrr_add() which get converted to that thing...

Drivers don't do those lookups afaict.

But its things like set_memory_XX(), and afaict that's all buggy against
MTRR modifications.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

Re: [tip:x86/mm] x86/mm/mtrr: Clean up mtrr_type_lookup() Peter Zijlstra <peterz@infradead.org> - 2015-07-31 17:10 +0200
  Re: [tip:x86/mm] x86/mm/mtrr: Clean up mtrr_type_lookup() Borislav Petkov <bp@alien8.de> - 2015-07-31 17:30 +0200

csiph-web