linux-kernel - Re: [Cbe-oss-dev] [patch 3/5] cell: updated driver for DDR2 memory on AXON

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

Message-Id: <200706261938.07112.arnd@arndb.de>
Date:	Tue, 26 Jun 2007 19:38:06 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	carsteno@...ibm.com
Cc:	cbe-oss-dev@...abs.org, Maxim Shchetynin <maxim@...ibm.com>,
	linuxppc-dev@...abs.org, linux-kernel@...r.kernel.org
Subject: Re: [Cbe-oss-dev] [patch 3/5] cell: updated driver for DDR2 memory on AXON

On Tuesday 26 June 2007, Carsten Otte wrote:
> 
> Arnd Bergmann wrote:
> > What will actually happen if you try to mount an axonram device with ext2?
> > I suppose mount should fail with a proper error code if the block size is
> > larger than 4kb, but does that happen?
> > 
> > If you have a 4k block size axonram device, the ext2 really should work
> > using XIP as expected, including the mmap() operation.
> > 
> Absolutely. What's the symptom if you try mount -o xip? I am willing 
> to fix any bugs that show in the ext2/xip code in that scenario...

The real problem is that the ->direct_access function is supposed to return
a kernel virtual address in the linear mapping, which does not make any
sense for axonram. The physical address of the underlying device is
outside of the kernel mapping, and gets mapped into the kernel virtual
space using ioremap, with flags to disallow caching.

If ->direct_access returns a physical address, the file system cannot
access the data through the kernel mapping, but if it returns the
ioremapped address, it cannot know what address to map into the
user page tables, because virt_to_page() is not defined for the
ioremap space.

Maximchose to return the physical address, which is what he needs in
his file system, but that's just not how the interface was designed
to be used.

One way to change fix the problem might be to give a flag to the
->direct_access function to ask for either the page frame number,
or the virtual address (from ioremap or the linear mapping).
It's rather ugly though, so if you have a better idea, let us
know.

Another problem is that the mmap, or no_page, function really
needs to know about the pgprot value it should use. If we add
a field to struct block_device for this, the drivers could set
it there.

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