Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261725AbVDZStz (ORCPT ); Tue, 26 Apr 2005 14:49:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261713AbVDZStd (ORCPT ); Tue, 26 Apr 2005 14:49:33 -0400 Received: from relay.2ka.mipt.ru ([194.85.82.65]:29118 "EHLO 2ka.mipt.ru") by vger.kernel.org with ESMTP id S261702AbVDZStV (ORCPT ); Tue, 26 Apr 2005 14:49:21 -0400 Date: Tue, 26 Apr 2005 22:48:33 +0400 From: Evgeniy Polyakov To: dtor_core@ameritech.net Cc: dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050426224833.3b6a0792@zanzibar.2ka.mipt.ru> In-Reply-To: References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> <20050426203023.378e4831@zanzibar.2ka.mipt.ru> <20050426220713.7915e036@zanzibar.2ka.mipt.ru> <20050426223126.37b7aea1@zanzibar.2ka.mipt.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Tue, 26 Apr 2005 22:48:47 +0400 (MSD) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2552 Lines: 64 On Tue, 26 Apr 2005 13:42:10 -0500 Dmitry Torokhov wrote: > On 4/26/05, Evgeniy Polyakov wrote: > > On Tue, 26 Apr 2005 13:20:08 -0500 > > Dmitry Torokhov wrote: > > > > > On 4/26/05, Evgeniy Polyakov wrote: > > > > Yes, I found it too. > > > > Following patch should be the solution: > > > > > > > > --- orig/drivers/connector/connector.c > > > > +++ mod/drivers/connector/connector.c > > > > @@ -146,13 +146,16 @@ > > > > spin_lock_bh(&dev->cbdev->queue_lock); > > > > list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) { > > > > if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { > > > > - __cbq->cb->priv = msg; > > > > + > > > > + if (!test_bit(0, &work->pending)) { > > > > + __cbq->cb->priv = msg; > > > > > > > > - __cbq->ddata = data; > > > > - __cbq->destruct_data = destruct_data; > > > > + __cbq->ddata = data; > > > > + __cbq->destruct_data = destruct_data; > > > > > > > > > > Still not good enough - work->pending bit gets cleared when work has > > > been scheduled, but before executing payload. You still have the race. > > > > Data pointer is copied before bit is set, > > but I forget that it is not data, but another pointer > > which may be overwritten. > > > > I think we may finish it by setting skb as data, > > and call kfree_skb() as destructor. > > > > Yes, that woudl work, although I would urge you to implement a message > queue for callbacks (probably limit it to 1000 messages or so) to > allow bursting. It already exist, btw, but not exactly in that way - we have skb queue, which can not be filled from userspace if pressure is so strong so work queue can not be scheduled. It is of course different and is influenced by other things but it handles bursts quite well - it was tested on both SMP and UP machines with continuous flows of forks with shape addon of new running tasks [both fith fork bomb and not], so I think it can be called real bursty test. > -- > Dmitry Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/