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] [day] [month] [year] [list]
Date:	Tue, 18 Dec 2007 06:48:45 -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, 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:

>> Well the other alternative looks like having a second file per par
>> bar.  Say resource0_wc to support the write-combining mode, possibly
>
> The intention was to support memory not in bars, but give a generic
> IOMMU mapped memory interface for user space e.g. for the X server.
> But that needs a way to return the bus address for the mmap mapping
> and ioctl was the best I came up with for that.
> Given it was never finished.

Ok that part wasn't obvious.  The only thing we mmap in sysfs today
are the bars.

Taking normal memory and iommu mapping it to a device and then having
a user space accessible version is a bit different.  We need a special
interface to allocate it and map it through the iommu to user space.
This needs to be a driver or a support subsystem like DRM.  Once
we have gone that far then we can map those address to user space.

I expect from the sysfs perspective those per device regions should look
a lot like bars showing contiguous chunks of memory RAM from the devices
perspective.  At which point having two files instead of just one can
solve the problem without an ioctl.

For contiguous to device memory we also have some permission issues
so I'm not yet certain that it make sense to expose it through sysfs.

Regardless that seems to be solving a completely new aspect of the problem,
and we can solve that problem separately.

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/

Powered by blists - more mailing lists