|author||Juli Mallett <jmallett@FreeBSD.org>||2012-03-29 03:13:43 +0000|
|committer||Juli Mallett <jmallett@FreeBSD.org>||2012-03-29 03:13:43 +0000|
Fix 32-bit libgeom consumers run on 64-bit kernels with COMPAT_FREEBSD32.
Kernel pointer values are used as opaque unique identifiers, which are then used to reconstruct references between various providers, classes, etc., inside libgeom from the source XML. Unfortunately, they're converted to pointer-width integers (in the form of pointers) to do this, and 32-bit userland pointers cannot hold sensible representations (however opaque) of 64-bit kernel pointers on all systems. In the case where the leading bits are zero and 32 distinct bits of pointer can be identified, this will happen to work. On systems where the upper 32-bits of kernel pointers are non-zero and the same for all kernel pointers, this will result in double frees and all kinds of bizarre crashes and linkage between objects inside libgeom. To mitigate this problem, treat the opaque identifiers in the XML as C strings instead, and internalize them to give unique and consistent per-object pointer values in userland for each identifier in the XML. This allows us to keep the libgeom logic the same with only minor changes to initial setup and parsing. It might be more sensible for speed reasons to treat the identifiers as numbers of a large size (uintmax_t, say) rather than strings, but strings seem fine for now. (As an added side-effect, this makes it slightly easier to identify unresolved references, but nothing has been added to inform the user of those.)
Notes: svn path=/head/; revision=233646
Diffstat (limited to 'sbin/mount_unionfs/mount_unionfs.8')
0 files changed, 0 insertions, 0 deletions