Messages in this thread | | | Date | Wed, 8 Dec 2004 00:36:52 +0100 | From | Petr Vandrovec <> | Subject | Re: [PATCH 2.6] clean-up: fixes "comparison between signed |
| |
On Wed, Dec 08, 2004 at 12:20:01AM +0100, Jesper Juhl wrote: > On Tue, 7 Dec 2004, Petr Vandrovec wrote: > > > On Tue, Dec 07, 2004 at 12:09:05AM +0100, Jesper Juhl wrote: > > > On Mon, 6 Dec 2004, Petr Vandrovec wrote: > > > > Correct is (if any fix is needed at all) typecast regs->esp to unsigned > > > > long, > > > > > > That would have been my suggestion as well. > > > > > > >eventually with check that address is less than (unsigned long)-32, > > > > as area at VA 0 is not going to grow "down" to 0xFFFFFxxx, even if you > > > > nicely ask. > > > > > > you mean something like this - right? > > > > Yes. Though I believe that we already take vma == NULL path when address is that big. > > Hmm, where? - maybe I'm blind or just stupid, but I don't seem to be able > to find where we do that. > And would it hurt to have that additional check there as well in case > address was modified after the previous check and before being passed to > do_page_fault ? (note: I'm writing this last bit without having mined the > source for info yet).
If find_vma() returns NULL, it is bad_area, and no further tests occur. Otherwise if vma->vm_start <= address, it is good area.
Only when these two conditions are satisifed (find_vma found vma, and this vma begins above vma's vm_start, regs->esp is checked. And as vma->vm_start can be at most 0xFFFFF000 (it is page aligned, and you cannot have vma at 4GB - actually you cannot have vma above 3GB on normal kernel, or 4GB-<whatever>MB on 4G/4G kernel), there is no way how 'address' could be in top 4KB, and so adding 32 to it cannot overflow 32bit variable.
At least I believe this... Petr Vandrovec
- 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/
| |