[mirror_ubuntu-jammy-kernel.git] / drivers / staging / exfat / TODO

A laundry list of things that need looking at, most of which will
require more work than the average checkpatch cleanup...

Note that some of these entries may not be bugs - they're things
that need to be looked at, and *possibly* fixed.

Clean up the ffsCamelCase function names.

Fix (thing)->flags to not use magic numbers - multiple offenders

Sort out all the s32/u32/u8 nonsense - most of these should be plain int.

exfat_core.c - ffsReadFile - the goto err_out seem to leak a brelse().
same for ffsWriteFile.

All the calls to fs_sync() need to be looked at, particularly in the
context of EXFAT_DELAYED_SYNC. Currently, if that's defined, we only
flush to disk when sync() gets called.  We should be doing at least
metadata flushes at appropriate times.

ffsTruncateFile -  if (old_size <= new_size) {
That doesn't look right. How did it ever work? Are they relying on lazy
block allocation when actual writes happen? If nothing else, it never
does the 'fid->size = new_size' and do the inode update....

ffsSetAttr() is just dangling in the breeze, not wired up at all...

Convert global mutexes to a per-superblock mutex.

Right now, we load exactly one UTF-8 table. Check to see
if that plays nice with different codepage and iocharset values
for simultanous mounts of different devices

exfat_rmdir() checks for -EBUSY but ffsRemoveDir() doesn't return it.
In fact, there's a complete lack of -EBUSY testing anywhere.

There's probably a few missing checks for -EEXIST

check return codes of sync_dirty_buffer()

Why is remove_file doing a num_entries++??

Double check a lot of can't-happen parameter checks (for null pointers for
things that have only one call site and can't pass a null, etc).

All the DEBUG stuff can probably be tossed, including the ioctl(). Either
that, or convert to a proper fault-injection system.

exfat_remount does exactly one thing.  Fix to actually deal with remount
options, particularly handling R/O correctly.  For that matter, allow
R/O mounts in the first place.

Figure out why the VFAT code used multi_sector_(read|write) but the
exfat code doesn't use it. The difference matters on SSDs with wear leveling.

exfat_fat_sync(), exfat_buf_sync(), and sync_alloc_bitmap()
aren't called anyplace....

Create helper function for exfat_set_entry_time() and exfat_set_entry_type()
because it's sort of ugly to be calling the same functionn directly and
other code calling through the fs_func struc ponters...

clean up the remaining vol_type checks, which are of two types:
some are ?: operators with magic numbers, and the rest are places
where we're doing stuff with '.' and '..'.

Patches to:
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	Valdis Kletnieks <valdis.kletnieks@vt.edu>
Commit	Line	Data
6366e523 VK	1	A laundry list of things that need looking at, most of which will
	2	require more work than the average checkpatch cleanup...
	3
	4	Note that some of these entries may not be bugs - they're things
	5	that need to be looked at, and possibly fixed.
	6
	7	Clean up the ffsCamelCase function names.
	8
	9	Fix (thing)->flags to not use magic numbers - multiple offenders
	10
	11	Sort out all the s32/u32/u8 nonsense - most of these should be plain int.
	12
c48c9f7f VK	13	exfat_core.c - ffsReadFile - the goto err_out seem to leak a brelse().
	14	same for ffsWriteFile.
	15
6366e523 VK	16	All the calls to fs_sync() need to be looked at, particularly in the
	17	context of EXFAT_DELAYED_SYNC. Currently, if that's defined, we only
	18	flush to disk when sync() gets called. We should be doing at least
	19	metadata flushes at appropriate times.
c48c9f7f VK	20
	21	ffsTruncateFile - if (old_size <= new_size) {
	22	That doesn't look right. How did it ever work? Are they relying on lazy
	23	block allocation when actual writes happen? If nothing else, it never
	24	does the 'fid->size = new_size' and do the inode update....
	25
	26	ffsSetAttr() is just dangling in the breeze, not wired up at all...
6366e523 VK	27
	28	Convert global mutexes to a per-superblock mutex.
	29
	30	Right now, we load exactly one UTF-8 table. Check to see
	31	if that plays nice with different codepage and iocharset values
	32	for simultanous mounts of different devices
	33
	34	exfat_rmdir() checks for -EBUSY but ffsRemoveDir() doesn't return it.
	35	In fact, there's a complete lack of -EBUSY testing anywhere.
	36
	37	There's probably a few missing checks for -EEXIST
	38
	39	check return codes of sync_dirty_buffer()
	40
	41	Why is remove_file doing a num_entries++??
	42
	43	Double check a lot of can't-happen parameter checks (for null pointers for
	44	things that have only one call site and can't pass a null, etc).
	45
	46	All the DEBUG stuff can probably be tossed, including the ioctl(). Either
	47	that, or convert to a proper fault-injection system.
	48
	49	exfat_remount does exactly one thing. Fix to actually deal with remount
	50	options, particularly handling R/O correctly. For that matter, allow
	51	R/O mounts in the first place.
	52
	53	Figure out why the VFAT code used multi_sector_(read\|write) but the
	54	exfat code doesn't use it. The difference matters on SSDs with wear leveling.
	55
	56	exfat_fat_sync(), exfat_buf_sync(), and sync_alloc_bitmap()
	57	aren't called anyplace....
	58
	59	Create helper function for exfat_set_entry_time() and exfat_set_entry_type()
	60	because it's sort of ugly to be calling the same functionn directly and
	61	other code calling through the fs_func struc ponters...
	62
	63	clean up the remaining vol_type checks, which are of two types:
	64	some are ?: operators with magic numbers, and the rest are places
	65	where we're doing stuff with '.' and '..'.
	66
	67	Patches to:
	68	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	69	Valdis Kletnieks <valdis.kletnieks@vt.edu>