From owner-freebsd-i386@FreeBSD.ORG Sun Aug 6 02:20:15 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E212C16A4E1 for ; Sun, 6 Aug 2006 02:20:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 293EA43D55 for ; Sun, 6 Aug 2006 02:20:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k762KFfE015582 for ; Sun, 6 Aug 2006 02:20:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k762KEQu015581; Sun, 6 Aug 2006 02:20:14 GMT (envelope-from gnats) Resent-Date: Sun, 6 Aug 2006 02:20:14 GMT Resent-Message-Id: <200608060220.k762KEQu015581@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Justin T. Gibbs" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9408916A4DA for ; Sun, 6 Aug 2006 02:17:40 +0000 (UTC) (envelope-from gibbs@ns1.scsiguy.com) Received: from ns1.scsiguy.com (ns1.scsiguy.com [70.89.174.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4941D43D46 for ; Sun, 6 Aug 2006 02:17:40 +0000 (GMT) (envelope-from gibbs@ns1.scsiguy.com) Received: from ns1.scsiguy.com (gibbs@localhost [127.0.0.1]) by ns1.scsiguy.com (8.13.6/8.13.6) with ESMTP id k762HdEQ023159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 5 Aug 2006 20:17:39 -0600 (MDT) (envelope-from gibbs@ns1.scsiguy.com) Received: (from gibbs@localhost) by ns1.scsiguy.com (8.13.6/8.13.6/Submit) id k762Hcqs023158; Sat, 5 Aug 2006 20:17:38 -0600 (MDT) (envelope-from gibbs) Message-Id: <200608060217.k762Hcqs023158@ns1.scsiguy.com> Date: Sat, 5 Aug 2006 20:17:38 -0600 (MDT) From: "Justin T. Gibbs" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: i386/101453: linprocfs disallows non-zero file offsets for maps files X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2006 02:20:16 -0000 >Number: 101453 >Category: i386 >Synopsis: linprocfs disallows non-zero file offsets for maps files >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Aug 06 02:20:14 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Justin T. Gibbs >Release: FreeBSD 6.1-STABLE i386 >Organization: >Environment: System: FreeBSD aslan.scsiguy.com 6.1-STABLE FreeBSD 6.1-STABLE #4: Sat May 6 17:23:37 MDT 2006 gibbs@aslan.scsiguy.com:/usr/obj/usr/src/sys/ASLAN i386 >Description: While trying to run Matlab R2006a under linux emulation, its embedded JVM complained of being unable to locate the position of thread stacks. The JRE uses the linux procfs filesystem's "maps" file to determine this information. Using ktrace I determined that the JRE was reading the maps file in 4k chunks, but that the output for the matlab process was much larger than this and was being truncated. The attached patch allows the maps file to be read in chunks rather than all at once. After applying this patch, the ktrace output indicated that all data was read correctly and the JVM error dissappeared. Unfortunately, Matlab still hangs when attempting to launch its java based GUI. I'm still investigating that issue, but currently believe that the root cause for that is elsewhere in our compatibility framework. >How-To-Repeat: Attempt to read the maps file in linprocfs in multiple chunks. >Fix: Index: linprocfs.c =================================================================== RCS file: /usr/cvs/src/sys/compat/linprocfs/linprocfs.c,v retrieving revision 1.89.2.3 diff -u -r1.89.2.3 linprocfs.c --- linprocfs.c 3 Jul 2006 06:38:53 -0000 1.89.2.3 +++ linprocfs.c 26 Jul 2006 02:35:11 -0000 @@ -851,12 +851,14 @@ vm_object_t obj, tobj, lobj; vm_ooffset_t off = 0; char *name = "", *freename = NULL; + char *bufptr; size_t len; ino_t ino; int ref_count, shadow_count, flags; int error; struct vnode *vp; struct vattr vat; + off_t cur_offset; PROC_LOCK(p); error = p_candebug(td, p); @@ -867,10 +869,8 @@ if (uio->uio_rw != UIO_READ) return (EOPNOTSUPP); - if (uio->uio_offset != 0) - return (0); - error = 0; + cur_offset = 0; if (map != &curthread->td_proc->p_vmspace->vm_map) vm_map_lock_read(map); for (entry = map->header.next; @@ -924,12 +924,35 @@ if (freename) free(freename, M_TEMP); len = strlen(mebuffer); + bufptr = mebuffer; + if (cur_offset < uio->uio_offset) { + off_t delta; + + /* + * Discard data until we get to the + * desired offset in the data. + */ + delta = uio->uio_offset - cur_offset; + if (delta >= len) { + cur_offset += len; + continue; + } + bufptr += delta; + len -= delta; + } + if (len > uio->uio_resid) len = uio->uio_resid; /* * XXX We should probably return * EFBIG here, as in procfs. */ - error = uiomove(mebuffer, len, uio); + error = uiomove(bufptr, len, uio); + /* + * Once we start outputing data, there is no need to + * look for where the data will start, so keep + * cur_offset in sync with the offset in the uio struct. + */ + cur_offset = uio->uio_offset; if (error) break; } >Release-Note: >Audit-Trail: >Unformatted: