From owner-freebsd-arch@FreeBSD.ORG Fri Apr 9 08:08:15 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CAC106566B for ; Fri, 9 Apr 2010 08:08:15 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB1A8FC1D for ; Fri, 9 Apr 2010 08:08:14 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA13482; Fri, 09 Apr 2010 10:54:42 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O0934-0004di-2z; Fri, 09 Apr 2010 10:54:42 +0300 Message-ID: <4BBEDD41.4070101@freebsd.org> Date: Fri, 09 Apr 2010 10:54:41 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: arch@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: panic: getblk: size(%d) > MAXBSIZE(%d) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 08:08:15 -0000 Some context. Recently we've investigated a problem with FAT filesystems that have more than 64K bytes per cluster (on media with sector size > 512). One of the symptoms was panic in the subject line. I've got curious why we have that check and what would go wrong if we allowed that condition to be violated. The check was added quite a long time ago, in 1996. I wonder if anyone remembers details of a problem that it fixed. Also, if MAXBSIZE limit was chosen appropriately. And, if the protected code changed enough since then to warrant a re-evaluation of this check. I tried to inspect the code and find any hard limits that would be exceeded when a large enough size parameter is passed. The only limit that I've found so far is a size of b_pages array in struct buf: struct vm_page *b_pages[btoc(MAXPHYS)]; Of course, current default value of MAXPHYS is only 2 * MAXBSIZE. But many people already use higher non-default values and there was a talk of bumping the default value too. (Also there is a question of appropriate uses for MAXBSIZE, but that's a different topic). If the b_pages is the only limit indeed, then the check could be changed to something like: if (size > MAXPHYS) ... Also, there is a question if larger size would lead to a suboptimal behavior in buffer cache / VM code even if it doesn't break anything. Thank you in advance for any information and analysis! -- Andriy Gapon