Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Mar 2009 09:45:38 -0700 (PDT)
From:      Doug Ambrisko <ambrisko@ambrisko.com>
To:        Chagin Dmitry <dchagin@freebsd.org>
Cc:        Doug Ambrisko <ambrisko@freebsd.org>, src-committers@freebsd.org, Doug Ambrisko <ambrisko@ambrisko.com>, 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:  <200903271645.n2RGjcC7047793@ambrisko.com>
In-Reply-To: <20090327163107.GA7564@dchagin.static.corbina.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
Chagin Dmitry writes:
| 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.

Will do.

| and. please, look to r185438. I suggest to use it in mfi

Thanks for the pointer on that.  I should also grab iovec32 from
compat/freebsd32/freebsd32.h.

Doug A.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903271645.n2RGjcC7047793>