Date: Fri, 27 Mar 2009 19:31:07 +0300 From: Chagin Dmitry <dchagin@freebsd.org> To: Doug Ambrisko <ambrisko@ambrisko.com> Cc: Doug Ambrisko <ambrisko@freebsd.org>, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, Roman Divacky <rdivacky@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r190445 - in head/sys: amd64/linux32 compat/linprocfs compat/linux conf dev/ipmi modules/ipmi modules/linprocfs Message-ID: <20090327163107.GA7564@dchagin.static.corbina.ru> In-Reply-To: <200903271547.n2RFl1qh044116@ambrisko.com> References: <20090327060643.GA1937@dchagin.static.corbina.ru> <200903271547.n2RFl1qh044116@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Fri, Mar 27, 2009 at 08:47:01AM -0700, Doug Ambrisko wrote:
> Chagin Dmitry writes:
> | On Thu, Mar 26, 2009 at 05:08:59PM -0700, Doug Ambrisko wrote:
> [snip]
> | > Okay, I did some more instrumenting again and found that I was
> | > slightly wrong. The mmap that was failing was 0xcf79c000 and not
> | > 0xf0000. This probably makes since since the sign bit was set
> | > on 0xcf79c000. However, it appear mmap doesn't really do negative
> | > seeks. Looking at the freebsd32_mmap the structure it uses for
> | > args is:
> | > struct freebsd6_freebsd32_mmap_args {
> | > char addr_l_[PADL_(caddr_t)]; caddr_t addr; char addr_r_[PADR_(caddr_t)];
> | > char len_l_[PADL_(size_t)]; size_t len; char len_r_[PADR_(size_t)];
> | > char prot_l_[PADL_(int)]; int prot; char prot_r_[PADR_(int)];
> | > char flags_l_[PADL_(int)]; int flags; char flags_r_[PADR_(int)];
> | > char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
> | > char pad_l_[PADL_(int)]; int pad; char pad_r_[PADR_(int)];
> | > char poslo_l_[PADL_(u_int32_t)]; u_int32_t poslo; char poslo_r_[PADR_(u_int32_t)];
> | > char poshi_l_[PADL_(u_int32_t)]; u_int32_t poshi; char poshi_r_[PADR_(u_int32_t)];
> | > };
> | > with both the high and the lows being u_int32_t.
> | >
> | > So I wonder if in the linux32 the structure that is:
> | > struct l_mmap_argv {
> | > l_uintptr_t addr;
> | > l_size_t len;
> | > l_int prot;
> | > l_int flags;
> | > l_int fd;
> | > l_off_t pgoff;
> | > } __packed;
> | > should be uint32_t for pgoff?
> |
> | yes, you are right. s/uint32_t/l_ulong/ :)
> | also remove __packed.
> | thnx!
>
> Index: linux.h
> ===================================================================
> RCS file: /usr/local/cvsroot/freebsd/src/sys/amd64/linux32/linux.h,v
> retrieving revision 1.24
> diff -u -p -r1.24 linux.h
> --- linux.h 26 Mar 2009 17:14:22 -0000 1.24
> +++ linux.h 27 Mar 2009 15:38:40 -0000
> @@ -79,7 +79,7 @@ typedef l_ulong l_ino_t;
> typedef l_int l_key_t;
> typedef l_longlong l_loff_t;
> typedef l_ushort l_mode_t;
> -typedef l_ulong l_off_t;
> +typedef l_long l_off_t;
> typedef l_int l_pid_t;
> typedef l_uint l_size_t;
> typedef l_long l_suseconds_t;
> @@ -179,8 +179,8 @@ struct l_mmap_argv {
> l_int prot;
> l_int flags;
> l_int fd;
> - l_off_t pgoff;
> -} __packed;
> + l_ulong pgoff;
> +};
>
> /*
> * stat family of syscalls
>
> Okay, then this is my proposed patch to fix this. This version works
> fine for the Linux tool. If people are happy with it then I'll check it
> in. I thought that I had greped for usage of l_off_t but missed that seek
> was using it :-(
>
commit please.
and. please, look to r185438. I suggest to use it in mfi
--
Have fun!
chd
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)
iEYEARECAAYFAknM/0sACgkQ0t2Tb3OO/O0hPgCaA6XN99uEXQcMujixOUxWIcn5
C/MAoJvbrmjA2o7VP8WLRpRz+bXE1lsI
=ybS3
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090327163107.GA7564>