Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936983AbWLFSHl (ORCPT ); Wed, 6 Dec 2006 13:07:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S936985AbWLFSHl (ORCPT ); Wed, 6 Dec 2006 13:07:41 -0500 Received: from smtp.osdl.org ([65.172.181.25]:51736 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936983AbWLFSHk (ORCPT ); Wed, 6 Dec 2006 13:07:40 -0500 Date: Wed, 6 Dec 2006 10:07:15 -0800 (PST) From: Linus Torvalds To: Jeff Garzik cc: David Howells , Andrew Morton , "Maciej W. Rozycki" , Roland Dreier , Andy Fleming , Ben Collins , Linux Kernel Mailing List Subject: Re: [PATCH] Export current_is_keventd() for libphy In-Reply-To: <457702E2.3000703@garzik.org> Message-ID: References: <1165125055.5320.14.camel@gullible> <20061203011625.60268114.akpm@osdl.org> <20061205123958.497a7bd6.akpm@osdl.org> <6FD5FD7A-4CC2-481A-BC87-B869F045B347@freescale.com> <20061205132643.d16db23b.akpm@osdl.org> <20061205135753.9c3844f8.akpm@osdl.org> <20061206075729.b2b6aa52.akpm@osdl.org> <21690.1165426993@redhat.com> <457702E2.3000703@garzik.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1904 Lines: 53 On Wed, 6 Dec 2006, Jeff Garzik wrote: > > Honestly I wonder if some of these situations really want > "kill_scheduled_work_unless_it_is_already_running_right_now_if_so_wait_for_it" We could do that, and the code to do it would be fairly close to what the "run it" code is. Just replace the if (!test_bit(WORK_STRUCT_NOAUTOREL, &work->management)) work_release(work); f(work); with an unconditional work_release(work); instead. However, I think I'd prefer my patch for now, if only because that "work_release()" thing kind of worries me. You're supposed to either do the release yourself in the work function _after_ you've done all book-keeping, or if the thing doesn't need any book-keeping at all, you can do the "autorelease" thing. The "kill without running" breaks that conceptual model. So a "kill_work()" usage should almost always end up being something like if (kill_work(work)) release anything that running the work function would release but then for the (probably common) case where there is nothing that the work function releases, that would obviously boil down to just a kill_work(work); However, my point is that the _workqueue_ logic cannot know what the user of the workqueue wants, so the "run_scheduled_work()" approach is much saner in this respect. NOTE NOTE NOTE! In neither case can we do anything at all about a workqueue entry that is actually _already_ running on another CPU. My suggested patch will simply not run it at all synchronously (and return 0), and a "kill_work()" thing couldn't do anything either. The required synchronization for something like that simply doesn't exist. Linus - 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/