public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/11611] New: statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits
@ 2010-05-19 17:47 rang at me dot com
2010-05-19 17:48 ` [Bug libc/11611] " rang at me dot com
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: rang at me dot com @ 2010-05-19 17:47 UTC (permalink / raw)
To: glibc-bugs
I'm running on CentOS 5.4 (but this bug appears to go back a long ways).
I have a file system mounted which has a 64-bit FSID, of which bit 31 is set:
000486ba.a1297d6b
Note that the lower 32 bits of the FSID, if interpreted as a signed number, are negative.
If I apply fstatvfs() to this file system, I get an incorrect FSID, because the lower half is sign-extended into the upper half:
fstatvfs returns:
ffffffff.a1297d6b
If I call fstatfs() instead, I get:
000486ba.a1297d6b
I traced the problem down to the INTERNAL_STATVFS routine in glibc/sysdeps/unix/sysv/linux/internal_statvfs.c. (This is not
quite the newest version, as the source tree I had handy was dated 2009-09-09, but I don't see any recent changes in this
area.)
The fsid is assigned here:
if (sizeof (buf->f_fsid) == sizeof (fsbuf->f_fsid))
buf->f_fsid = (fsbuf->f_fsid.__val[0]
| ((unsigned long int) fsbuf->f_fsid.__val[1]
<< (8 * (sizeof (buf->f_fsid)
- sizeof (fsbuf->f_fsid.__val[0])))));
Note that ' fsbuf->f_fsid.__val[0] ' is not cast to an unsigned value. f_fsid is defined in glibc/bits/typesizes.h as a structure of
two 'int' values.
Thus f_fsid, which is a 64-bit value, gets assigned a 32-bit signed 'int' value which is ORed against the upper 32 bits. If the
lower half has its sign bit set, the f_fsid will be incorrect.
Luckily, there is an easy workaround, as the statfs() and fstatfs() calls don't suffer from this problem. (But they're not POSIX,
either.)
--
Summary: statvfs sign-extends lower 32 bits of f_fsid field,
loses upper 32 bits
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: rang at me dot com
CC: glibc-bugs at sources dot redhat dot com
GCC host triplet: x86_64, Linux (CentOS 5.4)
http://sourceware.org/bugzilla/show_bug.cgi?id=11611
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/11611] statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits
2010-05-19 17:47 [Bug libc/11611] New: statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits rang at me dot com
@ 2010-05-19 17:48 ` rang at me dot com
2010-05-19 18:04 ` rang at me dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: rang at me dot com @ 2010-05-19 17:48 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From rang at me dot com 2010-05-19 17:47 -------
A really simple test program, if you happen to have a file system around that delivers these FSIDs....
#include <stdio.h>
#include <sys/statfs.h>
#include <sys/statvfs.h>
#include <fcntl.h>
void main(int argc, char *argv[])
{
int fd;
struct statvfs v;
struct statfs suck;
if (argc != 2) { printf("need mountpoint\n"); return; }
fd = open(argv[1], O_RDONLY);
if (fd < 0) perror("open");
if (fstatvfs(fd, &v) < 0) perror("fstatvfs");
printf("%016lx\n", v.f_fsid);
if (fstatfs(fd, &suck) < 0) perror("fstatfs");
printf("%016lx\n", suck.f_fsid);
}
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11611
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/11611] statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits
2010-05-19 17:47 [Bug libc/11611] New: statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits rang at me dot com
2010-05-19 17:48 ` [Bug libc/11611] " rang at me dot com
@ 2010-05-19 18:04 ` rang at me dot com
2010-05-20 20:44 ` rang at me dot com
2010-09-28 2:37 ` drepper dot fsp at gmail dot com
3 siblings, 0 replies; 6+ messages in thread
From: rang at me dot com @ 2010-05-19 18:04 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From rang at me dot com 2010-05-19 18:04 -------
For better correctness, the test program should probably do something like
unsigned long id;
memcpy(&id, &suck.f_fsid, sizeof(id));
printf("%016lx\n", id);
rather than just passing the structure to printf and expecting the right thing to happen, but either shows
the correct FSID on x86_64.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11611
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/11611] statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits
2010-05-19 17:47 [Bug libc/11611] New: statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits rang at me dot com
2010-05-19 17:48 ` [Bug libc/11611] " rang at me dot com
2010-05-19 18:04 ` rang at me dot com
@ 2010-05-20 20:44 ` rang at me dot com
2010-09-28 2:37 ` drepper dot fsp at gmail dot com
3 siblings, 0 replies; 6+ messages in thread
From: rang at me dot com @ 2010-05-20 20:44 UTC (permalink / raw)
To: glibc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
GCC build triplet| |x86_64-unknown-linux-gnu
| |(CentOS 5.4)
GCC host triplet|x86_64, Linux (CentOS 5.4) |x86_64-unknown-linux-gnu
| |(CentOS 5.4)
GCC target triplet| |x86_64-unknown-linux-gnu
| |(CentOS 5.4)
http://sourceware.org/bugzilla/show_bug.cgi?id=11611
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/11611] statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits
2010-05-19 17:47 [Bug libc/11611] New: statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits rang at me dot com
` (2 preceding siblings ...)
2010-05-20 20:44 ` rang at me dot com
@ 2010-09-28 2:37 ` drepper dot fsp at gmail dot com
3 siblings, 0 replies; 6+ messages in thread
From: drepper dot fsp at gmail dot com @ 2010-09-28 2:37 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper dot fsp at gmail dot com 2010-09-28 02:37 -------
Fixed in git.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://sourceware.org/bugzilla/show_bug.cgi?id=11611
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/11611] statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits
[not found] <bug-11611-131@http.sourceware.org/bugzilla/>
@ 2014-06-30 18:03 ` fweimer at redhat dot com
0 siblings, 0 replies; 6+ messages in thread
From: fweimer at redhat dot com @ 2014-06-30 18:03 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=11611
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-06-30 18:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-05-19 17:47 [Bug libc/11611] New: statvfs sign-extends lower 32 bits of f_fsid field, loses upper 32 bits rang at me dot com
2010-05-19 17:48 ` [Bug libc/11611] " rang at me dot com
2010-05-19 18:04 ` rang at me dot com
2010-05-20 20:44 ` rang at me dot com
2010-09-28 2:37 ` drepper dot fsp at gmail dot com
[not found] <bug-11611-131@http.sourceware.org/bugzilla/>
2014-06-30 18:03 ` fweimer at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).