ocfs2_read_blocks() and ocfs2_read_blocks_sync() are both used to read
several blocks from disk. Currently, the input argument *bhs* can be
NULL or NOT. It depends on the caller's behavior. If the function fails
in reading blocks from disk, the corresponding bh will be assigned to
NULL and put.
Ob
Signed-off-by: Changwei Ge
---
fs/ocfs2/dlm/dlmast.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/ocfs2/dlm/dlmast.c b/fs/ocfs2/dlm/dlmast.c
index fd6..39831fc 100644
--- a/fs/ocfs2/dlm/dlmast.c
+++ b/fs/ocfs2/dlm/dlmast.c
@@ -224,14 +224,12 @@ void dlm_do_local_ast(struct dlm_ctxt
When -EIOCBQUEUED returns, it means that aio_complete() will be called
from dio_complete(), which is an asynchronous progress against write_iter.
Generally, IO is a very slow progress than executing instruction, but we
still can't take the risk to access a freed iocb.
And we do face a BUG crash is
On 04/02/2018 02:17 AM, Joseph Qi wrote:
>
> On 18/3/31 01:42, Ashish Samant wrote:
>> While reflinking an inode, we create a new inode in orphan directory, then
>> take EX lock on it, reflink the original inode to orphan inode and release
>> EX lock. Once the lock is released another node might
Hi Changwei,
On 2018/4/10 19:35, Changwei Ge wrote:
> ocfs2_read_blocks() and ocfs2_read_blocks_sync() are both used to read
> several blocks from disk. Currently, the input argument *bhs* can be
> NULL or NOT. It depends on the caller's behavior. If the function fails
> in reading blocks from dis
Hi Changwei,
This patch had been merged into mainline already.
Please see patch a43d24cb3b0b.
thanks,
Jun
On 2018/4/10 19:49, Changwei Ge wrote:
> Signed-off-by: Changwei Ge
> ---
> fs/ocfs2/dlm/dlmast.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/fs/ocfs2/dlm/dlmast.c b/fs/ocf
Hi Changwei,
It looks like a code bug, and 'iocb' should not be freed at this place.
Could this BUG reproduced easily?
thanks,
Jun
On 2018/4/10 20:00, Changwei Ge wrote:
> When -EIOCBQUEUED returns, it means that aio_complete() will be called
> from dio_complete(), which is an asynchronous progr
Hi Jun,
On 2018/4/11 8:43, piaojun wrote:
> Hi Changwei,
>
> This patch had been merged into mainline already.
>
> Please see patch a43d24cb3b0b.
Oops, I forgot to rebase my tree... :(
Thanks for your reminder.
Changwei
>
> thanks,
> Jun
>
> On 2018/4/10 19:49, Changwei Ge wrote:
>> Signed
Hi Jun,
On 2018/4/11 8:52, piaojun wrote:
> Hi Changwei,
>
> It looks like a code bug, and 'iocb' should not be freed at this place.
> Could this BUG reproduced easily?
Actually, it's not easy to be reproduced since IO is much slower than CPU
executing instructions. But the logic here is broken
Hi Jun,
Thanks for your review.
On 2018/4/11 8:40, piaojun wrote:
> Hi Changwei,
>
> On 2018/4/10 19:35, Changwei Ge wrote:
>> ocfs2_read_blocks() and ocfs2_read_blocks_sync() are both used to read
>> several blocks from disk. Currently, the input argument *bhs* can be
>> NULL or NOT. It depends
Hi Changwei,
On 2018/4/11 9:14, Changwei Ge wrote:
> Hi Jun,
>
> Thanks for your review.
>
> On 2018/4/11 8:40, piaojun wrote:
>> Hi Changwei,
>>
>> On 2018/4/10 19:35, Changwei Ge wrote:
>>> ocfs2_read_blocks() and ocfs2_read_blocks_sync() are both used to read
>>> several blocks from disk. Cur
Hi Changwei,
It seems other codes which try to access 'iocb' will also cause error,
right? I think we should find the reason why 'iocb' is freed first.
thanks,
Jun
On 2018/4/11 9:07, Changwei Ge wrote:
> Hi Jun,
>
> On 2018/4/11 8:52, piaojun wrote:
>> Hi Changwei,
>>
>> It looks like a code bu
Hi Jun,
On 2018/4/11 9:52, piaojun wrote:
> Hi Changwei,
>
> It seems other codes which try to access 'iocb' will also cause error,
> right? I think we should find the reason why 'iocb' is freed first.
Which code snippet do you mean? Actually, I have checked most of other parts in
write_iter()
Hi Jun,
Thanks for your patch.
I just applied your patch into my tree and triggered ocfs2-test.
Unfortunately, the very first case fails in making fs since bio can't
accommodate more than 16 vecs.
Of course this is not introduced by your patch. You patch just makes this
hidden issue visible.
Hi Changwei,
The code change just works around the problem, but theoretically the IOCB
object should not be freed before which is handled.
Anyway, if we can find the root cause behind via some way (e.g. inject delay in
some place), the result is more perfect.
Thanks
Gang
>>>
> Hi Jun,
>
>
Hi Jun,
On 2018/4/11 9:43, piaojun wrote:
> Hi Changwei,
>
> On 2018/4/11 9:14, Changwei Ge wrote:
>> Hi Jun,
>>
>> Thanks for your review.
>>
>> On 2018/4/11 8:40, piaojun wrote:
>>> Hi Changwei,
>>>
>>> On 2018/4/10 19:35, Changwei Ge wrote:
ocfs2_read_blocks() and ocfs2_read_blocks_sync()
16 matches
Mail list logo