Re: [f2fs-dev] [PATCH] f2fs: add additional sanity check in f2fs_acl_from_disk()
Hi Jaegeuk, Could you update dev-test branch? so I can rebase my patch on it. :) On 2018/9/5 12:28, Jaegeuk Kim wrote: > On 08/30, Chengguang Xu wrote: >> Add additinal sanity check for irregular case(e.g. corruption). >> If size of extended attribution is smaller than size of acl header, >> then return -EINVAL. >> >> Signed-off-by: Chengguang Xu >> --- >> fs/f2fs/acl.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c >> index 111824199a88..79e9ea773070 100644 >> --- a/fs/f2fs/acl.c >> +++ b/fs/f2fs/acl.c >> @@ -53,6 +53,9 @@ static struct posix_acl *f2fs_acl_from_disk(const char >> *value, size_t size) >> struct f2fs_acl_entry *entry = (struct f2fs_acl_entry *)(hdr + 1); >> const char *end = value + size; >> >> +if (size < sizeof(f2fs_acl_header)) > > sizeof(struct f2fs_acl_header) > > I fixed the above, and merged. > > Thanks, > >> +return ERR_PTR(-EINVAL); >> + >> if (hdr->a_version != cpu_to_le32(F2FS_ACL_VERSION)) >> return ERR_PTR(-EINVAL); >> >> -- >> 2.17.1 > > . > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH] f2fs: add additional sanity check in f2fs_acl_from_disk()
On 08/30, Chengguang Xu wrote: > Add additinal sanity check for irregular case(e.g. corruption). > If size of extended attribution is smaller than size of acl header, > then return -EINVAL. > > Signed-off-by: Chengguang Xu > --- > fs/f2fs/acl.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c > index 111824199a88..79e9ea773070 100644 > --- a/fs/f2fs/acl.c > +++ b/fs/f2fs/acl.c > @@ -53,6 +53,9 @@ static struct posix_acl *f2fs_acl_from_disk(const char > *value, size_t size) > struct f2fs_acl_entry *entry = (struct f2fs_acl_entry *)(hdr + 1); > const char *end = value + size; > > + if (size < sizeof(f2fs_acl_header)) sizeof(struct f2fs_acl_header) I fixed the above, and merged. Thanks, > + return ERR_PTR(-EINVAL); > + > if (hdr->a_version != cpu_to_le32(F2FS_ACL_VERSION)) > return ERR_PTR(-EINVAL); > > -- > 2.17.1 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Are there limitation to the number of named pipes/FIFO's supported by F2FS?
On 09/05, Chao Yu wrote: > On 2018/9/5 0:28, Patrick Doyle wrote: > > I have created an f2fs partition on which to build embedded Linux > > images (using Yocto/OpenEmbedded/Bitbake). > > > > I just had a build fail where all 20 parallel makes failed with errors > > of the form: > > > > OSError: [Errno 5] Input/output error: > > '/home/wpd/src/20180904-test/apps_proc/poky/build/tmp-glibc/work/armv7a-vfp-neon-oe-linux-gnueabi/libxml2/2.9.2-r0/temp/fifo.32426' > > I don't remember there is any restriction to create named pipes/FIFO. If you > can > provider more info about the building failure, maybe I can help to trouble > shoot > the issue. > > Is there no more free inode space? can you show me filesystem usage by 'stat > -f'? Me too. I don't think F2FS does something on pipes. :P > > > > > This build completed successfully in the past, including just this > > morning (on this filesystem). > > > > I believe by design (and benchmarks I have researched) that F2FS is > > the best approach for SSD based file systems, but this will mark the > > second time in less than a week of having put F2FS in operation that I > > will have to back up my partition, reformat it with different flags, > > and restore it from my backup. I am now frustrated. > > > > What options would you recommend for a 1TB SSD formatted with F2FS to > > be used in an environment that generates Linux system images? This > > environment creates many object files, named pipes, logfiles, etc... > > > > I will start my new backup now, and hope to learn your recommendation > > before I am ready to issue my next mkfs command. > > Do you upgrade both mkfs and kernel? and use mkfs -i to format your ssd > device? > > Thanks, > > > > > --wpd > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > Linux-f2fs-devel mailing list > > Linux-f2fs-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 1/2] f2fs: set 4KB discard granularity by default
Hi,
On 2018/9/4 22:36, Ju Hyung Park wrote:
> Hi,
>
> I was wondering what would be the negatives on reducing the discard
> granularity
We may send more small-sized discard, which cost more IO times and lifetime, but
without this, we may heap up too many undiscard pages in device, it can make
write GC slower and cost more flash lifetime.
Thanks,
> other than making discard more aggressive(hence higher overhead and latency?).
>
> Thanks.
>
> On Tue, Aug 14, 2018 at 4:08 PM Chao Yu wrote:
>>
>> On 2018/8/14 12:13, Jaegeuk Kim wrote:
>>> On 08/10, Chao Yu wrote:
Small granularity (size < 64K) fragmentation will cause f2fs suspending
all pending discards, result in performance regression, so let's set
4KB discard granularity by default.
So that without fstrim, we also have the ability to avoid any performance
regression caused by non-alignment mapping between fs and flash device.
>>>
>>> This is why we added a sysfs entry. Why do we need to change the default
>>> value every time?
>>
>> Of course, I didn't forget it. But, mostly, our user didn't know very well
>> about
>> our filesystem including each configuration's meaning, mechanism, or usage
>> scenario, most of the time, they will choose to test f2fs with all default
>> option, and then make the conclusion.
>>
>> Currently, with default 64k granularity, if we simulate fragmentation
>> scenario
>> of filesystem, like by a)writing 4k file and b)deleting even indexing file,
>> then
>> all 4k discards won't be issued, result in exhaustion of free space of flash
>> storage, and performance degradation.
>>
>> So I think we'd better to consider and set default value of configuration
>> more
>> elaborately to avoid obvious weakness.
>>
>> Thoughts?
>>
>> Thanks,
>>
>>>
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 58431b9bfd8f..273ffdaf4891 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -248,7 +248,7 @@ struct discard_entry {
};
/* default discard granularity of inner discard thread, unit: block count
*/
-#define DEFAULT_DISCARD_GRANULARITY 16
+#define DEFAULT_DISCARD_GRANULARITY 1
/* max discard pend list number */
#define MAX_PLIST_NUM 512
--
2.18.0.rc1
>>>
>>> .
>>>
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Linux-f2fs-devel mailing list
>> Linux-f2fs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
> .
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v2] f2fs: fix to avoid NULL pointer dereference on se->discard_map
On 2018/9/5 0:00, Vicente Bergas wrote:
> On Tue, Sep 4, 2018 at 5:45 PM, Chao Yu wrote:
>> On 2018/9/4 23:25, Vicente Bergas wrote:
>>> On Mon, Sep 3, 2018 at 9:52 PM, Chao Yu wrote:
From: Chao Yu
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D200951data=02%7C01%7C%7Cc2be7ee866b04268e69f08d6127aa973%7C84df9e7fe9f640afb435%7C1%7C0%7C636716715374991374sdata=E%2Boli5wWbe97f3QCdmAiIIZPEMInd9u221ldtVDqvtA%3Dreserved=0
These is a NULL pointer dereference issue reported in bugzilla:
Hi,
in the setup there is a SATA SSD connected to a SATA-to-USB bridge.
The disc is "Samsung SSD 850 PRO 256G" which supports TRIM.
There are four partitions:
sda1: FAT /boot
sda2: F2FS /
sda3: F2FS /home
sda4: F2FS
The bridge is ASMT1153e which uses the "uas" driver.
There is no TRIM pass-through, so, when mounting it reports:
mounting with "discard" option, but the device does not support discard
The USB host is USB3.0 and UASP capable. It is the one on RK3399.
Given this everything works fine, except there is no TRIM support.
In order to enable TRIM a new UDEV rule is added [1]:
/etc/udev/rules.d/10-sata-bridge-trim.rules:
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa",
SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
After reboot any F2FS write hangs forever and dmesg reports:
Unable to handle kernel NULL pointer dereference
Also tested on a x86_64 system: works fine even with TRIM enabled.
same disc
same bridge
different usb host controller
different cpu architecture
not root filesystem
Regards,
Vicenç.
[1] Post #5 in
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbbs.archlinux.org%2Fviewtopic.php%3Fid%3D236280data=02%7C01%7C%7Cc2be7ee866b04268e69f08d6127aa973%7C84df9e7fe9f640afb435%7C1%7C0%7C636716715374991374sdata=tLP2J%2BL2MPDnqbLm1JcmJ7HfM%2F9j%2F0xc2MET2QSAjVE%3Dreserved=0
Unable to handle kernel NULL pointer dereference at virtual address
003e
Mem abort info:
ESR = 0x9604
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp = 626e3122
[003e] pgd=
Internal error: Oops: 9604 [#1] SMP
Modules linked in: overlay snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio
dw_hdmi_cec snd_soc_simple_card snd_soc_simple_card_utils
snd_soc_rockchip_i2s rockchip_rga snd_soc_rockchip_pcm rockchipdrm
videobuf2_dma_sg v4l2_mem2mem rtc_rk808 videobuf2_memops analogix_dp
videobuf2_v4l2 videobuf2_common dw_hdmi dw_wdt cec rc_core videodev
drm_kms_helper media drm rockchip_thermal rockchip_saradc realtek
drm_panel_orientation_quirks syscopyarea sysfillrect sysimgblt fb_sys_fops
dwmac_rk stmmac_platform stmmac pwm_bl squashfs loop crypto_user gpio_keys
hid_kensington
CPU: 5 PID: 957 Comm: nvim Not tainted 4.19.0-rc1-1-ARCH #1
Hardware name: Sapphire-RK3399 Board (DT)
pstate: 0005 (nzcv daif -PAN -UAO)
pc : update_sit_entry+0x304/0x4b0
lr : update_sit_entry+0x108/0x4b0
sp : 0ca13bd0
x29: 0ca13bd0 x28: 003e
x27: 0020 x26: 0008
x25: 0048 x24: 8000ebb85cf8
x23: 0253 x22:
x21: 000535f2 x20: ffdf
x19: 8000eb9e6800 x18: 8000eb9e6be8
x17: 07ce6926 x16: 1c83ffa8
x15: x14: 8000f602df90
x13: 0006 x12: 0040
x11: 0228 x10:
x9 : x8 :
x7 : 000535f2 x6 : 8000ebff3440
x5 : 8000ebff3440 x4 : 8000ebe3a6c8
x3 : x2 : 0020
x1 : x0 : 8000eb9e5800
Process nvim (pid: 957, stack limit = 0x63a78320)
Call trace:
update_sit_entry+0x304/0x4b0
f2fs_invalidate_blocks+0x98/0x140
truncate_node+0x90/0x400
f2fs_remove_inode_page+0xe8/0x340
f2fs_evict_inode+0x2b0/0x408
evict+0xe0/0x1e0
iput+0x160/0x260
do_unlinkat+0x214/0x298
__arm64_sys_unlinkat+0x3c/0x68
el0_svc_handler+0x94/0x118
el0_svc+0x8/0xc
Code: f9400800 b9488400 36080140 f9400f01 (387c4820)
---[ end trace a0f21a307118c477 ]---
The reason is it is possible to enable discard flag on block queue via
UDEV, but during mount, f2fs will initialize se->discard_map only if
this
[f2fs-dev] Are there limitation to the number of named pipes/FIFO's supported by F2FS?
I have created an f2fs partition on which to build embedded Linux images (using Yocto/OpenEmbedded/Bitbake). I just had a build fail where all 20 parallel makes failed with errors of the form: OSError: [Errno 5] Input/output error: '/home/wpd/src/20180904-test/apps_proc/poky/build/tmp-glibc/work/armv7a-vfp-neon-oe-linux-gnueabi/libxml2/2.9.2-r0/temp/fifo.32426' This build completed successfully in the past, including just this morning (on this filesystem). I believe by design (and benchmarks I have researched) that F2FS is the best approach for SSD based file systems, but this will mark the second time in less than a week of having put F2FS in operation that I will have to back up my partition, reformat it with different flags, and restore it from my backup. I am now frustrated. What options would you recommend for a 1TB SSD formatted with F2FS to be used in an environment that generates Linux system images? This environment creates many object files, named pipes, logfiles, etc... I will start my new backup now, and hope to learn your recommendation before I am ready to issue my next mkfs command. --wpd -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v2] f2fs: fix to avoid NULL pointer dereference on se->discard_map
On Tue, Sep 4, 2018 at 5:45 PM, Chao Yu wrote:
> On 2018/9/4 23:25, Vicente Bergas wrote:
>> On Mon, Sep 3, 2018 at 9:52 PM, Chao Yu wrote:
>>> From: Chao Yu
>>>
>>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D200951data=02%7C01%7C%7Cc2be7ee866b04268e69f08d6127aa973%7C84df9e7fe9f640afb435%7C1%7C0%7C636716715374991374sdata=E%2Boli5wWbe97f3QCdmAiIIZPEMInd9u221ldtVDqvtA%3Dreserved=0
>>>
>>> These is a NULL pointer dereference issue reported in bugzilla:
>>>
>>> Hi,
>>> in the setup there is a SATA SSD connected to a SATA-to-USB bridge.
>>>
>>> The disc is "Samsung SSD 850 PRO 256G" which supports TRIM.
>>> There are four partitions:
>>> sda1: FAT /boot
>>> sda2: F2FS /
>>> sda3: F2FS /home
>>> sda4: F2FS
>>>
>>> The bridge is ASMT1153e which uses the "uas" driver.
>>> There is no TRIM pass-through, so, when mounting it reports:
>>> mounting with "discard" option, but the device does not support discard
>>>
>>> The USB host is USB3.0 and UASP capable. It is the one on RK3399.
>>>
>>> Given this everything works fine, except there is no TRIM support.
>>>
>>> In order to enable TRIM a new UDEV rule is added [1]:
>>> /etc/udev/rules.d/10-sata-bridge-trim.rules:
>>> ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa",
>>> SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
>>> After reboot any F2FS write hangs forever and dmesg reports:
>>> Unable to handle kernel NULL pointer dereference
>>>
>>> Also tested on a x86_64 system: works fine even with TRIM enabled.
>>> same disc
>>> same bridge
>>> different usb host controller
>>> different cpu architecture
>>> not root filesystem
>>>
>>> Regards,
>>> Vicenç.
>>>
>>> [1] Post #5 in
>>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbbs.archlinux.org%2Fviewtopic.php%3Fid%3D236280data=02%7C01%7C%7Cc2be7ee866b04268e69f08d6127aa973%7C84df9e7fe9f640afb435%7C1%7C0%7C636716715374991374sdata=tLP2J%2BL2MPDnqbLm1JcmJ7HfM%2F9j%2F0xc2MET2QSAjVE%3Dreserved=0
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address
>>> 003e
>>> Mem abort info:
>>>ESR = 0x9604
>>>Exception class = DABT (current EL), IL = 32 bits
>>>SET = 0, FnV = 0
>>>EA = 0, S1PTW = 0
>>> Data abort info:
>>>ISV = 0, ISS = 0x0004
>>>CM = 0, WnR = 0
>>> user pgtable: 4k pages, 48-bit VAs, pgdp = 626e3122
>>> [003e] pgd=
>>> Internal error: Oops: 9604 [#1] SMP
>>> Modules linked in: overlay snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio
>>> dw_hdmi_cec snd_soc_simple_card snd_soc_simple_card_utils
>>> snd_soc_rockchip_i2s rockchip_rga snd_soc_rockchip_pcm rockchipdrm
>>> videobuf2_dma_sg v4l2_mem2mem rtc_rk808 videobuf2_memops analogix_dp
>>> videobuf2_v4l2 videobuf2_common dw_hdmi dw_wdt cec rc_core videodev
>>> drm_kms_helper media drm rockchip_thermal rockchip_saradc realtek
>>> drm_panel_orientation_quirks syscopyarea sysfillrect sysimgblt fb_sys_fops
>>> dwmac_rk stmmac_platform stmmac pwm_bl squashfs loop crypto_user gpio_keys
>>> hid_kensington
>>> CPU: 5 PID: 957 Comm: nvim Not tainted 4.19.0-rc1-1-ARCH #1
>>> Hardware name: Sapphire-RK3399 Board (DT)
>>> pstate: 0005 (nzcv daif -PAN -UAO)
>>> pc : update_sit_entry+0x304/0x4b0
>>> lr : update_sit_entry+0x108/0x4b0
>>> sp : 0ca13bd0
>>> x29: 0ca13bd0 x28: 003e
>>> x27: 0020 x26: 0008
>>> x25: 0048 x24: 8000ebb85cf8
>>> x23: 0253 x22:
>>> x21: 000535f2 x20: ffdf
>>> x19: 8000eb9e6800 x18: 8000eb9e6be8
>>> x17: 07ce6926 x16: 1c83ffa8
>>> x15: x14: 8000f602df90
>>> x13: 0006 x12: 0040
>>> x11: 0228 x10:
>>> x9 : x8 :
>>> x7 : 000535f2 x6 : 8000ebff3440
>>> x5 : 8000ebff3440 x4 : 8000ebe3a6c8
>>> x3 : x2 : 0020
>>> x1 : x0 : 8000eb9e5800
>>> Process nvim (pid: 957, stack limit = 0x63a78320)
>>> Call trace:
>>> update_sit_entry+0x304/0x4b0
>>> f2fs_invalidate_blocks+0x98/0x140
>>> truncate_node+0x90/0x400
>>> f2fs_remove_inode_page+0xe8/0x340
>>> f2fs_evict_inode+0x2b0/0x408
>>> evict+0xe0/0x1e0
>>> iput+0x160/0x260
>>> do_unlinkat+0x214/0x298
>>> __arm64_sys_unlinkat+0x3c/0x68
>>> el0_svc_handler+0x94/0x118
>>> el0_svc+0x8/0xc
>>> Code: f9400800 b9488400 36080140 f9400f01 (387c4820)
>>> ---[ end trace a0f21a307118c477 ]---
>>>
>>> The reason is it is possible to enable discard flag on block queue via
>>> UDEV, but during mount, f2fs will initialize se->discard_map only if
>>> this flag is set, once the flag is set after mount, f2fs may dereference
>>> NULL pointer on se->discard_map.
>>>
>>> So this patch does below changes to
Re: [f2fs-dev] [PATCH v2] f2fs: fix to avoid NULL pointer dereference on se->discard_map
On 2018/9/4 23:25, Vicente Bergas wrote:
> On Mon, Sep 3, 2018 at 9:52 PM, Chao Yu wrote:
>> From: Chao Yu
>>
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D200951data=02%7C01%7C%7Cc2be7ee866b04268e69f08d6127aa973%7C84df9e7fe9f640afb435%7C1%7C0%7C636716715374991374sdata=E%2Boli5wWbe97f3QCdmAiIIZPEMInd9u221ldtVDqvtA%3Dreserved=0
>>
>> These is a NULL pointer dereference issue reported in bugzilla:
>>
>> Hi,
>> in the setup there is a SATA SSD connected to a SATA-to-USB bridge.
>>
>> The disc is "Samsung SSD 850 PRO 256G" which supports TRIM.
>> There are four partitions:
>> sda1: FAT /boot
>> sda2: F2FS /
>> sda3: F2FS /home
>> sda4: F2FS
>>
>> The bridge is ASMT1153e which uses the "uas" driver.
>> There is no TRIM pass-through, so, when mounting it reports:
>> mounting with "discard" option, but the device does not support discard
>>
>> The USB host is USB3.0 and UASP capable. It is the one on RK3399.
>>
>> Given this everything works fine, except there is no TRIM support.
>>
>> In order to enable TRIM a new UDEV rule is added [1]:
>> /etc/udev/rules.d/10-sata-bridge-trim.rules:
>> ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa",
>> SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
>> After reboot any F2FS write hangs forever and dmesg reports:
>> Unable to handle kernel NULL pointer dereference
>>
>> Also tested on a x86_64 system: works fine even with TRIM enabled.
>> same disc
>> same bridge
>> different usb host controller
>> different cpu architecture
>> not root filesystem
>>
>> Regards,
>> Vicenç.
>>
>> [1] Post #5 in
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbbs.archlinux.org%2Fviewtopic.php%3Fid%3D236280data=02%7C01%7C%7Cc2be7ee866b04268e69f08d6127aa973%7C84df9e7fe9f640afb435%7C1%7C0%7C636716715374991374sdata=tLP2J%2BL2MPDnqbLm1JcmJ7HfM%2F9j%2F0xc2MET2QSAjVE%3Dreserved=0
>>
>> Unable to handle kernel NULL pointer dereference at virtual address
>> 003e
>> Mem abort info:
>>ESR = 0x9604
>>Exception class = DABT (current EL), IL = 32 bits
>>SET = 0, FnV = 0
>>EA = 0, S1PTW = 0
>> Data abort info:
>>ISV = 0, ISS = 0x0004
>>CM = 0, WnR = 0
>> user pgtable: 4k pages, 48-bit VAs, pgdp = 626e3122
>> [003e] pgd=
>> Internal error: Oops: 9604 [#1] SMP
>> Modules linked in: overlay snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio
>> dw_hdmi_cec snd_soc_simple_card snd_soc_simple_card_utils
>> snd_soc_rockchip_i2s rockchip_rga snd_soc_rockchip_pcm rockchipdrm
>> videobuf2_dma_sg v4l2_mem2mem rtc_rk808 videobuf2_memops analogix_dp
>> videobuf2_v4l2 videobuf2_common dw_hdmi dw_wdt cec rc_core videodev
>> drm_kms_helper media drm rockchip_thermal rockchip_saradc realtek
>> drm_panel_orientation_quirks syscopyarea sysfillrect sysimgblt fb_sys_fops
>> dwmac_rk stmmac_platform stmmac pwm_bl squashfs loop crypto_user gpio_keys
>> hid_kensington
>> CPU: 5 PID: 957 Comm: nvim Not tainted 4.19.0-rc1-1-ARCH #1
>> Hardware name: Sapphire-RK3399 Board (DT)
>> pstate: 0005 (nzcv daif -PAN -UAO)
>> pc : update_sit_entry+0x304/0x4b0
>> lr : update_sit_entry+0x108/0x4b0
>> sp : 0ca13bd0
>> x29: 0ca13bd0 x28: 003e
>> x27: 0020 x26: 0008
>> x25: 0048 x24: 8000ebb85cf8
>> x23: 0253 x22:
>> x21: 000535f2 x20: ffdf
>> x19: 8000eb9e6800 x18: 8000eb9e6be8
>> x17: 07ce6926 x16: 1c83ffa8
>> x15: x14: 8000f602df90
>> x13: 0006 x12: 0040
>> x11: 0228 x10:
>> x9 : x8 :
>> x7 : 000535f2 x6 : 8000ebff3440
>> x5 : 8000ebff3440 x4 : 8000ebe3a6c8
>> x3 : x2 : 0020
>> x1 : x0 : 8000eb9e5800
>> Process nvim (pid: 957, stack limit = 0x63a78320)
>> Call trace:
>> update_sit_entry+0x304/0x4b0
>> f2fs_invalidate_blocks+0x98/0x140
>> truncate_node+0x90/0x400
>> f2fs_remove_inode_page+0xe8/0x340
>> f2fs_evict_inode+0x2b0/0x408
>> evict+0xe0/0x1e0
>> iput+0x160/0x260
>> do_unlinkat+0x214/0x298
>> __arm64_sys_unlinkat+0x3c/0x68
>> el0_svc_handler+0x94/0x118
>> el0_svc+0x8/0xc
>> Code: f9400800 b9488400 36080140 f9400f01 (387c4820)
>> ---[ end trace a0f21a307118c477 ]---
>>
>> The reason is it is possible to enable discard flag on block queue via
>> UDEV, but during mount, f2fs will initialize se->discard_map only if
>> this flag is set, once the flag is set after mount, f2fs may dereference
>> NULL pointer on se->discard_map.
>>
>> So this patch does below changes to fix this issue:
>> - initialize and update se->discard_map all the time.
>> - don't clear DISCARD option if device has no QUEUE_FLAG_DISCARD flag
>> during
Re: [f2fs-dev] [PATCH v2] f2fs: fix to avoid NULL pointer dereference on se->discard_map
On Mon, Sep 3, 2018 at 9:52 PM, Chao Yu wrote:
> From: Chao Yu
>
> https://bugzilla.kernel.org/show_bug.cgi?id=200951
>
> These is a NULL pointer dereference issue reported in bugzilla:
>
> Hi,
> in the setup there is a SATA SSD connected to a SATA-to-USB bridge.
>
> The disc is "Samsung SSD 850 PRO 256G" which supports TRIM.
> There are four partitions:
> sda1: FAT /boot
> sda2: F2FS /
> sda3: F2FS /home
> sda4: F2FS
>
> The bridge is ASMT1153e which uses the "uas" driver.
> There is no TRIM pass-through, so, when mounting it reports:
> mounting with "discard" option, but the device does not support discard
>
> The USB host is USB3.0 and UASP capable. It is the one on RK3399.
>
> Given this everything works fine, except there is no TRIM support.
>
> In order to enable TRIM a new UDEV rule is added [1]:
> /etc/udev/rules.d/10-sata-bridge-trim.rules:
> ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa",
> SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
> After reboot any F2FS write hangs forever and dmesg reports:
> Unable to handle kernel NULL pointer dereference
>
> Also tested on a x86_64 system: works fine even with TRIM enabled.
> same disc
> same bridge
> different usb host controller
> different cpu architecture
> not root filesystem
>
> Regards,
> Vicenç.
>
> [1] Post #5 in https://bbs.archlinux.org/viewtopic.php?id=236280
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 003e
> Mem abort info:
>ESR = 0x9604
>Exception class = DABT (current EL), IL = 32 bits
>SET = 0, FnV = 0
>EA = 0, S1PTW = 0
> Data abort info:
>ISV = 0, ISS = 0x0004
>CM = 0, WnR = 0
> user pgtable: 4k pages, 48-bit VAs, pgdp = 626e3122
> [003e] pgd=
> Internal error: Oops: 9604 [#1] SMP
> Modules linked in: overlay snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio
> dw_hdmi_cec snd_soc_simple_card snd_soc_simple_card_utils
> snd_soc_rockchip_i2s rockchip_rga snd_soc_rockchip_pcm rockchipdrm
> videobuf2_dma_sg v4l2_mem2mem rtc_rk808 videobuf2_memops analogix_dp
> videobuf2_v4l2 videobuf2_common dw_hdmi dw_wdt cec rc_core videodev
> drm_kms_helper media drm rockchip_thermal rockchip_saradc realtek
> drm_panel_orientation_quirks syscopyarea sysfillrect sysimgblt fb_sys_fops
> dwmac_rk stmmac_platform stmmac pwm_bl squashfs loop crypto_user gpio_keys
> hid_kensington
> CPU: 5 PID: 957 Comm: nvim Not tainted 4.19.0-rc1-1-ARCH #1
> Hardware name: Sapphire-RK3399 Board (DT)
> pstate: 0005 (nzcv daif -PAN -UAO)
> pc : update_sit_entry+0x304/0x4b0
> lr : update_sit_entry+0x108/0x4b0
> sp : 0ca13bd0
> x29: 0ca13bd0 x28: 003e
> x27: 0020 x26: 0008
> x25: 0048 x24: 8000ebb85cf8
> x23: 0253 x22:
> x21: 000535f2 x20: ffdf
> x19: 8000eb9e6800 x18: 8000eb9e6be8
> x17: 07ce6926 x16: 1c83ffa8
> x15: x14: 8000f602df90
> x13: 0006 x12: 0040
> x11: 0228 x10:
> x9 : x8 :
> x7 : 000535f2 x6 : 8000ebff3440
> x5 : 8000ebff3440 x4 : 8000ebe3a6c8
> x3 : x2 : 0020
> x1 : x0 : 8000eb9e5800
> Process nvim (pid: 957, stack limit = 0x63a78320)
> Call trace:
> update_sit_entry+0x304/0x4b0
> f2fs_invalidate_blocks+0x98/0x140
> truncate_node+0x90/0x400
> f2fs_remove_inode_page+0xe8/0x340
> f2fs_evict_inode+0x2b0/0x408
> evict+0xe0/0x1e0
> iput+0x160/0x260
> do_unlinkat+0x214/0x298
> __arm64_sys_unlinkat+0x3c/0x68
> el0_svc_handler+0x94/0x118
> el0_svc+0x8/0xc
> Code: f9400800 b9488400 36080140 f9400f01 (387c4820)
> ---[ end trace a0f21a307118c477 ]---
>
> The reason is it is possible to enable discard flag on block queue via
> UDEV, but during mount, f2fs will initialize se->discard_map only if
> this flag is set, once the flag is set after mount, f2fs may dereference
> NULL pointer on se->discard_map.
>
> So this patch does below changes to fix this issue:
> - initialize and update se->discard_map all the time.
> - don't clear DISCARD option if device has no QUEUE_FLAG_DISCARD flag
> during mount.
> - don't issue small discard on zoned block device.
> - introduce some functions to enhance the readability.
>
> Signed-off-by: Chao Yu
> ---
> v2:
> - rebase to last dev branch.
> fs/f2fs/debug.c | 3 +--
> fs/f2fs/f2fs.h| 15 ---
> fs/f2fs/file.c| 2 +-
> fs/f2fs/segment.c | 65 ---
> fs/f2fs/super.c | 16 +++-
> 5 files changed, 46 insertions(+), 55 deletions(-)
>
> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> index 214a968962a1..ebe649d9793c 100644
> --- a/fs/f2fs/debug.c
> +++ b/fs/f2fs/debug.c
> @@ -190,8 +190,7 @@ static void update_mem_info(struct
[f2fs-dev] [PATCH 2/2] f2fs: fix setattr project check upon fssetxattr ioctl
Currently, project quota could be changed by fssetxattr
ioctl, and existed permission check inode_owner_or_capable()
is obviously not enough, just think that common users could
change project id of file, that could make users to
break project quota easily.
This patch try to follow same regular of xfs project
quota:
"Project Quota ID state is only allowed to change from
within the init namespace. Enforce that restriction only
if we are trying to change the quota ID state.
Everything else is allowed in user namespaces."
Besides that, check and set project id'state should
be an atomic operation, protect whole operation with
inode lock.
Signed-off-by: Wang Shilong
---
fs/f2fs/file.c | 41 ++---
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 5474aaa..cb63fe6 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -2736,6 +2736,32 @@ static int f2fs_ioc_fsgetxattr(struct file *filp,
unsigned long arg)
return 0;
}
+static int
+f2fs_ioctl_setattr_check_projid(struct inode *inode,
+ struct fsxattr *fa)
+{
+ /*
+* Project Quota ID state is only allowed to change from within the init
+* namespace. Enforce that restriction only if we are trying to change
+* the quota ID state. Everything else is allowed in user namespaces.
+*/
+ if (current_user_ns() == _user_ns)
+ return 0;
+
+ if (__kprojid_val(F2FS_I(inode)->i_projid) != fa->fsx_projid)
+ return -EINVAL;
+
+ if (F2FS_I(inode)->i_flags & F2FS_PROJINHERIT_FL) {
+ if (!(fa->fsx_xflags & FS_XFLAG_PROJINHERIT))
+ return -EINVAL;
+ } else {
+ if (fa->fsx_xflags & FS_XFLAG_PROJINHERIT)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int f2fs_ioc_fssetxattr(struct file *filp, unsigned long arg)
{
struct inode *inode = file_inode(filp);
@@ -2763,19 +2789,20 @@ static int f2fs_ioc_fssetxattr(struct file *filp,
unsigned long arg)
return err;
inode_lock(inode);
+ err = f2fs_ioctl_setattr_check_projid(inode, );
+ if (err)
+ goto out;
flags = (fi->i_flags & ~F2FS_FL_XFLAG_VISIBLE) |
(flags & F2FS_FL_XFLAG_VISIBLE);
err = __f2fs_ioc_setflags(inode, flags);
- inode_unlock(inode);
- mnt_drop_write_file(filp);
if (err)
- return err;
+ goto out;
err = f2fs_ioc_setproject(filp, fa.fsx_projid);
- if (err)
- return err;
-
- return 0;
+out:
+ inode_unlock(inode);
+ mnt_drop_write_file(filp);
+ return err;
}
int f2fs_pin_file_control(struct inode *inode, bool inc)
--
1.8.3.1
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
[f2fs-dev] [PATCH 1/2] ext4: fix setattr project check upon fssetxattr ioctl
Currently, project quota could be changed by fssetxattr
ioctl, and existed permission check inode_owner_or_capable()
is obviously not enough, just think that common users could
change project id of file, that could make users to
break project quota easily.
This patch try to follow same regular of xfs project
quota:
"Project Quota ID state is only allowed to change from
within the init namespace. Enforce that restriction only
if we are trying to change the quota ID state.
Everything else is allowed in user namespaces."
Besides that, check and set project id'state should
be an atomic operation, protect whole operation with
inode lock.
Signed-off-by: Wang Shilong
---
fs/ext4/ioctl.c | 62 -
1 file changed, 39 insertions(+), 23 deletions(-)
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index a707411..e860df9 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -339,19 +339,14 @@ static int ext4_ioctl_setproject(struct file *filp, __u32
projid)
if (projid_eq(kprojid, EXT4_I(inode)->i_projid))
return 0;
- err = mnt_want_write_file(filp);
- if (err)
- return err;
-
err = -EPERM;
- inode_lock(inode);
/* Is it quota file? Do not allow user to mess with it */
if (ext4_is_quota_file(inode))
- goto out_unlock;
+ return err;
err = ext4_get_inode_loc(inode, );
if (err)
- goto out_unlock;
+ return err;
raw_inode = ext4_raw_inode();
if (!EXT4_FITS_IN_INODE(raw_inode, ei, i_projid)) {
@@ -359,7 +354,7 @@ static int ext4_ioctl_setproject(struct file *filp, __u32
projid)
EXT4_SB(sb)->s_want_extra_isize,
);
if (err)
- goto out_unlock;
+ return err;
} else {
brelse(iloc.bh);
}
@@ -369,10 +364,8 @@ static int ext4_ioctl_setproject(struct file *filp, __u32
projid)
handle = ext4_journal_start(inode, EXT4_HT_QUOTA,
EXT4_QUOTA_INIT_BLOCKS(sb) +
EXT4_QUOTA_DEL_BLOCKS(sb) + 3);
- if (IS_ERR(handle)) {
- err = PTR_ERR(handle);
- goto out_unlock;
- }
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
err = ext4_reserve_inode_write(handle, inode, );
if (err)
@@ -400,9 +393,6 @@ static int ext4_ioctl_setproject(struct file *filp, __u32
projid)
err = rc;
out_stop:
ext4_journal_stop(handle);
-out_unlock:
- inode_unlock(inode);
- mnt_drop_write_file(filp);
return err;
}
#else
@@ -626,6 +616,32 @@ static long ext4_ioctl_group_add(struct file *file,
return err;
}
+static int
+ext4_ioctl_setattr_check_projid(struct inode *inode,
+ struct fsxattr *fa)
+{
+ /*
+* Project Quota ID state is only allowed to change from within the init
+* namespace. Enforce that restriction only if we are trying to change
+* the quota ID state. Everything else is allowed in user namespaces.
+*/
+ if (current_user_ns() == _user_ns)
+ return 0;
+
+ if (__kprojid_val(EXT4_I(inode)->i_projid) != fa->fsx_projid)
+ return -EINVAL;
+
+ if (ext4_test_inode_flag(inode, EXT4_INODE_PROJINHERIT)) {
+ if (!(fa->fsx_xflags & FS_XFLAG_PROJINHERIT))
+ return -EINVAL;
+ } else {
+ if (fa->fsx_xflags & FS_XFLAG_PROJINHERIT)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct inode *inode = file_inode(filp);
@@ -1025,19 +1041,19 @@ long ext4_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
return err;
inode_lock(inode);
+ err = ext4_ioctl_setattr_check_projid(inode, );
+ if (err)
+ goto out;
flags = (ei->i_flags & ~EXT4_FL_XFLAG_VISIBLE) |
(flags & EXT4_FL_XFLAG_VISIBLE);
err = ext4_ioctl_setflags(inode, flags);
- inode_unlock(inode);
- mnt_drop_write_file(filp);
if (err)
- return err;
-
+ goto out;
err = ext4_ioctl_setproject(filp, fa.fsx_projid);
- if (err)
- return err;
-
- return 0;
+out:
+ inode_unlock(inode);
+ mnt_drop_write_file(filp);
+ return err;
}
case EXT4_IOC_SHUTDOWN:
return ext4_shutdown(sb, arg);
--
1.8.3.1
--
Check out the vibrant tech
Re: [f2fs-dev] [PATCH 1/2] f2fs: set 4KB discard granularity by default
Hi,
I was wondering what would be the negatives on reducing the discard granularity
other than making discard more aggressive(hence higher overhead and latency?).
Thanks.
On Tue, Aug 14, 2018 at 4:08 PM Chao Yu wrote:
>
> On 2018/8/14 12:13, Jaegeuk Kim wrote:
> > On 08/10, Chao Yu wrote:
> >> Small granularity (size < 64K) fragmentation will cause f2fs suspending
> >> all pending discards, result in performance regression, so let's set
> >> 4KB discard granularity by default.
> >>
> >> So that without fstrim, we also have the ability to avoid any performance
> >> regression caused by non-alignment mapping between fs and flash device.
> >
> > This is why we added a sysfs entry. Why do we need to change the default
> > value every time?
>
> Of course, I didn't forget it. But, mostly, our user didn't know very well
> about
> our filesystem including each configuration's meaning, mechanism, or usage
> scenario, most of the time, they will choose to test f2fs with all default
> option, and then make the conclusion.
>
> Currently, with default 64k granularity, if we simulate fragmentation scenario
> of filesystem, like by a)writing 4k file and b)deleting even indexing file,
> then
> all 4k discards won't be issued, result in exhaustion of free space of flash
> storage, and performance degradation.
>
> So I think we'd better to consider and set default value of configuration more
> elaborately to avoid obvious weakness.
>
> Thoughts?
>
> Thanks,
>
> >
> >>
> >> Signed-off-by: Chao Yu
> >> ---
> >> fs/f2fs/f2fs.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >> index 58431b9bfd8f..273ffdaf4891 100644
> >> --- a/fs/f2fs/f2fs.h
> >> +++ b/fs/f2fs/f2fs.h
> >> @@ -248,7 +248,7 @@ struct discard_entry {
> >> };
> >>
> >> /* default discard granularity of inner discard thread, unit: block count
> >> */
> >> -#define DEFAULT_DISCARD_GRANULARITY 16
> >> +#define DEFAULT_DISCARD_GRANULARITY 1
> >>
> >> /* max discard pend list number */
> >> #define MAX_PLIST_NUM 512
> >> --
> >> 2.18.0.rc1
> >
> > .
> >
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
[f2fs-dev] [Bug 200951] kernel NULL pointer dereference in update_sit_entry
https://bugzilla.kernel.org/show_bug.cgi?id=200951 --- Comment #17 from Chao Yu (c...@kernel.org) --- Updated in below git link, :) https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git/log/?h=f2fs-dev -- You are receiving this mail because: You are watching the assignee of the bug. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
[f2fs-dev] [PATCH v2] f2fs: fix to avoid NULL pointer dereference on se->discard_map
From: Chao Yu
https://bugzilla.kernel.org/show_bug.cgi?id=200951
These is a NULL pointer dereference issue reported in bugzilla:
Hi,
in the setup there is a SATA SSD connected to a SATA-to-USB bridge.
The disc is "Samsung SSD 850 PRO 256G" which supports TRIM.
There are four partitions:
sda1: FAT /boot
sda2: F2FS /
sda3: F2FS /home
sda4: F2FS
The bridge is ASMT1153e which uses the "uas" driver.
There is no TRIM pass-through, so, when mounting it reports:
mounting with "discard" option, but the device does not support discard
The USB host is USB3.0 and UASP capable. It is the one on RK3399.
Given this everything works fine, except there is no TRIM support.
In order to enable TRIM a new UDEV rule is added [1]:
/etc/udev/rules.d/10-sata-bridge-trim.rules:
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa",
SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
After reboot any F2FS write hangs forever and dmesg reports:
Unable to handle kernel NULL pointer dereference
Also tested on a x86_64 system: works fine even with TRIM enabled.
same disc
same bridge
different usb host controller
different cpu architecture
not root filesystem
Regards,
Vicenç.
[1] Post #5 in https://bbs.archlinux.org/viewtopic.php?id=236280
Unable to handle kernel NULL pointer dereference at virtual address
003e
Mem abort info:
ESR = 0x9604
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp = 626e3122
[003e] pgd=
Internal error: Oops: 9604 [#1] SMP
Modules linked in: overlay snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio
dw_hdmi_cec snd_soc_simple_card snd_soc_simple_card_utils snd_soc_rockchip_i2s
rockchip_rga snd_soc_rockchip_pcm rockchipdrm videobuf2_dma_sg v4l2_mem2mem
rtc_rk808 videobuf2_memops analogix_dp videobuf2_v4l2 videobuf2_common dw_hdmi
dw_wdt cec rc_core videodev drm_kms_helper media drm rockchip_thermal
rockchip_saradc realtek drm_panel_orientation_quirks syscopyarea sysfillrect
sysimgblt fb_sys_fops dwmac_rk stmmac_platform stmmac pwm_bl squashfs loop
crypto_user gpio_keys hid_kensington
CPU: 5 PID: 957 Comm: nvim Not tainted 4.19.0-rc1-1-ARCH #1
Hardware name: Sapphire-RK3399 Board (DT)
pstate: 0005 (nzcv daif -PAN -UAO)
pc : update_sit_entry+0x304/0x4b0
lr : update_sit_entry+0x108/0x4b0
sp : 0ca13bd0
x29: 0ca13bd0 x28: 003e
x27: 0020 x26: 0008
x25: 0048 x24: 8000ebb85cf8
x23: 0253 x22:
x21: 000535f2 x20: ffdf
x19: 8000eb9e6800 x18: 8000eb9e6be8
x17: 07ce6926 x16: 1c83ffa8
x15: x14: 8000f602df90
x13: 0006 x12: 0040
x11: 0228 x10:
x9 : x8 :
x7 : 000535f2 x6 : 8000ebff3440
x5 : 8000ebff3440 x4 : 8000ebe3a6c8
x3 : x2 : 0020
x1 : x0 : 8000eb9e5800
Process nvim (pid: 957, stack limit = 0x63a78320)
Call trace:
update_sit_entry+0x304/0x4b0
f2fs_invalidate_blocks+0x98/0x140
truncate_node+0x90/0x400
f2fs_remove_inode_page+0xe8/0x340
f2fs_evict_inode+0x2b0/0x408
evict+0xe0/0x1e0
iput+0x160/0x260
do_unlinkat+0x214/0x298
__arm64_sys_unlinkat+0x3c/0x68
el0_svc_handler+0x94/0x118
el0_svc+0x8/0xc
Code: f9400800 b9488400 36080140 f9400f01 (387c4820)
---[ end trace a0f21a307118c477 ]---
The reason is it is possible to enable discard flag on block queue via
UDEV, but during mount, f2fs will initialize se->discard_map only if
this flag is set, once the flag is set after mount, f2fs may dereference
NULL pointer on se->discard_map.
So this patch does below changes to fix this issue:
- initialize and update se->discard_map all the time.
- don't clear DISCARD option if device has no QUEUE_FLAG_DISCARD flag
during mount.
- don't issue small discard on zoned block device.
- introduce some functions to enhance the readability.
Signed-off-by: Chao Yu
---
v2:
- rebase to last dev branch.
fs/f2fs/debug.c | 3 +--
fs/f2fs/f2fs.h| 15 ---
fs/f2fs/file.c| 2 +-
fs/f2fs/segment.c | 65 ---
fs/f2fs/super.c | 16 +++-
5 files changed, 46 insertions(+), 55 deletions(-)
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 214a968962a1..ebe649d9793c 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -190,8 +190,7 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
si->base_mem += MAIN_SEGS(sbi) * sizeof(struct seg_entry);
si->base_mem += f2fs_bitmap_size(MAIN_SEGS(sbi));
si->base_mem += 2 * SIT_VBLOCK_MAP_SIZE * MAIN_SEGS(sbi);
- if (f2fs_discard_en(sbi))
- si->base_mem +=
[f2fs-dev] [Bug 200951] kernel NULL pointer dereference in update_sit_entry
https://bugzilla.kernel.org/show_bug.cgi?id=200951 --- Comment #16 from vice...@gmail.com --- 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ç. -- You are receiving this mail because: You are watching the assignee of the bug. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
[f2fs-dev] [Bug 200951] kernel NULL pointer dereference in update_sit_entry
https://bugzilla.kernel.org/show_bug.cgi?id=200951 --- Comment #15 from Chao Yu (c...@kernel.org) --- 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/ -- You are receiving this mail because: You are watching the assignee of the bug. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
