Re: [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Petr Tesarik <ptesarik@xxxxxxx>
- Subject: Re: [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses
- From: Ingo Molnar <mingo@xxxxxxx>
- Date: Sun, 3 Jul 2011 21:46:18 +0200
- Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Fenghua Yu <fenghua.yu@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Paul Mundt <lethal@xxxxxxxxxxxx>, Russell King <linux@xxxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Tony Luck <tony.luck@xxxxxxxxx>, x86@xxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-ia64@xxxxxxxxxxxxxxx, linux-sh@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Arjan van de Ven <arjan@xxxxxxxxxxxxx>, Dave Jones <davej@xxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- In-reply-to: <email@example.com>
- List-id: <linux-ia64.vger.kernel.org>
- References: <firstname.lastname@example.org> <email@example.com> <20110701195629.GA19057@elte.hu> <firstname.lastname@example.org>
- User-agent: Mutt/1.5.20 (2009-08-17)
* Petr Tesarik <ptesarik@xxxxxxx> wrote:
> > Do you expect distros to enable this boot option by default? I.e.
> > would SuSE be willing to ship with a restrictive /dev/mem by
> > default? That's really the wider goal we want to work towards.
> I'm not really the decision-maker on this, but even though I don't
> need it for crash, there are several other users which would have
> to be fixed:
> 1. hwinfo (EFI, MPTABLE and ACPI table parsing, analyzing video BIOS)
> 2. dmidecode (SMBIOS, DMI)
> 3. possibly others
But those tables wont be in regular RAM (they will be in ROM or in
RAM marked non-RAM in a special way in the e820 tables).
dmidecode certainly works on Fedora.
> > Hm, why would the ability "dirty and/or flush an arbitrary
> > physical cache line for testing purposes" be a DoS?
> Effectively switching off CPU caches can slow things down quite a
> bit... especially on a large SMP system. ;)
Flushing a cacheline isnt switching it off. You can already 'flush'
the cache from user-space as well, by trashing it for example. So i
don't see the DoS angle.
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html