This is the mail archive of the libc-hacker@sources.redhat.com 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] |
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. Jakub
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |