2023-01-13 17:35 GMT+09:00, Yuezhang.Mo@xxxxxxxx <Yuezhang.Mo@xxxxxxxx>: >> > > > >> > > >> + if (exfat_get_entry_type(ep) & TYPE_BENIGN_SEC) >> > > >> + exfat_free_benign_secondary_clusters(inode, ep); >> > > >> + >> > > > >> > > > Only vendor allocation entry(0xE1) have associated cluster >> > > > allocations, vendor extension entry(0xE0) do not have associated >> > > > cluster >> > > allocations. >> > > This is to free associated cluster allocation of the unrecognized >> > > benign secondary entries, not only vendor alloc entry. Could you >> > > elaborate more if there is any issue ? >> > >> > From exFAT spec, there are 2 types benign secondary entries only, >> > Vendor Extension entry and Vendor Allocation entry. >> > >> > For different Vendor, Different Vendors are distinguished by different >> > VendorGuid. >> > >> > For a better understanding, please refer to >> > https://urldefense.com/v3/__https://dokumen.pub/sd-__;!!JmoZiZGBv3RvKR >> > >> Sx!-iaK3DSO2yh1pGjdOLoZjMhH7s6QEAbN-Yd05bnBzTzpPks10JNCptYbvAdHZ >> XYYvox >> > 5D4Pi2xC3TBqH1pHEIg$ >> > specifications-part-2-file-system-specification-version-300.html. This >> > is the specification that the SD Card Association defines Vendor >> > Extension entries and Vendor Allocation entries for SD card. "Figure 5-3 >> > : >> > Continuous Information Management" is an example of an entry set >> > containing a Vendor Extension entry and a Vendor Allocation entry. In >> > the example, we can see vendor extension entry(0xE0) do not have >> > associated cluster allocations. >> >> From "8.2 in the exFAT spec" as below, it is needed to handle all >> unrecognized >> benign secondary entries that include NOT specified in Revision 1.00. >> >> 8.2 Implications of Unrecognized Directory Entries Future exFAT >> specifications >> of the same major revision number, 1, and minor revision number higher >> than >> 0, may define new benign primary, critical secondary, and benign >> secondary >> directory entries. Only exFAT specifications of a higher major revision >> number >> may define new critical primary directory entries. Implementations of >> this >> specification, exFAT Revision 1.00 File System Basic Specification, should >> be >> able to mount and access any exFAT volume of major revision number 1 and >> any minor revision number. This presents scenarios in which an >> implementation may encounter directory entries which it does not >> recognize. >> The following describe implications of these scenarios: >> ... >> 4. Implementations shall not modify unrecognized benign secondary >> directory entries or their associated cluster allocations. >> Implementations should ignore unrecognized benign secondary directory >> entries. When deleting a directory entry set, implementations shall >> free all cluster allocations, if any, associated with unrecognized >> benign secondary directory entries. >> > > My understanding are > > 1. If new benign directory entries are defined in the future, the minor > version number will be incremented. > - If FileSystemRevision is 1.0, Benign secondary is only Vendor Extension > DirectoryEntry or Vendor Allocation DirectoryEntry. > - If FileSystemRevision is higher than 1.0, another Benign secondary > entries are defined. > - So it seems we need to add a check for FileSystemRevision in > exfat_read_boot_sector() > - If FileSystemRevision is higher than 1.0, mount with read only, > because we can not handle the version. Well, I can't agree it. The current problem is that exfat has no handling for unrecognized benign secondary entries. Currently, exfat does not support vendor alloc/ext entries, so exfat handle unrecognized benign secondary entry as described in the spec. Of course, even if a new entry is added to the updated specification later, there is no problem because it is handled as an unrecognized benign secondary entry. > > 2. Not all Benign secondary have FirstCluster and DataLength Fields. > - Vendor Extension DirectoryEntry has no FirstCluster and DataLength > Fields, and there are no clusters to free when deleting it. We can know if it is defined by checking the AllocationPossible field of GeneralSecondaryFlags. If that bit is set, the FirstCluster and DataLength fields are defined. This patch has code that checks it. > > Table 36 Vendor Extension DirectoryEntry > Field Name Offset(byte) Size(byte) > EntryType 0 1 > GeneralSecondaryFlags 1 1 > VendorGuid 2 16 > VendorDefined 18 14 > > - Vendor Allocation DirectoryEntry has FirstCluster and DataLength Fields, > the associated cluster should be freed when deleting it. > > Field Name Offset(byte) Size(byte) > EntryType 0 1 > GeneralSecondaryFlags 1 1 > VendorGuid 2 16 > VendorDefined 18 2 > FirstCluster 20 4 > DataLength 24 8 > > BTW, I start my Spring Festival vacation tomorrow, so I may not be able to > respond to emails in time. >
