Re: [PATCH] i386 uaccess to fixmap pages

Andrew Morton (akpm@digeo.com)
Fri, 9 May 2003 02:19:21 -0700


Roland McGrath <roland@redhat.com> wrote:
>
> > This doesn't apply against Linus's current tree.
>
> Ok. I don't use bk, but I can update relative to the latest snapshot on
> kernel.org.

Yup. The best place usually is the first link here:

http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/

the "Gzipped full patch".

> > Your patch increases the kernel text by nearly 1%. That's rather a lot for
> > what is a fairly esoteric feature.
>
> Agreed. I hadn't thought about that angle. I am open to suggestions on
> other ways to make it work.
>
> > Would it be possible to avoid this by just taking the fault and fixing
> > things up in the exception handler?
>
> There is no fault that would be taken.

oop, very true.

Nasty. Maybe the best approach is to mostly uninline the access_ok()
check. Do the check for constant-sized small copies first, so those guys
still do the access_ok() check inline; uninline the rest.

It'll hurt the microbenchmarks (again), but it's a general article of faith
that keeping the kernel's cache footprint small is a net win...

Let me think about that for a bit.

> > For some reason the patch causes gcc-2.95.3 to choke over the
>
> You got me. That version of gcc has many, many bugs and is long obsolete.
> Random meaningless perturbations of the code might change its behavior.

Turns out that it only happens with `-O1'. -O2 is OK. I use -O1 because
it is faster. I use gcc-2.95.3 because gcc-3.x is unacceptably slow.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/