On 05/10, Andy Lutomirski wrote: > > On May 10, 2016 11:21 AM, "Oleg Nesterov" <oleg@xxxxxxxxxx> wrote: > > > > On 05/10, Andy Lutomirski wrote: > > > > > > - xol_add_vma: This one is weird: uprobes really is doing something > > > behind the task's back, and the addresses need to be consistent with > > > the address width. I'm not quite sure what to do here. > > > > It can use mm->task_size instead, plus this is just a hint. And perhaps > > mm->task_size should have more users, say get_unmapped_area... > > Ick. I hadn't noticed mm->task_size. We have a *lot* of different > indicators of task size. mm->task_size appears to have basically no > useful uses except maybe for ppc. > > On x86, bitness can change without telling the kernel, and tasks > running in 64-bit mode can do 32-bit syscalls. Sure, but imo this doesn't mean that mm->task_size or (say) is_64bit_mm() make no sense. > So maybe I should add mm->task_size to my list of things that would be > nice to remove. Or maybe I'm just tilting at windmills. I dunno. But afaics there is no other way to look at foreign mm and find out its limit. Say, the usage of mm->task_size in validate_range() looks valid even if (afaics) nothing bad can happen if start/end >= task_size, so validate_range() could just check that len+start doesn't overflow. Oleg. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>