svn commit: r190445 - in head/sys: amd64/linux32 compat/linprocfs compat/linux conf dev/ipmi modules/ipmi modules/linprocfs

Scott Long scottl at samsco.org
Thu Mar 26 15:29:10 PDT 2009


Doug Ambrisko wrote:
> John Baldwin writes:
> | On Thursday 26 March 2009 5:29:42 pm Doug Ambrisko wrote:
> 	[snip]
> | > Maybe you have another suggestion to fix this.  The problem showed up
> | > when doing a mmap of 0xcf79c000 into 0xffffffffcf79c000 also a mmap
> | > of 0xf0000 ended up the same way.  This caused it to fail.  Note this
> | > is only on amd64 with a Linux.  It didn't happen with a FreeBSD i386
> | > version on amd64.  Here is a sample test program:
> | 
> | I'm sure this can be easily fixed in the Linux mmap() handlers instead.  Do 
> | you know if your Linux binary is using mmap2() or the old mmap()?
> 
> I think it uses linux_mmap then bouncing it to linux_mmap_common.
> linux_mmap_common had it right but when it mmap picked it up then 
> it was wrong in my intrumentation. 
> 
> I'll flip the l_off_t type back and then instrument it more to find
> out when things are going bad.  I missed the other usage of l_off_t
> so I agree this is a bad change.  However, I wonder if the other
> usage of l_off_t actually works right or there is a bug with that
> as well?

Well, ultimately remember that offsets can be negative, by definition.

Scott


More information about the svn-src-all mailing list