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]
Date:	Thu, 22 Oct 2009 23:16:27 +0530
From:	"Leonidas ." <leonidas137@...il.com>
To:	Valdis.Kletnieks@...edu
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Can current macro be accessed from interrupt context?

>
> So given that the process ID is quite often totally pointless, what were you
> trying to accomplish by getting the process ID?
>

I am glad that you asked this question. Actually, what I am trying to
do may not be
even feasible in kernel space. Just spending some cycles on checking
the feasibility.

Here is what I am trying to do.

I am trying to emulate thread local storage in kernel space. Only conceptually.
In user space, multithreaded programs can avoid locking issues by keeping
per thread data structures, as per my understanding in kernel space there is
no such notion. Per cpu data structures is not quite the same thing
since locking
can be avoided only for accessing data local to that cpu, for
accessing data belonging
to other cpus, we would still need some locking mechanism.

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. 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.

-Leo.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ