linux-kernel - Re: Can current macro be accessed from interrupt context?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AE165A1.5080204@ladisch.de>
Date:	Fri, 23 Oct 2009 10:13:21 +0200
From:	Clemens Ladisch <clemens@...isch.de>
To:	"Leonidas ." <leonidas137@...il.com>
CC:	Valdis.Kletnieks@...edu,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Can current macro be accessed from interrupt context?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/