|Summary:||locarchive does not provide fallback for mmap()|
|Product:||glibc||Reporter:||Bernardo Innocenti <bernie>|
|Component:||locale||Assignee:||GNU C Library Locale Maintainers <libc-locales>|
|Severity:||normal||CC:||bugdal, dwmw2, glibc-bugs, junkmailnotread, neleai|
Description Bernardo Innocenti 2007-09-14 06:51:22 UTC
Some filesystems, notably JFFS2 which is used in embedded systems such as the OLPC, cannot support shared writable file mapping. Providing a fallback seems extremely simple: on mmap() failure, malloc() a memory buffer and do a final write() operation in close_archive(). Building the locale archive does not seem to be a performance critical opearation. So we may wish to simplify code by supporting only the write() mechanism. If you like the proposal, I volunteer to provide a patch. I should have papers on file with the FSF for libc too (but I'm not sure).
Comment 1 junkmailnotread 2012-02-21 14:42:33 UTC
This is a serious bug and still present in glibc-2.13. Why no progress? To clarify, localedef *fails* if /usr/lib/locale/locale-archive is located on a file system - such as JFFS2 - which does not support the mmap(2) MAP_SHARED flag. As far as I can tell, any Linux kernel file system whose mmap handler is: generic_file_readonly_mmap() does not support MAP_SHARED. Currently, as of linux-3.3, these include: 9p afs jffs2 logfs The bug is easy to demonstrate. Here, the root file system is a JFFS2 file system, and /var/tmp is a tmpfs file system: # ls -l /usr/lib/locale total 0 # df /usr/lib/locale Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 78592 27816 50776 36% / # localedef -f ISO-8859-1 -i en_GB en_GB.ISO-8859-1 cannot map archive header: Invalid argument # rmdir /usr/lib/locale # ln -s /var/tmp /usr/lib/locale # df /usr/lib/locale Filesystem 1K-blocks Used Available Use% Mounted on none 30664 24 30640 1% /var # localedef -f ISO-8859-1 -i en_GB en_GB.ISO-8859-1 # localedef --list en_GB.iso88591 # I've just spent a day tracking this bug down, only to discover it was reported over 4 years ago.
Comment 2 Rich Felker 2012-02-21 16:49:24 UTC
I would say it's a serious kernel bug for MAP_SHARED to fail on any ordinary file. The type of filesystem it's on should not matter. Unfortunately the kernel has lots of bugs like this and they seem to be treated somewhere between lowest-priority and WONTFIX...
Comment 3 David Woodhouse 2012-02-21 20:54:39 UTC
No, it's quite expected that some file systems don't support shared writable mmap.
Comment 4 Rich Felker 2012-02-21 22:51:54 UTC
Per POSIX: The mmap() function shall be supported for the following memory objects: Regular files [SHM][X> Shared memory objects <X] [TYM][X> Typed memory objects <X] No exception is made that says MAP_SHARED need not work for certain regular files, so I interpret this as meaning that a system on which some filesystems do not support MAP_SHARED is non-conformant.
Comment 5 David Woodhouse 2012-02-22 09:47:27 UTC
But mmap() *is* supported on this object. It's just that PROT_WRITE isn't supported, in conjunction with MAP_SHARED. Perhaps we should return ENOTSUP for a PROT_WRITE shared mapping? And whatever POSIX says, this is a common behaviour from file systems and it's easy to work cope with. Why *wouldn't* we?
Comment 6 Ondrej Bilka 2013-10-17 12:09:11 UTC
Main problem here is lack of resources, If you come with patch that adds a fallback it would be welcome.