Bug 11269 - syscall.mmap decoding $fd incorrectly with MAP_ANONYMOUS
Summary: syscall.mmap decoding $fd incorrectly with MAP_ANONYMOUS
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: tapsets (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: David Smith
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-10 21:57 UTC by David Smith
Modified: 2010-02-23 21:58 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Smith 2010-02-10 21:57:53 UTC
The user side of mmap is defined like this:

void *mmap(void *addr, size_t length, int prot, int flags,               
            int fd, off_t offset);

The kernel side is defined like this:

long sys_mmap(unsigned long addr, unsigned long len,                          
          unsigned long prot, unsigned long flags,                             
          unsigned long fd, unsigned long off)

Notice that on the user side, 'fd' is a signed integer, while on the kernel side
it is an unsigned long.

The mmap manpage says this about the MAP_ANONYMOUS flag:

MAP_ANONYMOUS                                                            
      The mapping is not backed by any file; its contents are initial-  
      ized to zero.  The fd and offset arguments are ignored; however,  
      some  implementations require  fd to be -1 if MAP_ANONYMOUS (or  
      MAP_ANON) is specified, and portable applications should ensure  
      this.
              
Here's the problem.  When MAP_ANONYMOUS is used and fd is set to -1, the
syscall.mmap probe treats $fd as an unsigned long, so -1 looks like 4294967295
(on x86_64).
Comment 1 David Smith 2010-02-23 21:58:40 UTC
Fixed in commit d945a07.