* [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
@ 2024-07-16 5:44 zhaoyang.huang
2024-07-16 5:50 ` Gao Xiang
0 siblings, 1 reply; 16+ messages in thread
From: zhaoyang.huang @ 2024-07-16 5:44 UTC (permalink / raw)
To: Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu, Sandeep Dhavale,
linux-erofs, linux-kernel, Zhaoyang Huang, steve.kang
From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
scheduling while atomic was reported as below where the schedule_timeout
comes from too_many_isolated when doing direct_reclaim. Fix this by
masking GFP_DIRECT_RECLAIM from gfp.
[ 175.610416][ T618] BUG: scheduling while atomic: kworker/u16:6/618/0x00000000
[ 175.643480][ T618] CPU: 2 PID: 618 Comm: kworker/u16:6 Tainted: G
[ 175.645791][ T618] Workqueue: loop20 loop_workfn
[ 175.646394][ T618] Call trace:
[ 175.646785][ T618] dump_backtrace+0xf4/0x140
[ 175.647345][ T618] show_stack+0x20/0x2c
[ 175.647846][ T618] dump_stack_lvl+0x60/0x84
[ 175.648394][ T618] dump_stack+0x18/0x24
[ 175.648895][ T618] __schedule_bug+0x64/0x90
[ 175.649445][ T618] __schedule+0x680/0x9b8
[ 175.649970][ T618] schedule+0x130/0x1b0
[ 175.650470][ T618] schedule_timeout+0xac/0x1d0
[ 175.651050][ T618] schedule_timeout_uninterruptible+0x24/0x34
[ 175.651789][ T618] __alloc_pages_slowpath+0x8dc/0x121c
[ 175.652455][ T618] __alloc_pages+0x294/0x2fc
[ 175.653011][ T618] erofs_allocpage+0x48/0x58
[ 175.653572][ T618] z_erofs_runqueue+0x314/0x8a4
[ 175.654161][ T618] z_erofs_readahead+0x258/0x318
[ 175.654761][ T618] read_pages+0x88/0x394
[ 175.655275][ T618] page_cache_ra_unbounded+0x1cc/0x23c
[ 175.655939][ T618] page_cache_ra_order+0x27c/0x33c
[ 175.656559][ T618] ondemand_readahead+0x224/0x334
[ 175.657169][ T618] page_cache_async_ra+0x60/0x9c
[ 175.657767][ T618] filemap_get_pages+0x19c/0x7cc
[ 175.658367][ T618] filemap_read+0xf0/0x484
[ 175.658901][ T618] generic_file_read_iter+0x4c/0x15c
[ 175.659543][ T618] do_iter_read+0x224/0x348
[ 175.660100][ T618] vfs_iter_read+0x24/0x38
[ 175.660635][ T618] loop_process_work+0x408/0xa68
[ 175.661236][ T618] loop_workfn+0x28/0x34
[ 175.661751][ T618] process_scheduled_works+0x254/0x4e8
[ 175.662417][ T618] worker_thread+0x24c/0x33c
[ 175.662974][ T618] kthread+0x110/0x1b8
[ 175.663465][ T618] ret_from_fork+0x10/0x20
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
---
fs/erofs/zdata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
index d6fe002a4a71..0213c66d141b 100644
--- a/fs/erofs/zdata.c
+++ b/fs/erofs/zdata.c
@@ -1486,7 +1486,7 @@ static void z_erofs_fill_bio_vec(struct bio_vec *bvec,
folio_unlock(zbv.folio);
folio_put(zbv.folio);
out_allocfolio:
- page = erofs_allocpage(&f->pagepool, gfp | __GFP_NOFAIL);
+ page = erofs_allocpage(&f->pagepool, (gfp | __GFP_NOFAIL) & ~__GFP_DIRECT_RECLAIM);
spin_lock(&pcl->obj.lockref.lock);
if (pcl->compressed_bvecs[nr].folio) {
erofs_pagepool_add(&f->pagepool, page);
--
2.25.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
2024-07-16 5:44 [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage zhaoyang.huang
@ 2024-07-16 5:50 ` Gao Xiang
2024-07-16 6:14 ` Zhaoyang Huang
0 siblings, 1 reply; 16+ messages in thread
From: Gao Xiang @ 2024-07-16 5:50 UTC (permalink / raw)
To: zhaoyang.huang, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, linux-erofs, linux-kernel, Zhaoyang Huang,
steve.kang
On 2024/7/16 13:44, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> scheduling while atomic was reported as below where the schedule_timeout
> comes from too_many_isolated when doing direct_reclaim. Fix this by
> masking GFP_DIRECT_RECLAIM from gfp.
>
> [ 175.610416][ T618] BUG: scheduling while atomic: kworker/u16:6/618/0x00000000
> [ 175.643480][ T618] CPU: 2 PID: 618 Comm: kworker/u16:6 Tainted: G
> [ 175.645791][ T618] Workqueue: loop20 loop_workfn
> [ 175.646394][ T618] Call trace:
> [ 175.646785][ T618] dump_backtrace+0xf4/0x140
> [ 175.647345][ T618] show_stack+0x20/0x2c
> [ 175.647846][ T618] dump_stack_lvl+0x60/0x84
> [ 175.648394][ T618] dump_stack+0x18/0x24
> [ 175.648895][ T618] __schedule_bug+0x64/0x90
> [ 175.649445][ T618] __schedule+0x680/0x9b8
> [ 175.649970][ T618] schedule+0x130/0x1b0
> [ 175.650470][ T618] schedule_timeout+0xac/0x1d0
> [ 175.651050][ T618] schedule_timeout_uninterruptible+0x24/0x34
> [ 175.651789][ T618] __alloc_pages_slowpath+0x8dc/0x121c
> [ 175.652455][ T618] __alloc_pages+0x294/0x2fc
> [ 175.653011][ T618] erofs_allocpage+0x48/0x58
> [ 175.653572][ T618] z_erofs_runqueue+0x314/0x8a4
> [ 175.654161][ T618] z_erofs_readahead+0x258/0x318
> [ 175.654761][ T618] read_pages+0x88/0x394
> [ 175.655275][ T618] page_cache_ra_unbounded+0x1cc/0x23c
> [ 175.655939][ T618] page_cache_ra_order+0x27c/0x33c
> [ 175.656559][ T618] ondemand_readahead+0x224/0x334
> [ 175.657169][ T618] page_cache_async_ra+0x60/0x9c
> [ 175.657767][ T618] filemap_get_pages+0x19c/0x7cc
> [ 175.658367][ T618] filemap_read+0xf0/0x484
> [ 175.658901][ T618] generic_file_read_iter+0x4c/0x15c
> [ 175.659543][ T618] do_iter_read+0x224/0x348
> [ 175.660100][ T618] vfs_iter_read+0x24/0x38
> [ 175.660635][ T618] loop_process_work+0x408/0xa68
> [ 175.661236][ T618] loop_workfn+0x28/0x34
> [ 175.661751][ T618] process_scheduled_works+0x254/0x4e8
> [ 175.662417][ T618] worker_thread+0x24c/0x33c
> [ 175.662974][ T618] kthread+0x110/0x1b8
> [ 175.663465][ T618] ret_from_fork+0x10/0x20
>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
I don't see why it's an atomic context,
so this patch is incorrect.
Thanks,
Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
2024-07-16 5:50 ` Gao Xiang
@ 2024-07-16 6:14 ` Zhaoyang Huang
0 siblings, 0 replies; 16+ messages in thread
From: Zhaoyang Huang @ 2024-07-16 6:14 UTC (permalink / raw)
To: Gao Xiang; +Cc: linux-kernel, zhaoyang.huang, Yue Hu, linux-erofs, steve.kang
On Tue, Jul 16, 2024 at 1:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2024/7/16 13:44, zhaoyang.huang wrote:
> > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >
> > scheduling while atomic was reported as below where the schedule_timeout
> > comes from too_many_isolated when doing direct_reclaim. Fix this by
> > masking GFP_DIRECT_RECLAIM from gfp.
> >
> > [ 175.610416][ T618] BUG: scheduling while atomic: kworker/u16:6/618/0x00000000
> > [ 175.643480][ T618] CPU: 2 PID: 618 Comm: kworker/u16:6 Tainted: G
> > [ 175.645791][ T618] Workqueue: loop20 loop_workfn
> > [ 175.646394][ T618] Call trace:
> > [ 175.646785][ T618] dump_backtrace+0xf4/0x140
> > [ 175.647345][ T618] show_stack+0x20/0x2c
> > [ 175.647846][ T618] dump_stack_lvl+0x60/0x84
> > [ 175.648394][ T618] dump_stack+0x18/0x24
> > [ 175.648895][ T618] __schedule_bug+0x64/0x90
> > [ 175.649445][ T618] __schedule+0x680/0x9b8
> > [ 175.649970][ T618] schedule+0x130/0x1b0
> > [ 175.650470][ T618] schedule_timeout+0xac/0x1d0
> > [ 175.651050][ T618] schedule_timeout_uninterruptible+0x24/0x34
> > [ 175.651789][ T618] __alloc_pages_slowpath+0x8dc/0x121c
> > [ 175.652455][ T618] __alloc_pages+0x294/0x2fc
> > [ 175.653011][ T618] erofs_allocpage+0x48/0x58
> > [ 175.653572][ T618] z_erofs_runqueue+0x314/0x8a4
> > [ 175.654161][ T618] z_erofs_readahead+0x258/0x318
> > [ 175.654761][ T618] read_pages+0x88/0x394
> > [ 175.655275][ T618] page_cache_ra_unbounded+0x1cc/0x23c
> > [ 175.655939][ T618] page_cache_ra_order+0x27c/0x33c
> > [ 175.656559][ T618] ondemand_readahead+0x224/0x334
> > [ 175.657169][ T618] page_cache_async_ra+0x60/0x9c
> > [ 175.657767][ T618] filemap_get_pages+0x19c/0x7cc
> > [ 175.658367][ T618] filemap_read+0xf0/0x484
> > [ 175.658901][ T618] generic_file_read_iter+0x4c/0x15c
> > [ 175.659543][ T618] do_iter_read+0x224/0x348
> > [ 175.660100][ T618] vfs_iter_read+0x24/0x38
> > [ 175.660635][ T618] loop_process_work+0x408/0xa68
> > [ 175.661236][ T618] loop_workfn+0x28/0x34
> > [ 175.661751][ T618] process_scheduled_works+0x254/0x4e8
> > [ 175.662417][ T618] worker_thread+0x24c/0x33c
> > [ 175.662974][ T618] kthread+0x110/0x1b8
> > [ 175.663465][ T618] ret_from_fork+0x10/0x20
> >
> > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> I don't see why it's an atomic context,
> so this patch is incorrect.
Sorry, I should provide more details. page_cache_ra_unbounded() will
call filemap_invalidate_lock_shared(mapping) to ensure the integrity
of page cache during readahead, which will disable preempt.
>
> Thanks,
> Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
@ 2024-07-16 6:14 ` Zhaoyang Huang
0 siblings, 0 replies; 16+ messages in thread
From: Zhaoyang Huang @ 2024-07-16 6:14 UTC (permalink / raw)
To: Gao Xiang
Cc: zhaoyang.huang, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, linux-erofs, linux-kernel, steve.kang
On Tue, Jul 16, 2024 at 1:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2024/7/16 13:44, zhaoyang.huang wrote:
> > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >
> > scheduling while atomic was reported as below where the schedule_timeout
> > comes from too_many_isolated when doing direct_reclaim. Fix this by
> > masking GFP_DIRECT_RECLAIM from gfp.
> >
> > [ 175.610416][ T618] BUG: scheduling while atomic: kworker/u16:6/618/0x00000000
> > [ 175.643480][ T618] CPU: 2 PID: 618 Comm: kworker/u16:6 Tainted: G
> > [ 175.645791][ T618] Workqueue: loop20 loop_workfn
> > [ 175.646394][ T618] Call trace:
> > [ 175.646785][ T618] dump_backtrace+0xf4/0x140
> > [ 175.647345][ T618] show_stack+0x20/0x2c
> > [ 175.647846][ T618] dump_stack_lvl+0x60/0x84
> > [ 175.648394][ T618] dump_stack+0x18/0x24
> > [ 175.648895][ T618] __schedule_bug+0x64/0x90
> > [ 175.649445][ T618] __schedule+0x680/0x9b8
> > [ 175.649970][ T618] schedule+0x130/0x1b0
> > [ 175.650470][ T618] schedule_timeout+0xac/0x1d0
> > [ 175.651050][ T618] schedule_timeout_uninterruptible+0x24/0x34
> > [ 175.651789][ T618] __alloc_pages_slowpath+0x8dc/0x121c
> > [ 175.652455][ T618] __alloc_pages+0x294/0x2fc
> > [ 175.653011][ T618] erofs_allocpage+0x48/0x58
> > [ 175.653572][ T618] z_erofs_runqueue+0x314/0x8a4
> > [ 175.654161][ T618] z_erofs_readahead+0x258/0x318
> > [ 175.654761][ T618] read_pages+0x88/0x394
> > [ 175.655275][ T618] page_cache_ra_unbounded+0x1cc/0x23c
> > [ 175.655939][ T618] page_cache_ra_order+0x27c/0x33c
> > [ 175.656559][ T618] ondemand_readahead+0x224/0x334
> > [ 175.657169][ T618] page_cache_async_ra+0x60/0x9c
> > [ 175.657767][ T618] filemap_get_pages+0x19c/0x7cc
> > [ 175.658367][ T618] filemap_read+0xf0/0x484
> > [ 175.658901][ T618] generic_file_read_iter+0x4c/0x15c
> > [ 175.659543][ T618] do_iter_read+0x224/0x348
> > [ 175.660100][ T618] vfs_iter_read+0x24/0x38
> > [ 175.660635][ T618] loop_process_work+0x408/0xa68
> > [ 175.661236][ T618] loop_workfn+0x28/0x34
> > [ 175.661751][ T618] process_scheduled_works+0x254/0x4e8
> > [ 175.662417][ T618] worker_thread+0x24c/0x33c
> > [ 175.662974][ T618] kthread+0x110/0x1b8
> > [ 175.663465][ T618] ret_from_fork+0x10/0x20
> >
> > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> I don't see why it's an atomic context,
> so this patch is incorrect.
Sorry, I should provide more details. page_cache_ra_unbounded() will
call filemap_invalidate_lock_shared(mapping) to ensure the integrity
of page cache during readahead, which will disable preempt.
>
> Thanks,
> Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
2024-07-16 6:14 ` Zhaoyang Huang
@ 2024-07-16 6:19 ` Gao Xiang
-1 siblings, 0 replies; 16+ messages in thread
From: Gao Xiang @ 2024-07-16 6:19 UTC (permalink / raw)
To: Zhaoyang Huang
Cc: linux-kernel, zhaoyang.huang, Yue Hu, linux-erofs, steve.kang
On 2024/7/16 14:14, Zhaoyang Huang wrote:
> On Tue, Jul 16, 2024 at 1:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2024/7/16 13:44, zhaoyang.huang wrote:
>>> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>>>
>>> scheduling while atomic was reported as below where the schedule_timeout
>>> comes from too_many_isolated when doing direct_reclaim. Fix this by
>>> masking GFP_DIRECT_RECLAIM from gfp.
>>>
>>> [ 175.610416][ T618] BUG: scheduling while atomic: kworker/u16:6/618/0x00000000
>>> [ 175.643480][ T618] CPU: 2 PID: 618 Comm: kworker/u16:6 Tainted: G
>>> [ 175.645791][ T618] Workqueue: loop20 loop_workfn
>>> [ 175.646394][ T618] Call trace:
>>> [ 175.646785][ T618] dump_backtrace+0xf4/0x140
>>> [ 175.647345][ T618] show_stack+0x20/0x2c
>>> [ 175.647846][ T618] dump_stack_lvl+0x60/0x84
>>> [ 175.648394][ T618] dump_stack+0x18/0x24
>>> [ 175.648895][ T618] __schedule_bug+0x64/0x90
>>> [ 175.649445][ T618] __schedule+0x680/0x9b8
>>> [ 175.649970][ T618] schedule+0x130/0x1b0
>>> [ 175.650470][ T618] schedule_timeout+0xac/0x1d0
>>> [ 175.651050][ T618] schedule_timeout_uninterruptible+0x24/0x34
>>> [ 175.651789][ T618] __alloc_pages_slowpath+0x8dc/0x121c
>>> [ 175.652455][ T618] __alloc_pages+0x294/0x2fc
>>> [ 175.653011][ T618] erofs_allocpage+0x48/0x58
>>> [ 175.653572][ T618] z_erofs_runqueue+0x314/0x8a4
>>> [ 175.654161][ T618] z_erofs_readahead+0x258/0x318
>>> [ 175.654761][ T618] read_pages+0x88/0x394
>>> [ 175.655275][ T618] page_cache_ra_unbounded+0x1cc/0x23c
>>> [ 175.655939][ T618] page_cache_ra_order+0x27c/0x33c
>>> [ 175.656559][ T618] ondemand_readahead+0x224/0x334
>>> [ 175.657169][ T618] page_cache_async_ra+0x60/0x9c
>>> [ 175.657767][ T618] filemap_get_pages+0x19c/0x7cc
>>> [ 175.658367][ T618] filemap_read+0xf0/0x484
>>> [ 175.658901][ T618] generic_file_read_iter+0x4c/0x15c
>>> [ 175.659543][ T618] do_iter_read+0x224/0x348
>>> [ 175.660100][ T618] vfs_iter_read+0x24/0x38
>>> [ 175.660635][ T618] loop_process_work+0x408/0xa68
>>> [ 175.661236][ T618] loop_workfn+0x28/0x34
>>> [ 175.661751][ T618] process_scheduled_works+0x254/0x4e8
>>> [ 175.662417][ T618] worker_thread+0x24c/0x33c
>>> [ 175.662974][ T618] kthread+0x110/0x1b8
>>> [ 175.663465][ T618] ret_from_fork+0x10/0x20
>>>
>>> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>>
>> I don't see why it's an atomic context,
>> so this patch is incorrect.
> Sorry, I should provide more details. page_cache_ra_unbounded() will
> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
> of page cache during readahead, which will disable preempt.
Why a rwsem sleepable lock disable preemption? .readahead
context should be always non-atomic context, which is applied
to all kernel filesystems.
Thanks,
Gao Xiang
>>
>> Thanks,
>> Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
@ 2024-07-16 6:19 ` Gao Xiang
0 siblings, 0 replies; 16+ messages in thread
From: Gao Xiang @ 2024-07-16 6:19 UTC (permalink / raw)
To: Zhaoyang Huang
Cc: zhaoyang.huang, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, linux-erofs, linux-kernel, steve.kang
On 2024/7/16 14:14, Zhaoyang Huang wrote:
> On Tue, Jul 16, 2024 at 1:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2024/7/16 13:44, zhaoyang.huang wrote:
>>> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>>>
>>> scheduling while atomic was reported as below where the schedule_timeout
>>> comes from too_many_isolated when doing direct_reclaim. Fix this by
>>> masking GFP_DIRECT_RECLAIM from gfp.
>>>
>>> [ 175.610416][ T618] BUG: scheduling while atomic: kworker/u16:6/618/0x00000000
>>> [ 175.643480][ T618] CPU: 2 PID: 618 Comm: kworker/u16:6 Tainted: G
>>> [ 175.645791][ T618] Workqueue: loop20 loop_workfn
>>> [ 175.646394][ T618] Call trace:
>>> [ 175.646785][ T618] dump_backtrace+0xf4/0x140
>>> [ 175.647345][ T618] show_stack+0x20/0x2c
>>> [ 175.647846][ T618] dump_stack_lvl+0x60/0x84
>>> [ 175.648394][ T618] dump_stack+0x18/0x24
>>> [ 175.648895][ T618] __schedule_bug+0x64/0x90
>>> [ 175.649445][ T618] __schedule+0x680/0x9b8
>>> [ 175.649970][ T618] schedule+0x130/0x1b0
>>> [ 175.650470][ T618] schedule_timeout+0xac/0x1d0
>>> [ 175.651050][ T618] schedule_timeout_uninterruptible+0x24/0x34
>>> [ 175.651789][ T618] __alloc_pages_slowpath+0x8dc/0x121c
>>> [ 175.652455][ T618] __alloc_pages+0x294/0x2fc
>>> [ 175.653011][ T618] erofs_allocpage+0x48/0x58
>>> [ 175.653572][ T618] z_erofs_runqueue+0x314/0x8a4
>>> [ 175.654161][ T618] z_erofs_readahead+0x258/0x318
>>> [ 175.654761][ T618] read_pages+0x88/0x394
>>> [ 175.655275][ T618] page_cache_ra_unbounded+0x1cc/0x23c
>>> [ 175.655939][ T618] page_cache_ra_order+0x27c/0x33c
>>> [ 175.656559][ T618] ondemand_readahead+0x224/0x334
>>> [ 175.657169][ T618] page_cache_async_ra+0x60/0x9c
>>> [ 175.657767][ T618] filemap_get_pages+0x19c/0x7cc
>>> [ 175.658367][ T618] filemap_read+0xf0/0x484
>>> [ 175.658901][ T618] generic_file_read_iter+0x4c/0x15c
>>> [ 175.659543][ T618] do_iter_read+0x224/0x348
>>> [ 175.660100][ T618] vfs_iter_read+0x24/0x38
>>> [ 175.660635][ T618] loop_process_work+0x408/0xa68
>>> [ 175.661236][ T618] loop_workfn+0x28/0x34
>>> [ 175.661751][ T618] process_scheduled_works+0x254/0x4e8
>>> [ 175.662417][ T618] worker_thread+0x24c/0x33c
>>> [ 175.662974][ T618] kthread+0x110/0x1b8
>>> [ 175.663465][ T618] ret_from_fork+0x10/0x20
>>>
>>> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>>
>> I don't see why it's an atomic context,
>> so this patch is incorrect.
> Sorry, I should provide more details. page_cache_ra_unbounded() will
> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
> of page cache during readahead, which will disable preempt.
Why a rwsem sleepable lock disable preemption? .readahead
context should be always non-atomic context, which is applied
to all kernel filesystems.
Thanks,
Gao Xiang
>>
>> Thanks,
>> Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
2024-07-16 6:19 ` Gao Xiang
@ 2024-07-16 6:43 ` Zhaoyang Huang
-1 siblings, 0 replies; 16+ messages in thread
From: Zhaoyang Huang @ 2024-07-16 6:43 UTC (permalink / raw)
To: Gao Xiang; +Cc: linux-kernel, zhaoyang.huang, Yue Hu, linux-erofs, steve.kang
On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2024/7/16 14:14, Zhaoyang Huang wrote:
> > On Tue, Jul 16, 2024 at 1:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>
> >>
> >>
> >> On 2024/7/16 13:44, zhaoyang.huang wrote:
> >>> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >>>
> >>> scheduling while atomic was reported as below where the schedule_timeout
> >>> comes from too_many_isolated when doing direct_reclaim. Fix this by
> >>> masking GFP_DIRECT_RECLAIM from gfp.
> >>>
> >>> [ 175.610416][ T618] BUG: scheduling while atomic: kworker/u16:6/618/0x00000000
> >>> [ 175.643480][ T618] CPU: 2 PID: 618 Comm: kworker/u16:6 Tainted: G
> >>> [ 175.645791][ T618] Workqueue: loop20 loop_workfn
> >>> [ 175.646394][ T618] Call trace:
> >>> [ 175.646785][ T618] dump_backtrace+0xf4/0x140
> >>> [ 175.647345][ T618] show_stack+0x20/0x2c
> >>> [ 175.647846][ T618] dump_stack_lvl+0x60/0x84
> >>> [ 175.648394][ T618] dump_stack+0x18/0x24
> >>> [ 175.648895][ T618] __schedule_bug+0x64/0x90
> >>> [ 175.649445][ T618] __schedule+0x680/0x9b8
> >>> [ 175.649970][ T618] schedule+0x130/0x1b0
> >>> [ 175.650470][ T618] schedule_timeout+0xac/0x1d0
> >>> [ 175.651050][ T618] schedule_timeout_uninterruptible+0x24/0x34
> >>> [ 175.651789][ T618] __alloc_pages_slowpath+0x8dc/0x121c
> >>> [ 175.652455][ T618] __alloc_pages+0x294/0x2fc
> >>> [ 175.653011][ T618] erofs_allocpage+0x48/0x58
> >>> [ 175.653572][ T618] z_erofs_runqueue+0x314/0x8a4
> >>> [ 175.654161][ T618] z_erofs_readahead+0x258/0x318
> >>> [ 175.654761][ T618] read_pages+0x88/0x394
> >>> [ 175.655275][ T618] page_cache_ra_unbounded+0x1cc/0x23c
> >>> [ 175.655939][ T618] page_cache_ra_order+0x27c/0x33c
> >>> [ 175.656559][ T618] ondemand_readahead+0x224/0x334
> >>> [ 175.657169][ T618] page_cache_async_ra+0x60/0x9c
> >>> [ 175.657767][ T618] filemap_get_pages+0x19c/0x7cc
> >>> [ 175.658367][ T618] filemap_read+0xf0/0x484
> >>> [ 175.658901][ T618] generic_file_read_iter+0x4c/0x15c
> >>> [ 175.659543][ T618] do_iter_read+0x224/0x348
> >>> [ 175.660100][ T618] vfs_iter_read+0x24/0x38
> >>> [ 175.660635][ T618] loop_process_work+0x408/0xa68
> >>> [ 175.661236][ T618] loop_workfn+0x28/0x34
> >>> [ 175.661751][ T618] process_scheduled_works+0x254/0x4e8
> >>> [ 175.662417][ T618] worker_thread+0x24c/0x33c
> >>> [ 175.662974][ T618] kthread+0x110/0x1b8
> >>> [ 175.663465][ T618] ret_from_fork+0x10/0x20
> >>>
> >>> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >>
> >> I don't see why it's an atomic context,
> >> so this patch is incorrect.
> > Sorry, I should provide more details. page_cache_ra_unbounded() will
> > call filemap_invalidate_lock_shared(mapping) to ensure the integrity
> > of page cache during readahead, which will disable preempt.
>
> Why a rwsem sleepable lock disable preemption?
emm, that's the original design of down_read()
> context should be always non-atomic context, which is applied
> to all kernel filesystems.
AFAICT, filemap_fault/read have added the folios of readahead to page
cache which means the aops->readahead basically just need to map the
block to this folios and then launch the bio. The erofs is a little
bit different to others as it has to alloc_pages for decompression
when doing this.
>
> Thanks,
> Gao Xiang
>
> >>
> >> Thanks,
> >> Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
@ 2024-07-16 6:43 ` Zhaoyang Huang
0 siblings, 0 replies; 16+ messages in thread
From: Zhaoyang Huang @ 2024-07-16 6:43 UTC (permalink / raw)
To: Gao Xiang
Cc: zhaoyang.huang, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, linux-erofs, linux-kernel, steve.kang
On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2024/7/16 14:14, Zhaoyang Huang wrote:
> > On Tue, Jul 16, 2024 at 1:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>
> >>
> >>
> >> On 2024/7/16 13:44, zhaoyang.huang wrote:
> >>> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >>>
> >>> scheduling while atomic was reported as below where the schedule_timeout
> >>> comes from too_many_isolated when doing direct_reclaim. Fix this by
> >>> masking GFP_DIRECT_RECLAIM from gfp.
> >>>
> >>> [ 175.610416][ T618] BUG: scheduling while atomic: kworker/u16:6/618/0x00000000
> >>> [ 175.643480][ T618] CPU: 2 PID: 618 Comm: kworker/u16:6 Tainted: G
> >>> [ 175.645791][ T618] Workqueue: loop20 loop_workfn
> >>> [ 175.646394][ T618] Call trace:
> >>> [ 175.646785][ T618] dump_backtrace+0xf4/0x140
> >>> [ 175.647345][ T618] show_stack+0x20/0x2c
> >>> [ 175.647846][ T618] dump_stack_lvl+0x60/0x84
> >>> [ 175.648394][ T618] dump_stack+0x18/0x24
> >>> [ 175.648895][ T618] __schedule_bug+0x64/0x90
> >>> [ 175.649445][ T618] __schedule+0x680/0x9b8
> >>> [ 175.649970][ T618] schedule+0x130/0x1b0
> >>> [ 175.650470][ T618] schedule_timeout+0xac/0x1d0
> >>> [ 175.651050][ T618] schedule_timeout_uninterruptible+0x24/0x34
> >>> [ 175.651789][ T618] __alloc_pages_slowpath+0x8dc/0x121c
> >>> [ 175.652455][ T618] __alloc_pages+0x294/0x2fc
> >>> [ 175.653011][ T618] erofs_allocpage+0x48/0x58
> >>> [ 175.653572][ T618] z_erofs_runqueue+0x314/0x8a4
> >>> [ 175.654161][ T618] z_erofs_readahead+0x258/0x318
> >>> [ 175.654761][ T618] read_pages+0x88/0x394
> >>> [ 175.655275][ T618] page_cache_ra_unbounded+0x1cc/0x23c
> >>> [ 175.655939][ T618] page_cache_ra_order+0x27c/0x33c
> >>> [ 175.656559][ T618] ondemand_readahead+0x224/0x334
> >>> [ 175.657169][ T618] page_cache_async_ra+0x60/0x9c
> >>> [ 175.657767][ T618] filemap_get_pages+0x19c/0x7cc
> >>> [ 175.658367][ T618] filemap_read+0xf0/0x484
> >>> [ 175.658901][ T618] generic_file_read_iter+0x4c/0x15c
> >>> [ 175.659543][ T618] do_iter_read+0x224/0x348
> >>> [ 175.660100][ T618] vfs_iter_read+0x24/0x38
> >>> [ 175.660635][ T618] loop_process_work+0x408/0xa68
> >>> [ 175.661236][ T618] loop_workfn+0x28/0x34
> >>> [ 175.661751][ T618] process_scheduled_works+0x254/0x4e8
> >>> [ 175.662417][ T618] worker_thread+0x24c/0x33c
> >>> [ 175.662974][ T618] kthread+0x110/0x1b8
> >>> [ 175.663465][ T618] ret_from_fork+0x10/0x20
> >>>
> >>> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >>
> >> I don't see why it's an atomic context,
> >> so this patch is incorrect.
> > Sorry, I should provide more details. page_cache_ra_unbounded() will
> > call filemap_invalidate_lock_shared(mapping) to ensure the integrity
> > of page cache during readahead, which will disable preempt.
>
> Why a rwsem sleepable lock disable preemption?
emm, that's the original design of down_read()
> context should be always non-atomic context, which is applied
> to all kernel filesystems.
AFAICT, filemap_fault/read have added the folios of readahead to page
cache which means the aops->readahead basically just need to map the
block to this folios and then launch the bio. The erofs is a little
bit different to others as it has to alloc_pages for decompression
when doing this.
>
> Thanks,
> Gao Xiang
>
> >>
> >> Thanks,
> >> Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
2024-07-16 6:43 ` Zhaoyang Huang
@ 2024-07-16 6:46 ` Gao Xiang
-1 siblings, 0 replies; 16+ messages in thread
From: Gao Xiang @ 2024-07-16 6:46 UTC (permalink / raw)
To: Zhaoyang Huang
Cc: linux-kernel, zhaoyang.huang, Yue Hu, linux-erofs, steve.kang
On 2024/7/16 14:43, Zhaoyang Huang wrote:
> On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>>
>>
...
>>>>
>>>> I don't see why it's an atomic context,
>>>> so this patch is incorrect.
>>> Sorry, I should provide more details. page_cache_ra_unbounded() will
>>> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
>>> of page cache during readahead, which will disable preempt.
>>
>> Why a rwsem sleepable lock disable preemption?
> emm, that's the original design of down_read()
No.
>
>> context should be always non-atomic context, which is applied
>> to all kernel filesystems.
> AFAICT, filemap_fault/read have added the folios of readahead to page
> cache which means the aops->readahead basically just need to map the
> block to this folios and then launch the bio. The erofs is a little
> bit different to others as it has to alloc_pages for decompression
> when doing this.
Interesting. The whole .readahead is sleepable, including
submit block I/Os to storage.
Nacked-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Thanks,
Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
@ 2024-07-16 6:46 ` Gao Xiang
0 siblings, 0 replies; 16+ messages in thread
From: Gao Xiang @ 2024-07-16 6:46 UTC (permalink / raw)
To: Zhaoyang Huang
Cc: zhaoyang.huang, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, linux-erofs, linux-kernel, steve.kang
On 2024/7/16 14:43, Zhaoyang Huang wrote:
> On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>>
>>
...
>>>>
>>>> I don't see why it's an atomic context,
>>>> so this patch is incorrect.
>>> Sorry, I should provide more details. page_cache_ra_unbounded() will
>>> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
>>> of page cache during readahead, which will disable preempt.
>>
>> Why a rwsem sleepable lock disable preemption?
> emm, that's the original design of down_read()
No.
>
>> context should be always non-atomic context, which is applied
>> to all kernel filesystems.
> AFAICT, filemap_fault/read have added the folios of readahead to page
> cache which means the aops->readahead basically just need to map the
> block to this folios and then launch the bio. The erofs is a little
> bit different to others as it has to alloc_pages for decompression
> when doing this.
Interesting. The whole .readahead is sleepable, including
submit block I/Os to storage.
Nacked-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Thanks,
Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
2024-07-16 6:46 ` Gao Xiang
@ 2024-07-16 6:50 ` Gao Xiang
-1 siblings, 0 replies; 16+ messages in thread
From: Gao Xiang @ 2024-07-16 6:50 UTC (permalink / raw)
To: Zhaoyang Huang
Cc: linux-kernel, zhaoyang.huang, Yue Hu, linux-erofs, steve.kang
On 2024/7/16 14:46, Gao Xiang wrote:
>
>
> On 2024/7/16 14:43, Zhaoyang Huang wrote:
>> On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>>
>>>
>>>
>
> ...
>
>>>>>
>>>>> I don't see why it's an atomic context,
>>>>> so this patch is incorrect.
>>>> Sorry, I should provide more details. page_cache_ra_unbounded() will
>>>> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
>>>> of page cache during readahead, which will disable preempt.
>>>
>>> Why a rwsem sleepable lock disable preemption?
>> emm, that's the original design of down_read()
>
> No.
>
>>
>>> context should be always non-atomic context, which is applied
>>> to all kernel filesystems.
>> AFAICT, filemap_fault/read have added the folios of readahead to page
>> cache which means the aops->readahead basically just need to map the
>> block to this folios and then launch the bio. The erofs is a little
>> bit different to others as it has to alloc_pages for decompression
>> when doing this.
>
> Interesting. The whole .readahead is sleepable, including
> submit block I/Os to storage.
Also, please don't imagine your stack trace if it's a non-upstream
kernel.
>
> Nacked-by: Gao Xiang <hsiangkao@linux.alibaba.com>
>
> Thanks,
> Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
@ 2024-07-16 6:50 ` Gao Xiang
0 siblings, 0 replies; 16+ messages in thread
From: Gao Xiang @ 2024-07-16 6:50 UTC (permalink / raw)
To: Zhaoyang Huang
Cc: zhaoyang.huang, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, linux-erofs, linux-kernel, steve.kang
On 2024/7/16 14:46, Gao Xiang wrote:
>
>
> On 2024/7/16 14:43, Zhaoyang Huang wrote:
>> On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>>
>>>
>>>
>
> ...
>
>>>>>
>>>>> I don't see why it's an atomic context,
>>>>> so this patch is incorrect.
>>>> Sorry, I should provide more details. page_cache_ra_unbounded() will
>>>> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
>>>> of page cache during readahead, which will disable preempt.
>>>
>>> Why a rwsem sleepable lock disable preemption?
>> emm, that's the original design of down_read()
>
> No.
>
>>
>>> context should be always non-atomic context, which is applied
>>> to all kernel filesystems.
>> AFAICT, filemap_fault/read have added the folios of readahead to page
>> cache which means the aops->readahead basically just need to map the
>> block to this folios and then launch the bio. The erofs is a little
>> bit different to others as it has to alloc_pages for decompression
>> when doing this.
>
> Interesting. The whole .readahead is sleepable, including
> submit block I/Os to storage.
Also, please don't imagine your stack trace if it's a non-upstream
kernel.
>
> Nacked-by: Gao Xiang <hsiangkao@linux.alibaba.com>
>
> Thanks,
> Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
2024-07-16 6:50 ` Gao Xiang
@ 2024-07-16 7:41 ` Zhaoyang Huang
-1 siblings, 0 replies; 16+ messages in thread
From: Zhaoyang Huang @ 2024-07-16 7:41 UTC (permalink / raw)
To: Gao Xiang; +Cc: linux-kernel, zhaoyang.huang, Yue Hu, linux-erofs, steve.kang
On Tue, Jul 16, 2024 at 2:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2024/7/16 14:46, Gao Xiang wrote:
> >
> >
> > On 2024/7/16 14:43, Zhaoyang Huang wrote:
> >> On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>>
> >>>
> >>>
> >
> > ...
> >
> >>>>>
> >>>>> I don't see why it's an atomic context,
> >>>>> so this patch is incorrect.
> >>>> Sorry, I should provide more details. page_cache_ra_unbounded() will
> >>>> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
> >>>> of page cache during readahead, which will disable preempt.
> >>>
> >>> Why a rwsem sleepable lock disable preemption?
> >> emm, that's the original design of down_read()
> >
> > No.
> >
> >>
> >>> context should be always non-atomic context, which is applied
> >>> to all kernel filesystems.
> >> AFAICT, filemap_fault/read have added the folios of readahead to page
> >> cache which means the aops->readahead basically just need to map the
> >> block to this folios and then launch the bio. The erofs is a little
> >> bit different to others as it has to alloc_pages for decompression
> >> when doing this.
> >
> > Interesting. The whole .readahead is sleepable, including
> > submit block I/Os to storage.
>
> Also, please don't imagine your stack trace if it's a non-upstream
> kernel.
ok, it should be caused by a vendor hook function of the android
system. sorry for interrupting by my stupid.
>
> >
> > Nacked-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> >
> > Thanks,
> > Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
@ 2024-07-16 7:41 ` Zhaoyang Huang
0 siblings, 0 replies; 16+ messages in thread
From: Zhaoyang Huang @ 2024-07-16 7:41 UTC (permalink / raw)
To: Gao Xiang
Cc: zhaoyang.huang, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, linux-erofs, linux-kernel, steve.kang
On Tue, Jul 16, 2024 at 2:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2024/7/16 14:46, Gao Xiang wrote:
> >
> >
> > On 2024/7/16 14:43, Zhaoyang Huang wrote:
> >> On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>>
> >>>
> >>>
> >
> > ...
> >
> >>>>>
> >>>>> I don't see why it's an atomic context,
> >>>>> so this patch is incorrect.
> >>>> Sorry, I should provide more details. page_cache_ra_unbounded() will
> >>>> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
> >>>> of page cache during readahead, which will disable preempt.
> >>>
> >>> Why a rwsem sleepable lock disable preemption?
> >> emm, that's the original design of down_read()
> >
> > No.
> >
> >>
> >>> context should be always non-atomic context, which is applied
> >>> to all kernel filesystems.
> >> AFAICT, filemap_fault/read have added the folios of readahead to page
> >> cache which means the aops->readahead basically just need to map the
> >> block to this folios and then launch the bio. The erofs is a little
> >> bit different to others as it has to alloc_pages for decompression
> >> when doing this.
> >
> > Interesting. The whole .readahead is sleepable, including
> > submit block I/Os to storage.
>
> Also, please don't imagine your stack trace if it's a non-upstream
> kernel.
ok, it should be caused by a vendor hook function of the android
system. sorry for interrupting by my stupid.
>
> >
> > Nacked-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> >
> > Thanks,
> > Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
2024-07-16 7:41 ` Zhaoyang Huang
@ 2024-07-16 7:47 ` Gao Xiang
-1 siblings, 0 replies; 16+ messages in thread
From: Gao Xiang @ 2024-07-16 7:47 UTC (permalink / raw)
To: Zhaoyang Huang
Cc: linux-kernel, zhaoyang.huang, Yue Hu, linux-erofs, steve.kang
On 2024/7/16 15:41, Zhaoyang Huang wrote:
> On Tue, Jul 16, 2024 at 2:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2024/7/16 14:46, Gao Xiang wrote:
>>>
>>>
>>> On 2024/7/16 14:43, Zhaoyang Huang wrote:
>>>> On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>>>>
>>>>>
>>>>>
>>>
>>> ...
>>>
>>>>>>>
>>>>>>> I don't see why it's an atomic context,
>>>>>>> so this patch is incorrect.
>>>>>> Sorry, I should provide more details. page_cache_ra_unbounded() will
>>>>>> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
>>>>>> of page cache during readahead, which will disable preempt.
>>>>>
>>>>> Why a rwsem sleepable lock disable preemption?
>>>> emm, that's the original design of down_read()
>>>
>>> No.
>>>
>>>>
>>>>> context should be always non-atomic context, which is applied
>>>>> to all kernel filesystems.
>>>> AFAICT, filemap_fault/read have added the folios of readahead to page
>>>> cache which means the aops->readahead basically just need to map the
>>>> block to this folios and then launch the bio. The erofs is a little
>>>> bit different to others as it has to alloc_pages for decompression
>>>> when doing this.
>>>
>>> Interesting. The whole .readahead is sleepable, including
>>> submit block I/Os to storage.
>>
>> Also, please don't imagine your stack trace if it's a non-upstream
>> kernel.
> ok, it should be caused by a vendor hook function of the android
> system. sorry for interrupting by my stupid.
okay, thanks for confirmation.
Also more words may be useful here: Note that .readahead doesn't
just map the block to this folios. Even an uncompressed fs could
allocate/read (submit+wait) meta folio/blocks to get the block
mapping from these meta blocks and sleep in this context.
Thanks,
Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage
@ 2024-07-16 7:47 ` Gao Xiang
0 siblings, 0 replies; 16+ messages in thread
From: Gao Xiang @ 2024-07-16 7:47 UTC (permalink / raw)
To: Zhaoyang Huang
Cc: zhaoyang.huang, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, linux-erofs, linux-kernel, steve.kang
On 2024/7/16 15:41, Zhaoyang Huang wrote:
> On Tue, Jul 16, 2024 at 2:50 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2024/7/16 14:46, Gao Xiang wrote:
>>>
>>>
>>> On 2024/7/16 14:43, Zhaoyang Huang wrote:
>>>> On Tue, Jul 16, 2024 at 2:20 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>>>>
>>>>>
>>>>>
>>>
>>> ...
>>>
>>>>>>>
>>>>>>> I don't see why it's an atomic context,
>>>>>>> so this patch is incorrect.
>>>>>> Sorry, I should provide more details. page_cache_ra_unbounded() will
>>>>>> call filemap_invalidate_lock_shared(mapping) to ensure the integrity
>>>>>> of page cache during readahead, which will disable preempt.
>>>>>
>>>>> Why a rwsem sleepable lock disable preemption?
>>>> emm, that's the original design of down_read()
>>>
>>> No.
>>>
>>>>
>>>>> context should be always non-atomic context, which is applied
>>>>> to all kernel filesystems.
>>>> AFAICT, filemap_fault/read have added the folios of readahead to page
>>>> cache which means the aops->readahead basically just need to map the
>>>> block to this folios and then launch the bio. The erofs is a little
>>>> bit different to others as it has to alloc_pages for decompression
>>>> when doing this.
>>>
>>> Interesting. The whole .readahead is sleepable, including
>>> submit block I/Os to storage.
>>
>> Also, please don't imagine your stack trace if it's a non-upstream
>> kernel.
> ok, it should be caused by a vendor hook function of the android
> system. sorry for interrupting by my stupid.
okay, thanks for confirmation.
Also more words may be useful here: Note that .readahead doesn't
just map the block to this folios. Even an uncompressed fs could
allocate/read (submit+wait) meta folio/blocks to get the block
mapping from these meta blocks and sleep in this context.
Thanks,
Gao Xiang
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-07-16 7:47 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-16 5:44 [PATCH] fs: fix schedule while atomic caused by gfp of erofs_allocpage zhaoyang.huang
2024-07-16 5:50 ` Gao Xiang
2024-07-16 6:14 ` Zhaoyang Huang
2024-07-16 6:14 ` Zhaoyang Huang
2024-07-16 6:19 ` Gao Xiang
2024-07-16 6:19 ` Gao Xiang
2024-07-16 6:43 ` Zhaoyang Huang
2024-07-16 6:43 ` Zhaoyang Huang
2024-07-16 6:46 ` Gao Xiang
2024-07-16 6:46 ` Gao Xiang
2024-07-16 6:50 ` Gao Xiang
2024-07-16 6:50 ` Gao Xiang
2024-07-16 7:41 ` Zhaoyang Huang
2024-07-16 7:41 ` Zhaoyang Huang
2024-07-16 7:47 ` Gao Xiang
2024-07-16 7:47 ` Gao Xiang
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.