Andrew Morton <[email protected]> wrote:
> hm, I guess it adds a theoretical deadlock if some other CPU is in the
> middle of printk and is trying to take some_lock and this CPU takes an oops
> while holding some_lock. Probably that's an acceptable tradeoff though.
What it perhaps needs is a maximum number of spins or something like that.
> Does this guy really need to be volatile?
atomic_t is volatile, so that makes no difference.
Actually, I shouldn't use an atomic_t or a signed int as the CPU ID is
unsigned:-/
I'm using -1 / UINT_MAX as a "not in use" thing, but I'm not sure that's
strictly viable.
> Coud we use atomic_t and lose that wmb()?
I talked it over with David Woodhouse, and he's convinced me that we don't
need the barrier: the only thing we care about is getting a printk within a
printk on the CPU because of an oops. THEN we have to break the lock. And in
that case we're looking for the CPU number being set to that of our CPU, and
only our CPU will ever set that.
> Methinks this should be raw_smp_processor_id().
Not only that, but the whole function needs wrapping in preemption
disablement, lest the processor ID change under us.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |