From owner-freebsd-fs@FreeBSD.ORG Fri Feb 1 10:23:47 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DBF316A46D; Fri, 1 Feb 2008 10:23:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id E843C13C4D3; Fri, 1 Feb 2008 10:23:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 852E743E542; Fri, 1 Feb 2008 12:05:06 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lnDZozSuo4P; Fri, 1 Feb 2008 12:05:06 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id CF65A43C749; Fri, 1 Feb 2008 12:05:05 +0200 (EET) Message-ID: <47A2EED0.3010209@icyb.net.ua> Date: Fri, 01 Feb 2008 12:05:04 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Remko Lodder , scottl@FreeBSD.org, freebsd-fs@freebsd.org References: <200612221824.kBMIOhfM049471@freefall.freebsd.org> <47A2EDB0.8000801@icyb.net.ua> In-Reply-To: <47A2EDB0.8000801@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bruce Evans Subject: Re: kern/84983: [udf] [patch] udf filesystem: stat-ting files could randomly fail X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2008 10:23:47 -0000 Sorry - I sent this a reply to a wrong email. Correct PR is kern/77234. http://www.freebsd.org/cgi/query-pr.cgi?pr=77234 on 01/02/2008 12:00 Andriy Gapon said the following: > on 22/12/2006 20:24 Pav Lucistnik said the following: >> Synopsis: [udf] [patch] udf filesystem: stat-ting files could randomly fail >> >> State-Changed-From-To: open->closed >> State-Changed-By: pav >> State-Changed-When: Fri Dec 22 18:24:14 UTC 2006 >> State-Changed-Why: >> Fixed in 6.1 and up >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=84983 > > I found a bug in the patch. I got a panic in real situation when testing > a UDF fs with a directory with a huge number of files (~10^4), but this > can be easily shown in the code too: > > static int > udf_readatoffset(struct udf_node *node, int *size, off_t offset, > struct buf **bp, uint8_t **data) > { > ... > *size = min(*size, MAXBSIZE); > > if ((error = udf_readlblks(udfmp, sector, *size + (offset & > udfmp->bmask), bp))) { > > If it so happens that *size gets MAXBSIZ value and (offset & > udfmp->bmask) is not zero, then a value > MAXBSIZ would be passed to > udf_readlblks->bread->breadn->getblk and the latter will panic because > it has an explicit assert for size <= MAXBSIZ. > > I think there should be something in the code like the following: > *size = min(*size, MAXBSIZE - (offset & udfmp->bmask)); > > ---- a different, under-debugged problem ----- > BTW, on some smaller directories (but still large ones) I get some very > strange problems with reading a directory too. It seems like some bad > interaction between udf and buffer cache system. I added a lot of > debugging prints and the problems looks like the following: > > read starting at physical sector (2048-byte one) N, size is ~20K, N%4=0 > bread(4 * N, some_big_size) > correct data is read > repeat the above couple dozen times > read starting at physical sector (2048-byte one) N+1, size is ~20K > bread(4 * (N+1), some_big_size) > data is read from physical sector N+4 (instead of N+1) > > I remember that Bruce Evance warned me that something like this could > happen but I couldn't understand him, because I don't understand > VM/buffer subsystem. I'll try to dig up the email. > > -- Andriy Gapon