Not all direct loads from nvmm are avoided

[luzh]

To trap media errors NOVA would like to read nvmm (meta)data in to dram using machine-check-safe functions such as memcpy_mcsafe(), or its wrapper memcpy_from_pmem(), and then consume the copied and verified data in dram. Reading file data should be totally covered by memcpy_from_pmem(), and most reads of metadata are also covered but not all, because that will cause changes to many function interfaces.

Functions like nova_verify_entry_csum() and nova_check_inode_integrity will obtain a relevant metadata copy in dram and verify its integrity. Therefore it's possible to use the copy for subsequent functions that read the metadata. Now NOVA's implementation simply passes two pointers (one to nvmm, one to dram) around functions. Refer to how "entry" and "entryc" (entry_copy) are used.

However it's awkward and error-prone to always pass two pointers to every function, and perhaps a better solution is to add a nvmm pointer field to the NOVA metadata structures, for example:

struct nova_abc_entry {
        __le64 type;
        __le64 a;
        __le64 b;
        __le32 c;
        __le32 csum;
        __le64 addr; /* offset address in nvmm */
} __attribute((__packed__));

Once the structure is copied to dram and verified in a caller function, it can pass a pointer to the dram structure (just use one pointer as NOVA has been doing) to its callees, and if any callee wants to use the nvmm address, it can use the 'addr' field.

Known places that still directly read from nvmm are:

1. Read entry values in nova_execute_invalidate_reassign_logentry(), of log.c.
2. Use of entry values in nova_calc_entry_csum().
3. Use of inode values in nova_check_inode_checksum().
4. Read entry values in journal.c and snapshot.c.
5. Read pi-> values in bbuild.c, gc.c and inode.c