linux-kernel - Re: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl

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: <m1ejdkd3qk.fsf@ebiederm.dsl.xmission.com>
Date:	Mon, 17 Dec 2007 21:30:11 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andi Kleen <ak@....de>
Cc:	Paul Mackerras <paulus@...ba.org>, Greg KH <gregkh@...e.de>,
	David Miller <davem@...emloft.net>,
	venkatesh.pallipadi@...el.com, ebiederm@...ssion.com,
	rdreier@...co.com, torvalds@...ux-foundation.org,
	airlied@...net.ie, davej@...hat.com, mingo@...e.hu,
	tglx@...utronix.de, hpa@...or.com, akpm@...ux-foundation.org,
	arjan@...radead.org, jesse.barnes@...el.com,
	linux-kernel@...r.kernel.org, suresh.b.siddha@...el.com
Subject: Re: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl

Andi Kleen <ak@....de> writes:

> On Mon, Dec 17, 2007 at 08:57:50AM +1100, Paul Mackerras wrote:
>> Greg KH writes:
>> 
>> > Ok, sorry, it wasn't blindingly obvious that this was for pci sysfs
>> > devices that are mmaped, that makes a bit more sense.
>> > 
>> > But I'd like to see what ioctl is wanted here first.
>> 
>> I believe the ioctl would be to set whether the mapping goes to I/O or
>> memory space, 
>
> x86 cannot really access IO space through mmap so no that wasn't planned

0000_00FD_FC00_0000h - 0000_00FD_FDFF_FFFFh On a hypertransport based
system should work.  There is a 32MB window for it.

However the I/O vs mem distinction doesn't matter anyway if we start out
per bar because we already know if it is I/O or mem.

> The main planned use was to get the translated bus address (after IOMMU)
> for a mapping and to set the caching modes.
>
>> So the alternative to the ioctl would be to have multiple files in
>> sysfs, one per combination of modes -- i.e., 4 files, or 3 if we
>> exclude the "I/O with write combining" mode, which would be
>> reasonable.
>
> At least for the IOMMU translation case that wouldn't work.

Well the other alternative looks like having a second file per par
bar.  Say resource0_wc to support the write-combining mode, possibly
restricted to just prefetchable bars.

If that is all we have to worry about my inclination is to suggest
a second file, because that feels a bit more generally useable.  As
that attribute could be applied to ordinary reads and writes to and
from the bar.

Eric
--
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/