Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fuse: Fix VM_BUG_ON_PAGE issue while accessing zero ref count page
There is a potential race between fuse_abort_conn() and fuse_copy_page() as shown below, due to which VM_BUG_ON_PAGE crash is observed for accessing a free page. context#1: context#2: fuse_dev_do_read() fuse_abort_conn() ->fuse_copy_args() ->end_requests() ->fuse_copy_pages() ->request_end() ->fuse_copy_page() ->fuse_writepage_end) ->fuse_ref_page() ->fuse_writepage_free() ->__free_page() ->put_page_testzero() ->get_page() ->VM_BUG_ON_PAGE() This results in below crash as when ->put_page_testzero() in context#2 decrease the page reference and get_page() in context#1 accessed it with zero page reference count. [ 174.391095] (1)[10406:Thread-6]page dumped because: VM_BUG_ON_PAGE(((unsigned int) page_ref_count(page) + 127u <= 127u)) [ 174.391113] (1)[10406:Thread-6]page allocated via order 0, migratetype Unmovable, gfp_mask 0x620042(GFP_NOFS|__GFP_HIGHMEM|__GFP_HARDWALL), pid 261, ts 174390946312 ns [ 174.391135] (1)[10406:Thread-6] prep_new_page+0x13c/0x210 [ 174.391148] (1)[10406:Thread-6] get_page_from_freelist+0x21ac/0x2370 [ 174.391161] (1)[10406:Thread-6] __alloc_pages_nodemask+0x244/0x14a8 [ 174.391176] (1)[10406:Thread-6] fuse_writepages_fill+0x150/0x708 [ 174.391190] (1)[10406:Thread-6] write_cache_pages+0x3d8/0x550 [ 174.391202] (1)[10406:Thread-6] fuse_writepages+0x94/0x130 [ 174.391214] (1)[10406:Thread-6] do_writepages+0x74/0x140 [ 174.391228] (1)[10406:Thread-6] __writeback_single_inode+0x168/0x788 [ 174.391239] (1)[10406:Thread-6] writeback_sb_inodes+0x56c/0xab8 [ 174.391251] (1)[10406:Thread-6] __writeback_inodes_wb+0x94/0x180 [ 174.391262] (1)[10406:Thread-6] wb_writeback+0x318/0x618 [ 174.391274] (1)[10406:Thread-6] wb_workfn+0x468/0x828 [ 174.391290] (1)[10406:Thread-6] process_one_work+0x3d0/0x720 [ 174.391302] (1)[10406:Thread-6] worker_thread+0x234/0x4c0 [ 174.391314] (1)[10406:Thread-6] kthread+0x144/0x158 [ 174.391327] (1)[10406:Thread-6] ret_from_fork+0x10/0x1c [ 174.391363] (1)[10406:Thread-6]------------[ cut here ]------------ [ 174.391371] (1)[10406:Thread-6]kernel BUG at include/linux/mm.h:980! [ 174.391381] (1)[10406:Thread-6]Internal error: Oops - BUG: 0 [#1] ... [ 174.486928] (1)[10406:Thread-6]pc : fuse_copy_page+0x750/0x790 [ 174.493029] (1)[10406:Thread-6]lr : fuse_copy_page+0x750/0x790 [ 174.718831] (1)[10406:Thread-6] fuse_copy_page+0x750/0x790 [ 174.718838] (1)[10406:Thread-6] fuse_copy_args+0xb4/0x1e8 [ 174.718843] (1)[10406:Thread-6] fuse_dev_do_read+0x424/0x888 [ 174.718848] (1)[10406:Thread-6] fuse_dev_splice_read+0x94/0x200 [ 174.718856] (1)[10406:Thread-6] __arm64_sys_splice+0x874/0xb20 [ 174.718864] (1)[10406:Thread-6] el0_svc_common+0xc8/0x240 [ 174.718869] (1)[10406:Thread-6] el0_svc_handler+0x6c/0x88 [ 174.718875] (1)[10406:Thread-6] el0_svc+0x8/0xc [ 174.778853] (1)[10406:Thread-6]Kernel panic - not syncing: Fatal Fix this by protecting fuse_ref_page() with the same fc->lock as in fuse_abort_conn(). Changes since V2: - Moved the spin lock from fuse_copy_pages() to fuse_ref_page() Changes since V1: - Modified the logic as per kernel v5.9-rc1. - Added Reported by tag. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
- Loading branch information