Hi
I was testing this path in august and i have two patch applied for ocfs2
The one your referring and also a changed in file.c
At the time of the test, the two patch were necessary ( and both
suppress a BUG although
not the same one)
Sorry i have no idea if it's still necessary or not, but i prefer to
send you a notice
Vincent ETIENNE
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1998,7 +1998,7 @@ static long ocfs2_fallocate(struct file *file, int
mode, loff_t offset,
sr.l_start = (s64)offset;
sr.l_len = (s64)len;
- return __ocfs2_change_file_space(NULL, inode, offset, cmd, &sr,
+ return __ocfs2_change_file_space(file, inode, offset, cmd, &sr,
change_size);
}
diff --git a/fs/ocfs2/symlink.c b/fs/ocfs2/symlink.c
index f1fbb4b..66edce7 100644
--- a/fs/ocfs2/symlink.c
+++ b/fs/ocfs2/symlink.c
@@ -57,7 +57,7 @@
static int ocfs2_fast_symlink_readpage(struct file *unused, struct page
*page)
{
struct inode *inode = page->mapping->host;
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
int status = ocfs2_read_inode_block(inode, &bh);
struct ocfs2_dinode *fe;
const char *link;
Le 25/02/2013 21:33, Richard Weinberger a ?crit :
> Hi!
>
> Today I encountered the following problem on v3.8:
> [ 28.940032] general protection fault: 0000 [#1] PREEMPT SMP
> ...
> [ 28.984953] Call Trace:
> [ 28.986628 [<ffffffffa04cb200>]
> ocfs2_fast_symlink_readpage+0x70/0x1b0 [ocfs2]
> [ 28.988302] [<ffffffff8110dc49>] ? add_to_page_cache_lru+0x29/0x40
> [ 28.989942] [<ffffffff8110ddca>] do_read_cache_page+0x7a/0x170
> [ 28.991573] [<ffffffff8110def4>] read_cache_page_async+0x14/0x20
> [ 28.993212] [<ffffffff8110df09>] read_cache_page+0x9/0x20
> [ 28.994827] [<ffffffff81170ae5>] page_getlink.isra.9+0x25/0x80
> [ 28.996442] [<ffffffff81170b61>] page_follow_link_light+0x21/0x40
> [ 28.998049] [<ffffffff8117090d>] generic_readlink+0x3d/0xa0
> [ 28.999653] [<ffffffff8116c0db>] sys_readlinkat+0xfb/0x130
> [ 29.001246] [<ffffffff8116c126>] sys_readlink+0x16/0x20
> [ 29.002839] [<ffffffff815d8dad>] system_call_fastpath+0x1a/0x1f
>
> To my utter astonishment I found out that the issue is known since
> August 2012.
> And there is also a trivial fix for it.[0]
> The said fix found it's way into Oracle Unbreakable Linux very quickly,
> but not into mainline.[1]
>
> Now I'm wondering how much Oracle really cares about OCFS2 in mainline?
> Maybe there are some more unfixed vulnerabilities?
>
> Not amused,
> //richard
>
> [0] http://www.mail-archive.com/[email protected]/msg07774.html
> [1] https://oss.oracle.com/pipermail/el-errata/2012-October/003103.html
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>