Thomas Schwinge: > Hi! > > On Tue, 30 Apr 2013 00:47:47 +0000, Jacob Appelbaum <ja...@appelbaum.net> > wrote: >> I've noticed that mmap() doesn't behave as expected > > There are known issues with mmap, in particular it (currently) doesn't > work at all on filesystem based on libnetfs (such as NFS, ftpfs, etc.), > <http://www.gnu.org/software/hurd/open_issues/git_nfs_mmap.html>, > <http://www.gnu.org/software/hurd/open_issues/libnetfs_io_map.html>. > More details: <http://www.gnu.org/software/hurd/glibc/mmap.html>. A few > individual issues filed: > <http://www.gnu.org/software/hurd/open_issues/mmap_crash_etc.html>, > <http://www.gnu.org/software/hurd/open_issues/mmap_write-only.html>. > And, there's no mremap, > <http://www.gnu.org/software/hurd/open_issues/glibc/mremap.html>. > > If you tell us what you're seeing with mmap and what you'd expect to see, > we should quickly be able to tell "who's at fault".
Hi there, I'm sure that this is a known issue of sorts or if it isn't it is probably closely related to one of the above bugs. Sure - I made a dist tar.gz from git ( https://github.com/ioerror/tlsdate ) tip: https://people.torproject.org/~ioerror/src/tlsdate-git-tip-dist.tar.gz It appears that the issue is that when I try to memcpy into my mmap() created in the parent, the child is unable to write into it properly - that is - the mmap() is constructed like so: https://github.com/ioerror/tlsdate/blob/master/src/tlsdate-helper.c#L1115 tlsdate-helper then forks a child process and then attempts to memcpy into the mmap(): https://github.com/ioerror/tlsdate/blob/master/src/tlsdate-helper.c#L1056 Now - if I inspect the contents of the mmap inside the child process - sizeof() reports it to be four bytes (expected and the same size as the 32bit uint). However if I print it inside the child, it prints as a very small integer - it most certainly is not identical to the contents of ssl->s3->server_random. It gets even weirder from there... When the child process ends and the parent goes to use it - it is zero. I've added a clause to ensure that this value is never allowed and so now on GNU/Hurd it simply fails to get further than this check: https://github.com/ioerror/tlsdate/blob/master/src/tlsdate-helper.c#L1194 So far this is good as it caught a bug on all platforms - this value should never be zero and it shouldn't even attempt to set a clock if the value is somehow zero. So I've now caught that case - though really it should ensure the value is sane in a few ways - zero is OK for now but will likely be extended in the future. So... whose bug is this anyway? I was planning to just replace mmap() here with a pipe but now I wonder if this should be fixed in GNU/Hurd or if a pipe would do the trick in any case? All the best, Jacob
