Bug 5033 - locarchive does not provide fallback for mmap()
Summary: locarchive does not provide fallback for mmap()
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: locale (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: GNU C Library Locale Maintainers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-14 06:51 UTC by Bernardo Innocenti
Modified: 2015-08-27 21:56 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.