linux-kernel - Re: [PATCH v3] exfat: remove EXFAT_SB

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 for Android: free password hash cracker in your pocket

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

Message-ID: <c635e965-6b78-436a-3959-e4777e1732c1@gmail.com>
Date:   Fri, 10 Jul 2020 16:36:28 +0900
From:   Tetsuhiro Kohada <kohada.t2@...il.com>
To:     Sungjong Seo <sj1557.seo@...sung.com>
Cc:     kohada.tetsuhiro@...mitsubishielectric.co.jp,
        mori.takahiro@...mitsubishielectric.co.jp,
        motai.hirotaka@...mitsubishielectric.co.jp,
        'Namjae Jeon' <namjae.jeon@...sung.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] exfat: remove EXFAT_SB_DIRTY flag

On 2020/06/18 22:11, Sungjong Seo wrote:
>> BTW
>> Even with this patch applied,  VOL_DIRTY remains until synced in the above
>> case.
>> It's not  easy to reproduce as rmdir, but I'll try to fix it in the future.
> 
> I think it's not a problem not to clear VOL_DIRTY under real errors,
> because VOL_DIRTY is just like a hint to note that write was not finished clearly.
> 
> If you mean there are more situation like ENOTEMPTY you mentioned,
> please make new patch to fix them.

When should VOL_DIRTY be cleared?

The current behavior is ...

Case of  mkdir, rmdir, rename:
   - set VOL_DIRTY before operation
   - set VOL_CLEAN after operating.
In async mode, it is actually written to the media after 30 seconds.

Case of  cp, touch:
   - set VOL_DIRTY before operation
   - however, VOL_CLEAN is not called in this context.
VOL_CLEAN will call by sync_fs or unmount.

I added VOL_CLEAN in last of __exfat_write_inode() and exfat_map_cluster().
As a result, VOL_DIRTY is cleared with cp and touch.
However, when copying a many files ...
  - Async mode: VOL_DIRTY is written to the media twice every 30 seconds.
  - Sync mode: Of course,  VOL_DIRTY and VOL_CLEAN to the media for each file.

Frequent writing VOL_DIRTY and VOL_CLEAN  increases the risk of boot-sector curruption.
If the boot-sector corrupted, it causes the following serious problems  on some OSs.
  - misjudge as unformatted
  - can't judge as exfat
  - can't repair

I want to minimize boot sector writes, to reduce these risk.

I looked vfat/udf implementation, which manages similar dirty information on linux,
and found that they ware mark-dirty at mount and cleared at unmount.

Here are some ways to clear VOL_DIRTY.

(A) VOL_CLEAN after every write operation.
   :-) Ejectable at any time after a write operation.
   :-( Many times write to Boot-sector.

(B) dirty at mount, clear at unmount (same as vfat/udf)
   :-) Write to boot-sector twice.
   :-( It remains dirty unless unmounted.
   :-( Write to boot-sector even if there is no write operation.　

(C) dirty on first write operation, clear on unmount
   :-) Writing to boot-sector is minimal.
   :-) Will not write to the boot-sector if there is no write operation.
   :-( It remains dirty unless unmounted.

(D) dirty on first write operation,  clear on sync-fs/unmount
  :-) Writing to boot-sector can be reduced.
  :-) Will not write to the boot-sector if there is no write operation.
  :-) sync-fs makes it clean and ejectable immidiately.
  :-( It remains dirty unless sync-fs or unmount.
  :-( Frequent sync-fs will  increases writes to boot-sector.

I think it should be (C) or(D).
What do you think?

BR
---
Tetsuhiro Kohada <kohada.t2@...il.com>