Messages in this thread | | | Date | Fri, 9 May 2003 01:55:04 -0700 | From | Roland McGrath <> | Subject | Re: [PATCH] i386 uaccess to fixmap pages |
| |
> 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.
> 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. The address is valid, but above TASK_SIZE. The purpose of access_ok is to say that it's ok to try it and let it fault, because it's a user-visible address and not the kernel memory mapped into the high part of every process's address space. The accesses that follow are done in kernel mode, so there is no fault for pages marked as not user-visible. The fixmap addresses are > TASK_SIZE and so fail the __range_ok test, heretofore making access_ok return false. Those are the code paths leading to EFAULT that I mentioned.
So far I can't think of a better way to do it.
> You'll be wanting to parenthesise `size' and `type' here.
I didn't bother because the existing macros do not consistently parenthesize their arguments and so if there were really any problems they would already show. But I agree it's what should be done.
> 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.
Thanks, Roland - 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/
| |