headers
David Gwynne | 1 Jun 2010 03:09
Favicon

possible fix to races in ami(4)

you cant test a variable and then sleep on it without blocking
interrupts, cos a completion could change the variables state between
those two actions.

could anyone test setting a hotspare on ami(4) while doing io?

dlg

Index: ami.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/ami.c,v
retrieving revision 1.204
diff -u -p ami.c
--- ami.c	20 May 2010 00:55:17 -0000	1.204
+++ ami.c	31 May 2010 12:42:47 -0000
 <at>  <at>  -186,11 +186,8  <at>  <at>  ami_remove_runq(struct ami_ccb *ccb)
 	splassert(IPL_BIO);

 	TAILQ_REMOVE(&ccb->ccb_sc->sc_ccb_runq, ccb, ccb_link);
-	if (TAILQ_EMPTY(&ccb->ccb_sc->sc_ccb_runq)) {
-		ccb->ccb_sc->sc_drained = 1;
-		if (ccb->ccb_sc->sc_drainio)
-			wakeup(ccb->ccb_sc);
-	}
+	if (ccb->ccb_sc->sc_drainio && TAILQ_EMPTY(&ccb->ccb_sc->sc_ccb_runq))
+		wakeup(ccb->ccb_sc);
 }

 void
 <at>  <at>  -198,7 +195,6  <at>  <at>  ami_insert_runq(struct ami_ccb *ccb)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dawe | 1 Jun 2010 04:12
Picon
Picon

comment fix for ber.c

ber_calc_len() is not an internal function in snmpd(8) and ypldap(8).
It's used this way in ldapd(8), but it's likely better to keep the binding consistent.

Index: ldapd/ber.c
===================================================================
RCS file: /cvs/src/usr.sbin/ldapd/ber.c,v
retrieving revision 1.1
diff -u -p -r1.1 ber.c
--- ldapd/ber.c	31 May 2010 17:36:31 -0000	1.1
+++ ldapd/ber.c	1 Jun 2010 01:50:06 -0000
 <at>  <at>  -819,10 +819,6  <at>  <at>  ber_free_elements(struct ber_element *ro
 	free(root);
 }

-/*
- * internal functions
- */
-
 size_t
 ber_calc_len(struct ber_element *root)
 {
 <at>  <at>  -853,6 +849,10  <at>  <at>  ber_calc_len(struct ber_element *root)

 	return (root->be_len + size);
 }
+
+/*
+ * internal functions
+ */
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marco Peereboom | 1 Jun 2010 05:24
Picon
Favicon

Re: possible fix to races in ami(4)

And make sure the hotspare kicks in.  You HAVE to create the hotspare
under heavy io.

On Tue, Jun 01, 2010 at 11:09:53AM +1000, David Gwynne wrote:
> you cant test a variable and then sleep on it without blocking
> interrupts, cos a completion could change the variables state between
> those two actions.
> 
> could anyone test setting a hotspare on ami(4) while doing io?
> 
> dlg
> 
> Index: ami.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/ic/ami.c,v
> retrieving revision 1.204
> diff -u -p ami.c
> --- ami.c	20 May 2010 00:55:17 -0000	1.204
> +++ ami.c	31 May 2010 12:42:47 -0000
>  <at>  <at>  -186,11 +186,8  <at>  <at>  ami_remove_runq(struct ami_ccb *ccb)
>  	splassert(IPL_BIO);
>  
>  	TAILQ_REMOVE(&ccb->ccb_sc->sc_ccb_runq, ccb, ccb_link);
> -	if (TAILQ_EMPTY(&ccb->ccb_sc->sc_ccb_runq)) {
> -		ccb->ccb_sc->sc_drained = 1;
> -		if (ccb->ccb_sc->sc_drainio)
> -			wakeup(ccb->ccb_sc);
> -	}
> +	if (ccb->ccb_sc->sc_drainio && TAILQ_EMPTY(&ccb->ccb_sc->sc_ccb_runq))
> +		wakeup(ccb->ccb_sc);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim van der Molen | 1 Jun 2010 21:14
Picon
Picon
Favicon

Bug in gcc 3?

I'm running i386 -current of 13 May and ran into surprising behaviour
from gcc. Consider the following code snippet:

	int i;

	i = 1;
	if (i += 1 == 2)
		printf("%d; should be 2\n", i);

	i = 1;
	if ((i += 1) == 2)
		printf("%d; should be 2\n", i);

The output is:

	1; should be 2
	2; should be 2

It seems gcc parses the += statement wrongly: "a += b == c" should be
interpreted as something like "(a = a + b) == c", but instead gcc seems
to interpret it as "a = (a + b == c)". That would explain why i equals 1
in the first line of output.

Would this be a bug in gcc or am I overlooking something?

Regards,
Tim
Permalink | Reply | 7 comments |
headers
Joerg Sonnenberger | 1 Jun 2010 21:28
Picon

Re: Bug in gcc 3?

On Tue, Jun 01, 2010 at 09:14:53PM +0200, Tim van der Molen wrote:
> Would this be a bug in gcc or am I overlooking something?

== has a higher precendence than += and therefore binds stronger.
See operator(7).

Joerg
Permalink | Reply | 1 comment |
headers
Nikolai Fetissov | 1 Jun 2010 21:30
Gravatar

Re: Bug in gcc 3?

> I'm running i386 -current of 13 May and ran into surprising behaviour
> from gcc. Consider the following code snippet:
>
> 	int i;
>
> 	i = 1;
> 	if (i += 1 == 2)
> 		printf("%d; should be 2\n", i);
>
> 	i = 1;
> 	if ((i += 1) == 2)
> 		printf("%d; should be 2\n", i);
>
> The output is:
>
> 	1; should be 2
> 	2; should be 2
>
> It seems gcc parses the += statement wrongly: "a += b == c" should be
> interpreted as something like "(a = a + b) == c", but instead gcc seems
> to interpret it as "a = (a + b == c)". That would explain why i equals 1
> in the first line of output.
>
> Would this be a bug in gcc or am I overlooking something?

== has higher precedence then += so the first
expression is parsed as ( i += ( 1 == 2 )).

--
 Nikolai
(Continue reading)

Permalink | Reply | 0 comments |

Gmane