On Thu, 8 Aug 2013 19:03:31 +0530 Arun KS <arunks.linux@xxxxxxxxx> wrote:
> >From 2558382c8a030f7261e47977ac62412cd78e6d38 Mon Sep 17 00:00:00 2001
> From: Arun KS <arun.ks@xxxxxxxxxxxx>
> Date: Thu, 8 Aug 2013 18:23:04 +0530
> Subject: Seq File: Return error if d_path fails
>
> Return error if d_path fails in seq_path funciton. If we do not return
> from here,
> seq_commit sets seq_file state as overflow. And this continues in a
> loop utill we
> increase the size of seq buf beyond KMALLOC_MAX_SIZE.
>
> ...
>
> --- a/fs/seq_file.c
> +++ b/fs/seq_file.c
> @@ -471,7 +471,8 @@ int seq_path(struct seq_file *m, const struct path
> *path, const char *esc)
> char *end = mangle_path(buf, p, esc);
> if (end)
> res = end - buf;
> - }
> + } else
> + return PTR_ERR(p);
> }
> seq_commit(m, res);
hm, does that really fix the bug? Isn't the core problem the word "or":
/**
* seq_commit - commit data to the buffer
* @m: the seq_file handle
* @num: the number of bytes to commit
*
* Commit @num bytes of data written to a buffer previously acquired
* by seq_buf_get. To signal an error condition, or that the data
^^
* didn't fit in the available space, pass a negative @num value.
*/
seq_path()/seq_commit() is treating a d_path() failure as an overflow
condition, but it isn't.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
