linux-kernel - Re: [PATCH v4] exfat: check disk status during buffer write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKYAXd8U1P_+WYfkPnO4JeTA=_V1ScrfkApJxi7F-iyOw9n-cw@mail.gmail.com>
Date: Fri, 9 Aug 2024 21:57:39 +0900
From: Namjae Jeon <linkinjeon@...nel.org>
To: Dongliang Cui <dongliang.cui@...soc.com>
Cc: sj1557.seo@...sung.com, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, niuzhiguo84@...il.com, hao_hao.wang@...soc.com, 
	ke.wang@...soc.com, cuidongliang390@...il.com, 
	Zhiguo Niu <zhiguo.niu@...soc.com>
Subject: Re: [PATCH v4] exfat: check disk status during buffer write

2024년 8월 8일 (목) 오후 3:40, Dongliang Cui <dongliang.cui@...soc.com>님이 작성:
>
> We found that when writing a large file through buffer write, if the
> disk is inaccessible, exFAT does not return an error normally, which
> leads to the writing process not stopping properly.
>
> To easily reproduce this issue, you can follow the steps below:
>
> 1. format a device to exFAT and then mount (with a full disk erase)
> 2. dd if=/dev/zero of=/exfat_mount/test.img bs=1M count=8192
> 3. eject the device
>
> You may find that the dd process does not stop immediately and may
> continue for a long time.
>
> The root cause of this issue is that during buffer write process,
> exFAT does not need to access the disk to look up directory entries
> or the FAT table (whereas FAT would do) every time data is written.
> Instead, exFAT simply marks the buffer as dirty and returns,
> delegating the writeback operation to the writeback process.
>
> If the disk cannot be accessed at this time, the error will only be
> returned to the writeback process, and the original process will not
> receive the error, so it cannot be returned to the user side.
>
> When the disk cannot be accessed normally, an error should be returned
> to stop the writing process.
>
> xfstests results:
>
> Apart from generic/622, all other shutdown-related cases can pass.
>
> generic/622 fails the test after the shutdown ioctl implementation, but
> when it's not implemented, this case will be skipped.
>
> This case designed to test the lazytime mount option, based on the test
> results, it appears that the atime and ctime of files cannot be
> synchronized to the disk through interfaces such as sync or fsync.
> It seems that it has little to do with the implementation of shutdown
> itself.
>
> If you need detailed information about generic/622, I can upload it.
>
> Signed-off-by: Dongliang Cui <dongliang.cui@...soc.com>
> Signed-off-by: Zhiguo Niu <zhiguo.niu@...soc.com>
You still haven't updated the patch subject and description with
shutdown support.
I've directly updated it and applied it to #dev.
Thanks for your patch:)