From owner-freebsd-bugs@FreeBSD.ORG Thu Jul 13 09:15:07 2006 Return-Path: X-Original-To: freebsd-bugs@FreeBSD.org Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2994A16A4DA for ; Thu, 13 Jul 2006 09:15:07 +0000 (UTC) (envelope-from ohki@gssm.otsuka.tsukuba.ac.jp) Received: from utogwpl.gssm.otsuka.tsukuba.ac.jp (utogwpl.gssm.otsuka.tsukuba.ac.jp [210.154.96.162]) by mx1.FreeBSD.org (Postfix) with SMTP id 3AA3843D60 for ; Thu, 13 Jul 2006 09:15:04 +0000 (GMT) (envelope-from ohki@gssm.otsuka.tsukuba.ac.jp) Received: (qmail 51988 invoked from network); 13 Jul 2006 09:15:02 -0000 Received: from OneOfLocalMachines (HELO smr00.gssm.otsuka.tsukuba.ac.jp) (10.2.1.1) by 10.1.1.1 with SMTP; 13 Jul 2006 09:15:02 -0000 Received: from gssm.otsuka.tsukuba.ac.jp (localhost [127.0.0.1]) by smr00.gssm.otsuka.tsukuba.ac.jp (8.13.3/8.13.3) with ESMTP id k6D9F2eg054212; Thu, 13 Jul 2006 18:15:02 +0900 (JST) (envelope-from ohki@gssm.otsuka.tsukuba.ac.jp) Message-Id: <200607130915.k6D9F2eg054212@smr00.gssm.otsuka.tsukuba.ac.jp> From: Atsuo Ohki To: "Wojciech A. Koszek" In-reply-to: Your message of "Fri, 07 Jul 2006 16:56:43 GMT" References: <200607060842.k668gK2K021382@smr00.gssm.otsuka.tsukuba.ac.jp> <200607071139.k67BdTqH027312@smr00.gssm.otsuka.tsukuba.ac.jp> <20060707165643.GA60398@FreeBSD.czest.pl> Mime-Version: 1.0 Content-Type: text/plain;charset="ISO-2022-JP" Date: Thu, 13 Jul 2006 18:15:02 +0900 Sender: ohki@gssm.otsuka.tsukuba.ac.jp Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, Robert Watson Subject: Re: kern/99758: chown/chmod pty slave side in kernel X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 09:15:07 -0000 I wrote: > I got stress2.tgz and done `./run.sh pty.cfg' and got the message like > > Memory modified after free ... > Most recently used by DEVFS1 > > The reason for this panic is devfs_close() in fs/devfs/devfs_vnops.c. > As you see, devfs_close() eventually calls ptcclose()/ptsclose() > which calls pty_maybecleanup() destroying devs for ptc&pts, but > devfs_close() then calls dev_relthread() which may access just freeed dev. > > I'm afraid that devfs is not designed to handle destroing dev during > close operation. > > I'm working on this problem with the idea: > i) destory_dev() should not free dev, but just mark inactive. > ii) devfs_populate() should actually free an inactive dev. > iii) modify devfs_find() and other routines to take care of an inactive dev > . > But no success yet ;-< I achieved a little success. Now (really now!), pty test of stress2 is running. I modified as follow: i) destroy_dev() in cdevs' close routine is not appropriate. I introduced hide_dev() (in kern/kern_conf.c) and devfs_hide() (in fs/devfs/devfs_devs.c) to make dev invisible from userland. (via devfs_find(), devfs_readdir() and so on.) ii) pty_maybecleanup() no longer calls destroy_dev(), but calls hide_dev() to make pts/ptc invisible. when both of pts/ptc are closed, link them to pt_free_list as usual (structure dev for ptc/pts are not destroyied!). pty_new() now takes care of destorying dev for ptc/pts. when a new ptc/pts is requested, search pt_free_list to find a devs' which are free!(i.e. si_usecount == 0). if found, destroy existing devs. if not found, things goes by as before. I use the name ptsXX, ptcXX instead of pts/XX, ptc/XX. (original naming causes system hungup related to vnode operation. I must solve this problem.)