On 2018/1/11 15:57, Gang He wrote:
>
>
>
>> On 2018/1/11 15:19, Gang He wrote:
>>>
>>>
>>>
>>
On 2018/1/11 12:31, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/11 11:33, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>>
On 2018/1/11
Looks good.
>>>
> We need catch the errno returned by ocfs2_xattr_get_nolock() and assign
> it to 'ret' for printing and noticing upper callers.
>
> Signed-off-by: Jun Piao
> Reviewed-by: Alex Chen
> Reviewed-by: Yiwen Jiang
We need catch the errno returned by ocfs2_xattr_get_nolock() and assign
it to 'ret' for printing and noticing upper callers.
Signed-off-by: Jun Piao
Reviewed-by: Alex Chen
Reviewed-by: Yiwen Jiang
---
fs/ocfs2/xattr.c | 1 +
1
Acked-by: Changwei Ge
On 2018/1/11 16:14, piaojun wrote:
> We need catch the errno returned by ocfs2_xattr_get_nolock() and assign
> it to 'ret' for printing and noticing upper callers.
>
> Signed-off-by: Jun Piao
> Reviewed-by: Alex Chen
HiCédric,
Sorry I can't answer your question, but we are trying to.
Please be patient.
On 2018/1/11 19:52, BASSAGET Cédric wrote:
> Hi Changwei,
>
> short question : Will the stable release of kernel 4.15 fix this bug ?
> Regards
>
> 2018-01-11 8:06 GMT+01:00 Changwei Ge
Hi all,
Now we are testing ocfs2 with 4.14 kernel, and we finding a deadlock with
umount and ocfs2 workqueue triggered by ocfs2rec thread. The stack as follows:
journal recovery work:
[] call_rwsem_down_read_failed+0x14/0x30
[] ocfs2_finish_quota_recovery+0x62/0x450 [ocfs2]
[]
Hi Changkuo,
You said s_umount was acquired by umount and ocfs2rec was blocked when
acquiring it. But you didn't describe why umount was blocked.
Thanks,
Joseph
On 18/1/12 11:43, Shichangkuo wrote:
> Hi all,
> Now we are testing ocfs2 with 4.14 kernel, and we finding a deadlock with
> umount
Hi Joseph
Thanks for replying.
Umount will flush the ocfs2 workqueue in function
ocfs2_truncate_log_shutdown and journal recovery is one work of ocfs2 wq.
Thanks
Changkuo
> -Original Message-
> From: Joseph Qi [mailto:jiangqi...@gmail.com]
> Sent: Friday, January 12, 2018 1:51