[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130812144943.a09d6251bc20f8c3d0a6e8d8@linux-foundation.org>
Date: Mon, 12 Aug 2013 14:49:43 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Arun KS <arunks.linux@...il.com>
Cc: viro@...iv.linux.org.uk, matthew@....cx, bfields@...ldses.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
vinayak menon <vinayakm.list@...il.com>,
Nagachandra P <nagachandra@...il.com>,
Vikram MP <mp.vikram@...il.com>
Subject: Re: Seq File: Return error if d_path fails
On Thu, 8 Aug 2013 19:03:31 +0530 Arun KS <arunks.linux@...il.com> wrote:
> >From 2558382c8a030f7261e47977ac62412cd78e6d38 Mon Sep 17 00:00:00 2001
> From: Arun KS <arun.ks@...adcom.com>
> 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-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