Reputation: 894
I want your opinion about a syscall: mount().
Today, a problem brought back this doubt. I see a lots of code that calls/uses mount() syscall. But, recently, running Valgrind, it showed an error saying that you cannot specify NULL as the 'type' argument of mount function.
An example from kernel code:
ret = mount("/dev/pts/ptmx", "/dev/ptmx", NULL, MS_BIND, NULL);
Valgrind was complaining about the first NULL parameter which refers to the mount type:
==18012== Syscall param mount(type) points to unaddressable byte(s)
After replacing NULL to type "none" the error disappeared. I read a documentation about it, saying that is better to use "none" for BIND and MOVE options. But, I'm not right about that.
The x86_64 bits does not use the type for BIND and MOVE. If I read the code of the right arch.
Do you have any documentation or a best practice to use this syscall?
Upvotes: 2
Views: 740
Reputation: 180351
When passing MS_BIND
to mount()
among the flags, passing NULL
as the third argument is not wrong, and passing "none"
is neither better nor worse. Both rely on the fact that that argument is ignored for bind mounts (and this is documented in the manual).
Valgrind is right that NULL
is a pointer that does not point to data, and that when presented as an argument, "none"
decays to a pointer that does point to data. It is not discerning enough to recognize that that does not matter here. If silencing Valgrind about the issue is your primary concern, then passing "none"
is a fine way of doing so.
Myself, I'd probably just use NULL
, as that better conveys to others (including future me) that I'm passing something that I do not expect to be used. For the same reason, if I were to use a string here to mollify a petulant Valgrind, then I'd probably choose one more like "not used because MS_BIND"
.
On the other hand, when the mount data are stored in a file (i.e. /etc/fstab
) you have to put something in the field, and there, "none"
does a great job of conveying the information that is important at that level, to the human consumers of that data.
Upvotes: 1