RE: [PATCH v2] exfat: handle unreconized benign secondary entries

["Sungjong Seo" <sj1557.seo@samsung.com>]

> > >
> > >> +		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://dokumen.pub/sd-
> 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.