netdev
[Top] [All Lists]

Re: Fw: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary data

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: Fw: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database
From: Andrew Morton <akpm@xxxxxxxx>
Date: Fri, 2 Jul 2004 12:30:22 -0700
Cc: netdev@xxxxxxxxxxx
In-reply-to: <E1BgLql-00055X-00@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <20040702004956.448c95d9.akpm@xxxxxxxx> <E1BgLql-00055X-00@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Andrew Morton <akpm@xxxxxxxx> wrote:
> > 
> > Could someone please take a look at the locking in
> > net/ipv4/ipmr.c:ipmr_mfc_seq_next?  It seems rather broken.
> 
> Obfuscated yes, broken no.

Really?  Even if that goto

        if (it->cache == &mfc_unres_queue) 
                goto end_of_list;

is taken?

Bizarre.  It sure looks wrong.  But then, if the author couldn't be
bothered describing the locking, I can't be bothered reverse engineering
it, so there.

>  Unfortunately the seq interface tends to produce code like this.

Maybe.  It could be that the locking in there is straightforward and
sensible.  But because it is also secretly designed, we see what happens -
it wasted the Stanford guys' time, my time, your time, etc.

Sigh.

<Prev in Thread] Current Thread [Next in Thread>