On Thu, Apr 24, 2014 at 5:58 AM, Al Viro <v...@zeniv.linux.org.uk> wrote: > On Mon, Apr 21, 2014 at 10:12:42PM +0800, Fengwei Yin wrote: >> When dump /proc/xxx/maps, if d_path return error in seq_path, the >> buffer will be exhaust and trigger dead loop in seq_read. Till >> kmalloc fails with -ENOMEM. > > *WHAT* d_path error? -ENAMETOOLONG, aka. "you've got too little space"? > I could check it and get you back. But I suppose it's not this one because it still fails even I have buffer with 4M size.
>> @@ -295,8 +295,16 @@ show_map_vma(struct seq_file *m, struct vm_area_struct >> *vma, int is_pid) >> * special [heap] marker for the heap: >> */ >> if (file) { >> + size_t sz; >> seq_pad(m, ' '); >> - seq_path(m, &file->f_path, "\n"); >> + /* Save current count. Once seq_path return negtive value, >> + * we need to restore saved count. Otherwise, seq_path will >> + * exhaust the buffer and make seq_read dead loop till >> + * m->buff allocation failure. >> + */ >> + sz = m->count; >> + if (seq_path(m, &file->f_path, "\n") < 0) >> + m->count = sz; > > NAK. No way in hell. Any code playing with m->count that way is broken. > Post the reproducer for that infinite loop; then we'll be able to see > what triggers an impossible error from d_path(). _That_ is where the bug > is, assuming it exists at all. Thanks a lot for checking this. When I play the Android x86_64 emulator (with 64bit kernel) and cat the /proc/xxxx/maps (xxxx is a 32bit process id), seq_read return -ENOMEM. I tried to reproduce the same issue on a native environment. But couldn't reproduce it. I will collect more info and post here. Regards Yin, Fengwei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/