Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Aug 2004 12:43:10 +0200
From:      Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
To:        Pawel Jakub Dawidek <pjd@freebsd.org>
Cc:        ipfw@freebsd.org
Subject:   Re: kern/46557: ipfw pipe show fails with lots of queues
Message-ID:  <20040825104310.GA57463@shellma.zin.lublin.pl>
In-Reply-To: <200408232155.i7NLt4gF052086@freefall.freebsd.org>
References:  <200408232155.i7NLt4gF052086@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 23, 2004 at 09:55:04PM +0000, Pawel Jakub Dawidek wrote:

> Here is prosposed patch against HEAD:
[...]
> +static int
> +dummynet_get(struct sockopt *sopt)
> +{
> +    char *buf, *bp ; /* bp is the "copy-pointer" */
> +    size_t size ;
> +    struct dn_flow_set *set ;
> +    struct dn_pipe *p ;
> +    int error=0, i ;
> +
> +    /* XXX lock held too long */
> +    DUMMYNET_LOCK();
> +    /*
> +     * XXX: Ugly, but we need to allocate memory with M_WAITOK flag and we
> +     *      cannot use this flag while holding a mutex.
> +     */
> +    for (i = 0; i < 10; i++) {
> +	size = dn_calc_size();
> +	DUMMYNET_UNLOCK();
> +	buf = malloc(size, M_TEMP, M_WAITOK);

Wouldn't it be better to allocate size+something or size*i*something?
Theoretically with dynamic pipes we can be so unlucky that even after
10 tries and with plenty of free memory we still can't hit this size
because it floats all the time. (If so, next condition should be >=.)
Right now, we will report ENOBUFS not only when there is no memory
(BTW, shouldn't it be ENOMEM?) but also when we have ENOLUCK. ;)

> +	DUMMYNET_LOCK();
> +	if (size == dn_calc_size())
> +		break;
> +	free(buf, M_TEMP);
> +	buf = NULL;
> +    }
> +    if (buf == NULL) {
>  	DUMMYNET_UNLOCK();
>  	return ENOBUFS ;
>      }


-- 
Paweł Małachowski



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