Arch Linux

"The nvidia driver fails to link due to functions no longer being exported in linux 4.16."
is not accurate the build succeeds but is referencing a function that is not exported so fails at run time as documented in the linked thread.

https://git.archlinux.org/svntogit/packages.git/tree/trunk/0003-Partially-revert-swiotlb-remove-various-exports.patch?h=packages/linux&id=9a40229d82e018c3cee9da97dc89d703828c866a
Has that patch been forwarded to upstream? The issue of hardened user copy will just be left as a warning?

No and yes, assuming the spam isn't too bad. Otherwise I'll consider disabling usercopy hardening.

I was surprised you changed the kernel instead of changing the driver for the first issue. Exporting a function for the benefit of a none GPL'd module seems dubious to be me even if it is a revert.
There were also alternative solutions that avoid touching the kernel for changes that only required by the nvidia module.
Not working with upstream seems to go against arch principals. The second issue the output is from WARN_ONCE so should only be produced once but if you consider it spam you could mark the buffer
as whilelisted for userspace or drop the feature.

The nvidia 396.18 resolves the first issue with the following comment
/*
* The "else" case that is not shown
* (for NV_IS_EXPORT_SYMBOL_PRESENT_swiotlb_map_sg_attrs == 0) does
* nothing, and ends up dropping us out to the last line of this function,
* effectively returning false. The nearly-human-readable version of that
* case is "struct dma_map_ops is present (NV_DMA_MAP_OPS_PRESENT is
* defined) but swiotlb_map_sg_attrs is not present".
*
* That can happen on kernels that are later than:
*
* 2017-12-24 4bd89ed39b2ab8dc4ac4b6c59b07d420b0213bec
* ("swiotlb: remove various exports")
*
* Related to this: as of the above commit, this driver has no way of
* detecting whether or not the SWIOTLB is in use. Furthermore, the
* driver cannot support DMA remapping. That leads to the following
* point: "swiotlb=force" is not supported.
*/
Unfortunately the use of phys_to_dma is still broken so the driver will use phys_to_machine if the kernel supports xen.
Which means you could drop the second section of my patch leaving the first and third to fix up the phys_to_dma support.
The second issue also appears resolved.

I'll drop the patch from the kernel after we upgrade to 396, then.

Hopefully phys_to_dma will be fixed as well in the release version of driver as the arch linux package defines CONFIG_XEN_PV
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/xen/page.h?h=v4.16#n104
contacted upstream to clarify

Check out the nvidia packages in [testing] and report.

My summary of 396.18 also applies to 396.24
Edit:
nvidia-dkms 396.24-1 works without issue with a custom 4.16 kernel no usercopy_warn
nvidia 396.24-1 with linux 4.16.17-1 also works without issue and no usercopy_warn