Hi
Please take a look at this issue.
BUG_ON(v_cluster < le32_to_cpu(rec->e_cpos)) in ocfs2_get_clusters_nocache
has been triggered, so i think ip_alloc_sem is still needed.
the crash have been detailed.
crash> bt
PID: 1558 TASK: 88001245e4a0 CPU: 0 COMMAND: "dd"
#0 [88000
Hi Guanghui,
Please sort out your mail more orderly. It looks really messy! So, rework your
mail by asking
question yourself like:
- What is the problem you are facing?
Looks like a BUG_ON() is triggered. but which BUG_ON()? the backtrace? How
this can be
reroduced?
- What help or answer do y
--- a/aops.c 2017-05-27 01:23:35.591274026 -0400
+++ b/aops.c 2017-05-27 01:29:44.743285821 -0400
@@ -2396,6 +2396,35 @@
return 0;
}
+/*
+ * TODO: Make this into a generic get_blocks function.
+ *
+ * In ocfs2, ip_alloc_sem is used to protect allocation changes on the node.
+ * In direct IO, we ad
Hi
This patch replace that function ocfs2_direct_IO_get_blocks with
this function ocfs2_get_blocks in ocfs2_direct_IO, and remove the
ip_alloc_sem.
but i think ip_alloc_sem is still needed because protect allocation changes is
very correct.
Now, BUG_ON have been tiggered in the process of
This patch replace that function ocfs2_direct_IO_get_blocks with
this function ocfs2_get_blocks in ocfs2_direct_IO, and remove the
ip_alloc_sem.
but i think ip_alloc_sem is still needed because protect allocation changes is
very correct.
Now, BUG_ON have been tiggered in the process of tes
On Tue, Nov 22, 2016 at 10:29:52AM +0800, Junxiao Bi wrote:
> Hi Dan,
>
> It will not cause a real issue. -EAGAIN can be only returned in
> __ocfs2_page_mkwrite() path where "locked_page" is NULL, so that
> function will return VM_FAULT_NOPAGE before accessing "fsdata".
>
Good enough. Thanks fo
Hi Dan,
It will not cause a real issue. -EAGAIN can be only returned in
__ocfs2_page_mkwrite() path where "locked_page" is NULL, so that
function will return VM_FAULT_NOPAGE before accessing "fsdata".
Thanks,
Junxiao.
On 11/17/2016 06:03 PM, Dan Carpenter wrote:
> On Thu, Nov 17, 2016 at 11:08:0
sorry, my analysis is wrong. -EAGAIN will be eaten only when 'type' is
OCFS2_WRITE_MMAP in ocfs2_write_begin_nolock(). so uninitialized 'wc'
will not be dereferenced in ocfs2_dio_get_block() as abnormal branch
can catch error 'ret'.
thanks,
Jun
On 2016-11-17 19:58, piaojun wrote:
> Hi Carpenter,
Hi Carpenter,
I guess this may cause illegal memory access error as follows:
generic_perform_write
--a_ops->write_begin(file, mapping, pos, bytes, flags, &page, &fsdata);
--ocfs2_write_begin_nolock
--ocfs2_grab_pages_for_write
--return -EAGAIN if not enough pages
--'fsdata' will
On Thu, Nov 17, 2016 at 11:08:08AM +0800, Eric Ren wrote:
> Hi,
>
> On 11/16/2016 06:45 PM, Dan Carpenter wrote:
> >On Wed, Nov 16, 2016 at 10:33:49AM +0800, Eric Ren wrote:
> >That silences the warning, of course, but I feel like the code is buggy.
> >How do we know that we don't hit that exit pa
Hi,
On 11/16/2016 06:45 PM, Dan Carpenter wrote:
> On Wed, Nov 16, 2016 at 10:33:49AM +0800, Eric Ren wrote:
> That silences the warning, of course, but I feel like the code is buggy.
> How do we know that we don't hit that exit path?
Sorry, I missed your point. Do you mean the below?
"1817 goto
On Wed, Nov 16, 2016 at 10:33:49AM +0800, Eric Ren wrote:
> >>>fs/ocfs2/aops.c
> >>> 2235
> >>> 2236 ret = ocfs2_write_begin_nolock(inode->i_mapping, pos, len,
> >>> 2237 OCFS2_WRITE_DIRECT, NULL,
> >>> 2238
Hi Dan,
On 11/15/2016 06:36 PM, Dan Carpenter wrote:
> Ryan's email is dead. But this is buggy. Someone please fix it.
>
> regards,
> dan carpenter
>
> On Tue, Nov 15, 2016 at 01:33:30PM +0300, Dan Carpenter wrote:
>> I never got a response on this. I was looking at it today and it still
>> loo
Ryan's email is dead. But this is buggy. Someone please fix it.
regards,
dan carpenter
On Tue, Nov 15, 2016 at 01:33:30PM +0300, Dan Carpenter wrote:
> I never got a response on this. I was looking at it today and it still
> looks buggy to me.
>
> regards,
> dan carpenter
>
> On Wed, Mar 09,
I never got a response on this. I was looking at it today and it still
looks buggy to me.
regards,
dan carpenter
On Wed, Mar 09, 2016 at 01:25:05PM +0300, Dan Carpenter wrote:
> Hello Ryan Ding,
>
> The patch fbe25fb91af5: "ocfs2: fix sparse file & data ordering issue
> in direct io" from Feb 2
Hello Ryan Ding,
The patch fbe25fb91af5: "ocfs2: fix sparse file & data ordering issue
in direct io" from Feb 25, 2016, leads to the following static
checker warning:
fs/ocfs2/aops.c:2242 ocfs2_dio_get_block()
error: potentially dereferencing uninitialized 'wc'.
fs/ocfs2/aops.c
16 matches
Mail list logo
