linux-kernel - Re: [PATCH] UIO: only call pgprot

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 4 Nov 2008 19:06:53 -0500
From:	"Mike Frysinger" <vapier.adi@...il.com>
To:	"Hans J. Koch" <hjk@...utronix.de>
Cc:	"Mike Frysinger" <vapier@...too.org>, gregkh@...e.de,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] UIO: only call pgprot_noncached if defined

On Wed, Oct 29, 2008 at 15:53, Hans J. Koch wrote:
> On Wed, Oct 29, 2008 at 01:26:17PM -0400, Mike Frysinger wrote:
>> Not all arches support pgprot_noncached (like the Blackfin port).
>
> These archs have it (just a quick grep, might be incomplete):
> x86, sh, alpha, powerpc, ia64, sparc, sparc64, mips, avr32, arm, parisc.
>
> That's 11 archs _with_ pgprot_noncached(). Might be a good idea to add
> that macro to blackfin, too.

when i looked i got the feeling that the arches that could support
this added it, and those that couldnt did not.  the Blackfin arch
cannot support per-page caching behavior (well, we can with the MPU
turned on, but the overhead of the MPU makes it unrealistic for
production deployment in most cases), so we do not have it defined.

there doesnt seem to be any real documentation on this function though ...

>> Other
>> drivers seem to handle this by checking to see if it is defined,
>
> That statement made me curious. I greped around for a while, but the
> only driver that does this check is drivers/char/mem.c, while there are
> 22 drivers that use pgprot_noncached() without checking.

i was ignoring the drivers that are not generic as i dont think
they're relevant.  that cuts out quite a few of those "22 drivers".

>> so let's do that in the UIO driver as well.
>
> Well, your patch is surely OK and will work, but I've got some
> difficulties to understand why you prefer patching an ugly #ifdef into up
> to 22 drivers instead of just defining that simple macro in your arch,
> like many of the others already did. But maybe I missed the point
> here, could you please elaborate a bit?

it doesnt make sense to ifdef a driver that only works on a single
arch or two and has hardware support for this function (and thus has
it defined).
-mike
--
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/