Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751480AbZJWINU (ORCPT ); Fri, 23 Oct 2009 04:13:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751305AbZJWINT (ORCPT ); Fri, 23 Oct 2009 04:13:19 -0400 Received: from smtprelay08.ispgateway.de ([80.67.31.31]:34038 "EHLO smtprelay08.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbZJWINS (ORCPT ); Fri, 23 Oct 2009 04:13:18 -0400 Message-ID: <4AE165A1.5080204@ladisch.de> Date: Fri, 23 Oct 2009 10:13:21 +0200 From: Clemens Ladisch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Leonidas ." CC: Valdis.Kletnieks@vt.edu, linux-kernel Subject: Re: Can current macro be accessed from interrupt context? References: <5048.1256224623@turing-police.cc.vt.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Df-Sender: linux-kernel@cl.domainfactory-kunde.de Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1709 Lines: 37 Leonidas . wrote: > I am trying to emulate thread local storage in kernel space. [...] > Assume that, a multithreaded app talks to my kernel module using > /dev/node, and I need to book keep certain data in kernel module. The > data I am book keeping can be kept in a central data structure > protected by spinlocks. A better way would be per cpu data structure. > > My idea is to keep data specific to each task which is talking to my > kernel module. Assumption here is a certain task can be in kernel mode > only on one cpu at a time hence that task specific data structure can > be accessed without locks. There is no fixed association between your tasks and the CPUs they are running on. It is possible for two of your threads to be executed on the same CPU (one after the other), or for one thread to migrate between CPUs. > All book keeping which needs to be done in ISRs would be just book > keeping for the interrupted task, i.e. we would populate interrupted > task's data structure. This is where current comes in picture. The task that was interrupted is probably some entirely different task (the X server, the shell, your mail reader, some kernel thread, or any of the other tasks running on your system). It is possible for your interrupt handler to be called for some device request that belongs to one of your tasks that is currently running on another CPU, so you won't be able to manage that data without locking. Best regards, Clemens -- 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/