Hi Andrew, On Tue, Aug 13, 2013 at 3:19 AM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > 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. > I ll send a new patch. Thanks, Arun -- 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
