This is the mail archive of the mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: next test release (5th)

On Sun, Oct 01, 2000 at 01:38:43PM +0200, Thorsten Kukuk wrote:
> Hi,
> On Sat, Sep 30, Jakub Jelinek wrote:
> > On Fri, Sep 29, 2000 at 09:30:16AM +0200, Thorsten Kukuk wrote:
> > > 
> > > Hi,
> > > 
> > > I have only one bigger problem: H.J. Lu's patch for sunrpc/udp
> > > (IP_PKTINFO) patch does not seem to work on big endian platforms.
> > > 
> > > The server sends the data to the network, but the client never
> > > becomes the answer. I will try to look at it, but I don't know
> > > anything about IP_PKTINFO.
> > 
> > I think this is related to the portmap hang on boot. Older kernels used to
> > even crash when glibc 2.1.9x portmap was started, then DaveM fixed a bug in
> > the kernel and said something needs to be fixed in userland as well, but I
> > did not get to it yet and cannot find the mail right now (vger is not
> > accessible now and DaveM is until monday? on holidays).
> > So I guess 2.1.95 can be released with this known issue and I'll work with
> > DaveM on fixing sunrpc/udp on SPARC soon afterwards.
> Does this mean there is a bug in the SPARC code in all kernel versions
> with IP_PKTINFO ? Maybe this a problem with sparc64, but I doubt this
> is the reason for the sparc32 problems with HJLs patch.
> If I remove the patch from HJL, everything works fine on sparc32.
> Try the following: boot a sparc32 system with glibc 2.1.94 without
> HJLs patch. Then kill ypbind and restart it, but LD_PRELOAD glibc 2.1.94
> with the patch. Everything will work except ypbind. So I doubt that it
> is a problem with the kernel and portmap. I think the portmap problem
> you see comes from the problem with glibc.

The problem is slightly different - it is in the cmsghdr structure
definition in the Linux kernel and SPARC 32<->64bit translation layer.
cmsghdr is defined as size_t; int; int while on e.g. on Solaris it is
socklen_t; int; int which would simplify things a lot (because unlike size_t
socklent_t does not differ between 64bit kernel and 32bit userland).
The 32<->64bit translation layer (sys_sparc32.c) unfortunately unless it
wants to suck really badly has to do the uint64_t;int;int ->
uint32_t;int;int cmsghdr translation in userland and at the moment it does
so in situ.
So, I think we basically have 3 options:
- hack around it in H.J's patch so that we always give some space in the
msg_control buffer (other places in glibc use stuff like CMSG_SPACE() to
calculate msg_controllen for recvmsg and they always seem to give space for
the in situ translation).
- hack the sys32_recvmsg translation so that it does not do the 32<->64bit
msg_control translation in situ, but instead e.g. allocates a msg_controllen
* 1.5 area off the userland %sp (and decrements it temporarily).
- change cmsghdr definition at least on sparc64 (maybe ia64, mips64, k8) to
socklen_t and kill all the ugly translation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]