linux-kernel - Re: [PATCH] mtd: fix mtd_blkdevs problem with caches on some architectures (2.6.31)

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: <20091122214949.e1ffa058.isloginov@gmail.com>
Date:	Sun, 22 Nov 2009 21:49:49 +0300
From:	Ilya Loginov <isloginov@...il.com>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Peter Horton <phorton@...box.co.uk>,
	"Ed L. Cashin" <ecashin@...aid.com>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [PATCH] mtd: fix mtd_blkdevs problem with caches on some
 architectures (2.6.31)

On Sun, 22 Nov 2009 09:53:50 +0000
David Woodhouse <dwmw2@...radead.org> wrote:

> The thing is, having a function called flush_dcache_page() which doesn't
> actually flush a page of the dcache is just blatantly stupid.

Unfortunately, it's well-established that all architectures have these 
functions. Many kernel systems, for example file systems drivers (ext2,
ext3, ntfs), use them.

In letter to Andrew Morton I wrote that among 20 architectures this call
is not empty only for 8 of them. And it is the problem.

But some architectures really need this call. And kernel has to work
reasonably with them too. Therefore it is required often to call for
empty functions.

> It's misnamed -- it should probably be called something like
> 'flush_valiased_dcache_page()' or 'unalias_dcache_page()' instead, since
> I believe it's only supposed to cope with aliasing issues with virtually
> indexed caches.

I don't think so. For example I had this bug on the processor, which 
icache don't finds for data in dcache. There was no dcache aliases.

> If you're talking about _extending_ the existing silly name to a new
> ARCH_IMPLEMENTS_FOO macro or Kconfig option, perhaps this would be a
> good time to fix the nomenclature, rather than propagating the error?

Andrew has showed me in his first letter another topic in this mailing.
It is said there that there is no reasonable infrastructure in kernel to
correct such things. The first patch can fix bug in the mtd but the 
problem of useless cycle on many architectures is arising. 

It is because there is nothing associated with the flush_dcache_page()
function. 

This way enable us to solve and this problem too. But I agree that it
is not elegant. Have you any idea how to make it better?

Thanks!

-- 
Ilya Loginov <isloginov@...il.com>
--
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/