linux-kernel - RE: [PATCH 0/5] Generic smp_call_function(), improvements, and smp_call_function

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1FE6DD409037234FAB833C420AA843ECE5B401@orsmsx424.amr.corp.intel.com>
Date:	Mon, 24 Mar 2008 09:45:06 -0700
From:	"Luck, Tony" <tony.luck@...el.com>
To:	"Jens Axboe" <jens.axboe@...cle.com>
Cc:	<linux-kernel@...r.kernel.org>, <npiggin@...e.de>,
	<paulus@...ba.org>, <tglx@...utronix.de>, <mingo@...hat.com>
Subject: RE: [PATCH 0/5] Generic smp_call_function(), improvements, and smp_call_function_single()

> Funky, how does accessing other CPU's per-cpu variables work on ia64
> then? Perhaps I made some false assumptions.

The per-cpu memory is mapped at two different spots in the kernel
virtual memory.  When cpuA wants to access per-cpu memory that belongs
to cpuB it can use the mappings that allow access to every percpu
area (which may just be indexing by cpu number into a big block of
memory that has all the per-cpu spaces ... or some more complex
arithmetic and pointers for NUMA systems where the per-cpu memory
ought to be allocated out of memory on the right node for the cpu
that it refers to).

When any cpu wants to access its own per-cpu data, it can do so
via the per-cpu mapping (which is much more efficient from a code
generation perspective at the per-cpu virtual area is the top 64K
of virtual address space, so can be accessed with a small negative
offset from register r0).

This is why lists can be a problem ... since the same memory can
be accessed via two different virtual addresses, things can get
badly knotted when the two different addresses get used in different
parts of the code.  Then operations like "list_empty()" may give
the wrong answer because the virtual address used for head->next
isn't the same as that used for head ... but they both refer to the
same underlying object.

> Unfortunately I have no access to any IA64 machines, so I either
> have to yank the ia64 bits (which is unfortunate, since Alan tests
> on those :-) or rely on a bit of help from you and/or others in
> getting that bit right.

I'll see if I can figure out what is going wrong.

-Tony
--
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/