Bug 200951
| Summary: | kernel NULL pointer dereference in update_sit_entry | ||
|---|---|---|---|
| Product: | File System | Reporter: | vicencb |
| Component: | f2fs | Assignee: | Default virtual assignee for f2fs (filesystem_f2fs) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | high | CC: | chao |
| Priority: | P1 | ||
| Hardware: | ARM | ||
| OS: | Linux | ||
| Kernel Version: | v4.19-rc1, v4.18.2 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg
sg_readcap sg_vpd fsck.f2fs add some log log results add some log (bis) log results (bis) |
||
|
Description
vicencb
2018-08-27 13:44:43 UTC
Created attachment 278129 [details]
sg_readcap
Created attachment 278131 [details]
sg_vpd
Hi, Is this bug reproducible? Can you run fsck on device to check filesystem consistence. Hi! Yes, it is reproducible. Each time TRIM is enabled via the UDEV rule and the FS mounted with the discard option, the issue is triggered at the very first write attempt. Before mounting fsck.f2fs was successfully run on the FS. Regards, Vicenç. Created attachment 278227 [details]
fsck.f2fs
Hi, just found that the issue is also reproducible when mounted with the "nodiscard" option, enabling TRIM via UDEV is enouth. Created attachment 278233 [details]
add some log
Can you apply this patch attached and reproduce this bug again?
Created attachment 278241 [details]
log results
Hi, here are the results asked for.
Created attachment 278243 [details]
add some log (bis)
Hi, added a few more printk for extra verbosity.
Created attachment 278245 [details]
log results (bis)
The results of the previous patch.
Actually, the problem here is during mount(), both blk_queue_discard(q) and f2fs_sb_has_blkzoned(sbi) return false, so f2fs will skip allocating memory for se->discard_map.
static inline bool f2fs_discard_en(struct f2fs_sb_info *sbi)
{
struct request_queue *q = bdev_get_queue(sbi->sb->s_bdev);
return blk_queue_discard(q) || f2fs_sb_has_blkzoned(sbi);
}
[ 4.372580] f2fs_discard_en(1):0
[ 4.498957] f2fs_discard_en(2):0
But later, during update_sit_entiry(), f2fs_discard_en() return true, then it will cause f2fs to update se->discard_map bitmap, result in panic.
[ 56.939547] f2fs_discard_en(3):1 new_blkaddr:0xFFFF00000AB0383C
[ 56.945027] f2fs_discard_en(5):1 se:0xFFFF8000ED285ED8
Is there any interface we can turn on discard of device in real time?
As stated in the bug description, there is an udev rule to set the provisioning_mode attribute to unmap. When searching for this attribute name, i found this: drivers/scsi/sd.c:749 blk_queue_max_discard_sectors(q, ...); blk_queue_flag_set(QUEUE_FLAG_DISCARD, q); So, it looks like the answer is yes, there is an interface to turn on discard of device in real time. Regards, Vicenç. (In reply to vicencb from comment #12) > As stated in the bug description, there is an udev rule to set Sorry, I missed this one... :( > the provisioning_mode attribute to unmap. When searching for > this attribute name, i found this: > drivers/scsi/sd.c:749 > blk_queue_max_discard_sectors(q, ...); > blk_queue_flag_set(QUEUE_FLAG_DISCARD, q); > > So, it looks like the answer is yes, there is an interface to > turn on discard of device in real time. Alright, let me send one patch to fix this issue. > > Regards, > Vicenç. This could explain why it fails on aarch64 but works on x86_64. When this is tested on aarch64, the f2fs is the root FS, and the udev rule is applied after mount because it is stored in the filesystemm itself. Whereas in the x86_64 case, the udev rule is applied when the disk is plugged in, before mounting. All in all, it is a general issue, not an architecture-specific one. I've sent one patch for this issue, just cc your email, also you can find the patch in below link[1], can you please try this patch to check whether it can fix this issue? [1] https://sourceforge.net/p/linux-f2fs/mailman/message/36407378/ Hi, thank you for being that fast! I have tried it against v4.19-rc2 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=57361846b52bc686112da6ca5368d11210796804 but it does not apply checking file fs/f2fs/debug.c Hunk #1 succeeded at 190 (offset -3 lines). checking file fs/f2fs/f2fs.h Hunk #1 FAILED at 3436. 1 out of 1 hunk FAILED checking file fs/f2fs/file.c checking file fs/f2fs/segment.c Hunk #1 succeeded at 1725 (offset -43 lines). ... Hunk #8 succeeded at 3959 (offset -45 lines). checking file fs/f2fs/super.c Hunk #1 succeeded at 360 (offset -3 lines). Hunk #2 FAILED at 417. Hunk #3 succeeded at 1031 (offset -29 lines). Hunk #4 FAILED at 1440. 2 out of 4 hunks FAILED Which kernel tree should i be using? Regards, Vicenç. Updated in below git link, :) https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git/log/?h=f2fs-dev This issue has been fixed with patch listed in below link, so I tag this issue as resolved one. https://sourceforge.net/p/linux-f2fs/mailman/message/36407519/ |