Definitly a bug. The __ctl_store stores 16 registers and passing only
the first element of the array will make the addrtype in the
__ctl_store
macro too small:
Yes, exactly.
#define __ctl_store(array, low, high) ({ \
typedef struct { char _[sizeof(array)]; } addrtype; \
asm volatile( \
" stctg %2,%3,0(%1)\n" \
: "=m" (*(addrtype *)(array)) \
: "a" (&array), "i" (low), "i" (high)); \
})
We've used __ctl_store with an "unsigned long" as first argument at a
couple of places.
Only one, actually: in __udelay() (it does two __ctl_load()s as well).
Oh, and paging_init() has some __ctl_load() with an unsigned long.
If __cpu_up dies with an ICE then these other
occurences will probably be broken as well.
"=m" (*(addrtype *)(<unsigned long>)) doesn't look healthy since the
unsigned long is interpreted as an address. Not good ..
Yeah. What is this whole addrtype thing supposed to accomplish?
Can't you just write "=m" (array) ?
[/me tries it out]
That works fine for __ctl_store(), but doing the analogue thing to
__ctl_load() gives
arch/s390/kernel/smp.c:341: error: memory input 3 is not directly
addressable
which seems to mean that that input isn't an lvalue, but that's a)
nonsense
and b) why would it work for __ctl_store() then. So now I'm hopelessly
confused and I'll just give up.
I'll add this patch to the queue for 2.6.26
Thanks. At least this patch is obviously correct :-)
and have to think about some more fixes.
Better you than me ;-)
More seriously, please keep me informed.
Segher
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
