While clearing some compiler in e2fsprogs, I noticed that we are a bit inconsistent about the mmp_nodename and mmp_bdevname fields, and whether they are guaranteed to be null terminated or not. The kernel is using them in some printf contexts where it's assumed they are null terminated; but in other places, we have been filling them such that if the string is exactly 64 or 32 bytes, they will *not* necessarily be null terminated. This is potentially a problem both in the kernel as well as in e2fsprogs. I propose that we solve this problem by assuming that they *are* null terminated. But that means that if there are node names which are exactly 64 bytes long, or block device names which are exactly 32 bytes long, badness could happen. On the other hand, we kind of have this problem already, since in the kernel, we are using memcmp when comparing mmp_nodename, but in e2fsprogs userspace, we are using gethostbyname and there is no guarantee that bytes beyond the terminating NULL have been cleared. As a result I'm not sure the interlock between e2fsprogs and the kernel works in all cases anyway. Or we could go the other way, and try to fix all of the locations which are accessing and writing mmp_nodename and mmp_bdevname so that they are considered non-strings which are NULL padded. Andreas, do you have any preferences here? - Ted
