linux-kernel - Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs

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: <alpine.DEB.2.00.1105041341550.5495@router.home>
Date:	Wed, 4 May 2011 13:49:09 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Pekka Enberg <penberg@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Jens Axboe <axboe@...nel.dk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	werner <w.landgraf@...ru>, "H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs

On Wed, 4 May 2011, Linus Torvalds wrote:

>
> So I'm still waiting for the tested-by, but in the meantime I wrote a
> changelog. And part of that changelog reads:
>
> [ Btw, that whole "generic code defaults to no protection" design just
>   sounds stupid - if the code needs no protection, there is no reason to
>   use "cmpxchg_double" to begin with.  So we should probably just remove
>   the unprotected version entirely as pointless.   - Linus ]

The unprotected version is the __this_cpu_cmpxchg_double? That currently
has no user and could be removed. But all other functions also have __
variants so it was put there for symmetries sake.

> which really sums up the whole thing.
>
> The current "this_cpu_cmpxchg_double()" implementation is just
> incredibly idiotic. There is absolutely _no_ point to having that
> function at all. Why does it exist?

this_cpu_cmpxchg_double() affords protection against preemption but not
irqs. In the allocator case we have to deal with interrupts so its not
useful there. Other code that can guarantee that nothing runs from irq
context can use this function and then the fallback handling on other
arches can avoid disabling and enabling interrupts which is required by
irqsafe_cpu_cmpxchg_double().

> I can kind of see the point of the "preempt" version, although I'm not
> entirely convinced of that either. But the notion of having a
> "cmpxchg" function that isn't atomic even on a single CPU just makes
> me go "f*ck that, whoever wrote that is just a moron".
>
> If the function doesn't need atomicity, you're really better off just
> writing it out.  It's going to be faster on pretty much all
> architectures using just regular load/store instructions.

The unlocked cmpxchg8b/16b is quite fast on x86. The __ function allows
the use of cmpxchg8b on x86 and the fallback (and therefore longer) code
on other archs.

But I see the point that __this_cpu_cmpxchg double is pretty useless.
There is no user and so it could be removed.
--
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/