From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 03:33:47 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7ECFC406; Sun, 21 Jul 2013 03:33:47 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) by mx1.freebsd.org (Postfix) with ESMTP id B9CCEFB5; Sun, 21 Jul 2013 03:33:46 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id r6L3Dg9B011888; Sat, 20 Jul 2013 22:33:39 -0500 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp1.rice.edu with ESMTP id 1dpkf2gyjc-1; Sat, 20 Jul 2013 22:33:39 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from [192.168.5.116] (unknown [12.107.116.132]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id BECC440125; Sat, 20 Jul 2013 22:33:36 -0500 (CDT) Subject: Re: Fix for sys_munlock(2) with racct Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alan Cox In-Reply-To: <20130720112218.GD13628@caravan.chchile.org> Date: Sat, 20 Jul 2013 20:33:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <115EDC04-4B95-4FB5-9092-515188D8ADA7@rice.edu> References: <20130720112218.GD13628@caravan.chchile.org> To: Jeremie Le Hen X-Mailer: Apple Mail (2.1085) X-Proofpoint-SSN: Sensitivity3 Cc: Alan Cox , Konstantin Belousov , freebsd-current@FreeBSD.org, trasz@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 03:33:47 -0000 On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote: > Hi Edward, Alan, >=20 > I plan to commit the following patch: > http://people.freebsd.org/~jlh/racct_munlock.diff >=20 > This solves the following panic: >=20 > panic: racct_sub: freeing 301989888 of resource 5, which is more than = allocated 73728 for pwsafe (pid 4177) >=20 > The problem is that the racct code in sys_munlock() trusts too much = the > user's input. vm_map_unwire_count() now returns how much memory has > really been unwired. >=20 > Any objection? Can you elaborate on what you mean by "sys_munlock() trusts too much the = user's input." munlock(2) is supposed to return ENOMEM if any = addresses within the specified range are not backed by valid mappings. = (Valid mappings with PROT_NONE access are something of a gray area = here.) However, it is not error for a to call munlock() on a range that = isn't locked, or to call it a second, third, etc. time on the same = range. Is that what is provoking your panic? By the way, sys_mlock() uses a simpler approach to deal with a similar = situation: error =3D vm_map_wire(map, start, end,=20 VM_MAP_WIRE_USER | VM_MAP_WIRE_NOHOLES); #ifdef RACCT if (error !=3D KERN_SUCCESS) { PROC_LOCK(proc); racct_set(proc, RACCT_MEMLOCK, ptoa(pmap_wired_count(map->pmap))); PROC_UNLOCK(proc); } #endif However, the code in sys_mlock() for maintaining RACCT_MEMLOCK, = including the above snippet, is race-y. Two simultaneous callers to = sys_mlock() will produce incorrect results. (I haven't looked at = sys_mlockall() or vm_map_growstack().) Also, a wired mapping can be destroyed by calling munmap(2) without = first calling munlock(2), in which case, RACCT_MEMLOCK will be = incorrect. =20 Alan