Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753264AbXJWG4r (ORCPT ); Tue, 23 Oct 2007 02:56:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752065AbXJWG4h (ORCPT ); Tue, 23 Oct 2007 02:56:37 -0400 Received: from mx12.go2.pl ([193.17.41.142]:60747 "EHLO poczta.o2.pl" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751968AbXJWG4g (ORCPT ); Tue, 23 Oct 2007 02:56:36 -0400 Date: Tue, 23 Oct 2007 08:59:51 +0200 From: Jarek Poplawski To: Oleg Nesterov Cc: "Maciej W\. Rozycki" , Andy Fleming , Andrew Morton , Jeff Garzik , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] flush_work_sync vs. flush_scheduled_work Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes Message-ID: <20071023065951.GA1847@ff.dom.local> References: <20071016062108.GB1000@ff.dom.local> <20071017085809.GA1658@ff.dom.local> <20071018063157.GA1694@ff.dom.local> <20071018070531.GA2065@ff.dom.local> <20071018154819.GA425@tv-sign.ru> <20071019075014.GA1765@ff.dom.local> <20071022061143.GA973@ff.dom.local> <20071022180259.GA967@tv-sign.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071022180259.GA967@tv-sign.ru> User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1774 Lines: 48 On Mon, Oct 22, 2007 at 10:02:59PM +0400, Oleg Nesterov wrote: > On 10/22, Jarek Poplawski wrote: ... > > OK, I know I'm dumber and dumber everyday, > > You are not alone. I have the same feeling about myself! Feeling is not the same, only true knowledge counts! > > > these all flushes are > > rtnl lockup vulnerable wrt. other work functions, but cancel_work_sync > > looks perfectly fine > > Yes, > > > Then, if by any chance I'm right, something like flush_work_sync > > (or changed flush_scheduled_work, if there is no problem with such > > a change of implementation) could be safely (if it's called without > > locks used by flushed work only) done cancel_work_sync() way, by > > running a work function after try_to_grab_pending() returns 1 > > If this work doesn't rearm itself - yes. (otherwise, the same ->func > can run twice _at the same time_) > > But again, in this case wait_on_work() after try_to_grab_pending() == 1 > doesn't block, so we can just do > > if (cancel_work_sync(w)) > w->func(); Of course, I should have written it much shorter by saying flush_scheduled_work could be done internally just like you suggested! My point is to make this all safer and simpler, so we don't have to remember each time about these differences wrt. locking. Then checking of such patches could be much easier. Unless this current behavior of flush_scheduled_work has any real advantages, worth of this potential unsafety. (Btw. is there any reason to use this with rearming works, anyway?) Thanks, Jarek P. - 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/