Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Mar 2003 03:06:59 -0500
From:      Hiten Pandya <hiten@unixdaemons.com>
To:        Luigi Rizzo <rizzo@icir.org>
Cc:        Hiten Pandya <hiten@unixdaemons.com>, arch@FreeBSD.ORG
Subject:   Re: Using m_getcl() in network and nfs code paths
Message-ID:  <20030307080659.GA60937@unixdaemons.com>
In-Reply-To: <20030306212638.A32850@xorpc.icir.org>
References:  <20030307004958.GA98917@unixdaemons.com> <20030306212638.A32850@xorpc.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo (Thu, Mar 06, 2003 at 09:26:38PM -0800) wrote:
> the number of places where the code does
> 
> 	m = (want > X) ? m_getcl(...) : m_get(...)
> 
> makes me wonder if we shouldn't perhaps add a 'desired_size'
> parameter to m_getcl() so we can have the test made in one
> place and in a consistent way (i..e always use the same
> threshold X instead of MLEN/MINCLSIZE/MHLEN
> which i suspect is incorrect somewhere.

	Can you provide some examples for this?  I do no exactly follow.
	The size checking is always changing.  I have similar changes to
	the dev/ and pci/ and netgraph/ tree, and I noticed that it gets
	checked against MLEN/MCLBYTES/MHLEN and whatnot... but I do not think
	that is a bug, because surely they all represent different
	quantities?
	
> Also it makes no sense to print a msg on failure -- the allocator
> already does that. And even less to panic (as in the netatm
> case).

	Right.  I avoided this in the first place, because some did
	complain that extra verbosity was needed, but now that you have
	made the case crystal clear, I will remove them.  As for the
	panic, well, if you noticed, error checking after mbuf + cluster
	allocation was screwed from the start in the NFS code (the
	client code is sort of better in this than the server code).  So
	I was left with no choice but to panic, because there was no way
	I could return errors in a void function without considerable
	changes to the surrounding code and files as well.
	
> All of the above are bugs in the original code but given that
> you are going through it it would make sense to fix them once
> for all.

	Yes.  I will go ahead and fix the printf stuff, but I guess I
	can't look at the nfs error checking problems right now.  I will
	put an XXX comment saying 'better error checking', and then I
	will get to it some other fine day. :-)

	Thanks for your comments Luigi, very much appreciated.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030307080659.GA60937>