[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADUXgx7-5SQg2wVbJ1rp6DRhepcK9MWU67bixVwhXA6rr0skuA@mail.gmail.com>
Date: Thu, 24 Apr 2014 22:26:50 +0800
From: Fengwei Yin <yfw.kernel@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Fix seq_read dead loop and trigger memory allocation failure.
On Thu, Apr 24, 2014 at 5:58 AM, Al Viro <viro@...iv.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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists