From owner-freebsd-hackers@FreeBSD.ORG  Mon Apr 21 22:16:02 2014
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id DF8989E7
 for <freebsd-hackers@freebsd.org>; Mon, 21 Apr 2014 22:16:02 +0000 (UTC)
Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net
 [50.73.42.1])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id B0FB81DCE
 for <freebsd-hackers@freebsd.org>; Mon, 21 Apr 2014 22:16:02 +0000 (UTC)
Received: from elf.torek.net (localhost [127.0.0.1])
 by elf.torek.net (8.14.5/8.14.5) with ESMTP id s3LMFstd045652
 for <freebsd-hackers@freebsd.org>; Mon, 21 Apr 2014 16:15:54 -0600 (MDT)
 (envelope-from torek@torek.net)
Message-Id: <201404212215.s3LMFstd045652@elf.torek.net>
From: Chris Torek <torek@torek.net>
To: freebsd-hackers@freebsd.org
Subject: MAXPHYS in md(4)
Date: Mon, 21 Apr 2014 16:15:54 -0600
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3
 (elf.torek.net [127.0.0.1]); Mon, 21 Apr 2014 16:15:54 -0600 (MDT)
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Apr 2014 22:16:02 -0000

In svn commit: r264504 - head/sys/geom/uzip we have:

  Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause
  problems in our providers, such as a KASSERT in md(4). ...

That would be this one:

	KASSERT(bp->bio_length <= MAXPHYS, ("bio_length %jd",
	    (uintmax_t)bp->bio_length));
	if ((bp->bio_flags & BIO_UNMAPPED) == 0) {
		pb = NULL;
		aiov.iov_base = bp->bio_data;
	} else {
		pb = getpbuf(&md_vnode_pbuf_freecnt);
		...

As it happens, the KASSERT is really only required for the
pb != NULL case, which uses one of the reserved getpbuf() buffers
that only map MAXPHYS bytes at a time.  If bp->bio_flags says that
the bio is mapped, we just use the existing KVA, and VOP_READ() and
VOP_WRITE() must already break up arbitrarily large transfers.

So, it seems like the md(4) KASSERT can be moved into the "else".
Is this a good idea?  (It might not help r264504 much since it
looks like r264504 wants to handle short-read results anyway, but
it seems overly restrictive to require <= MAXPHYS for the mapped
cases.)

Chris