[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1364218338.2532.15.camel@cr0>
Date: Mon, 25 Mar 2013 21:32:18 +0800
From: Cong Wang <amwang@...hat.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, david.ward@...mit.edu, jorge@...2.net
Subject: Re: [PATCH net-next] 802: fix a possible race condition
On Sun, 2013-03-24 at 17:24 -0400, David Miller wrote:
> From: Cong Wang <amwang@...hat.com>
> Date: Sat, 23 Mar 2013 13:14:08 +0800
>
> > From: Cong Wang <amwang@...hat.com>
> >
> > garp_pdu_queue() should ways be called with this spin lock.
> > garp_uninit_applicant() only holds rtnl lock which is not
> > enough here.
> >
> > Found by code inspection.
> >
> > Cc: "David S. Miller" <davem@...emloft.net>
> > Cc: David Ward <david.ward@...mit.edu>
> > Cc: "Jorge Boncompte [DTI2]" <jorge@...2.net>
> > Signed-off-by: Cong Wang <amwang@...hat.com>
>
> Under what conditions can entries be removed or added to
> these RB-trees without the RTNL being held?
At least garp_join_timer() calls garp_pdu_queue() in a timer:
static void garp_join_timer(unsigned long data)
{
struct garp_applicant *app = (struct garp_applicant *)data;
spin_lock(&app->lock);
garp_gid_event(app, GARP_EVENT_TRANSMIT_PDU);
garp_pdu_queue(app);
spin_unlock(&app->lock);
garp_queue_xmit(app);
garp_join_timer_arm(app);
}
which I don't think can hold RTNL lock possibly.
>
> If such events cannot happen, then no locking is needed.
>
> Even if your change is correct and necessary, the answer to my
> needs to be added to your commit message.
Ok, I will.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists