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: <CAPqOJe1HUgoyQ_wBy00KYnkya2n0hORs5SjU-tHL5KOiqA72gg@mail.gmail.com>
Date: Mon, 12 Aug 2024 09:40:41 +0800
From: dongliang cui <cuidongliang390@...il.com>
To: Namjae Jeon <linkinjeon@...nel.org>
Cc: Dongliang Cui <dongliang.cui@...soc.com>, 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, 
	Zhiguo Niu <zhiguo.niu@...soc.com>
Subject: Re: [PATCH v4] exfat: check disk status during buffer write

On Fri, Aug 9, 2024 at 8:57 PM Namjae Jeon <linkinjeon@...nel.org> wrote:
>
> 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:)
Thank you for your help in updating.