Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758329AbZLNVdp (ORCPT ); Mon, 14 Dec 2009 16:33:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758317AbZLNVdm (ORCPT ); Mon, 14 Dec 2009 16:33:42 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:34648 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1758313AbZLNVdk (ORCPT ); Mon, 14 Dec 2009 16:33:40 -0500 Date: Mon, 14 Dec 2009 16:33:38 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Tejun Heo cc: Kernel development list Subject: Warn people about flush_scheduled_work() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1356 Lines: 38 Tejun: You've spent some time working on the workqueue implementation, right? I'd like to add comments or kerneldoc warning people about how dangerous it can be to use flush_scheduled_work() and related functions. Something like this: Think twice before calling this function! It's very easy to get into trouble if you don't take great care. Either of the following situations will lead to deadlock: Your code is running in the context of a scheduled work routine. Your code or its caller holds a lock needed by one of the work items currently on the workqueue. Since you generally don't know who your caller is, what locks it holds, or what locks are needed by the items on the workqueue, avoiding these situations is quite difficult. Consider using cancel_work_sync() or cancel_delayed_work_sync() instead. In most situations they will accomplish what you need. Does this sound like a good idea? Certainly flush_scheduled_work() is used in places where it shouldn't be. If comments like this are added, where do you think would be a good place to put them? Alan Stern -- 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/