linux-kernel - Re: [PATCH] kernel/timer.c: using spin_lock_irqsave instead of spin_lock + local_irq_save, especially when CONFIG

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.02.1306201218360.4013@ionos.tec.linutronix.de>
Date:	Thu, 20 Jun 2013 12:42:08 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Chen Gang <gang.chen@...anux.com>
cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kernel/timer.c: using spin_lock_irqsave instead of
 spin_lock + local_irq_save, especially when CONFIG_LOCKDEP not defined

Chen,

On Thu, 20 Jun 2013, Chen Gang wrote:
> On 06/20/2013 05:07 PM, Thomas Gleixner wrote:
> > If A is semantically the same as B, then B is semantically the same as
> > A. At least that's the common understanding.
> > 
> 
>   From A to B is OK.
> 
> Not means:
> 
>   From B to A is also OK.

Either you're questioning logic, math and fundamental basics of
computer science or you simply fail to grok the difference between
semantics and implementation details. See below.

> > Yes, it depends on the implementation, but all implementations do:
> > 
> >      local_irq_save(flags);
> >      arch_spin_lock_flags(l, flags);
> > 
> 
> Yes this is spin_lock_irqsave().
> 
> At least, this implemenation is not equal to.
> 
> 	local_irq_save(flags);
> 	spin_lock(l);

Again. It is semantically the same, because the semantics are:

   spin_lock_irqsave() returns with interrupts disabled, preemption
   disabled and the lock acquired.

This construct exactly follows these semantics:

 	local_irq_save(flags);
 	spin_lock(l);

After spin_lock(l) interrupts are disabled, preemption is disabled and
the lock is acquired. End of discussion.

I wasted enough time explaining you the difference between semantics
and implementation, but you seem to be simply advisory restistant.

And I already told you very impolite in the other thread, that I'm not
going to cope with such nonsense anymore. And yes, I'm tired of it.

Provide factual prove, that there is a bug in the code. And to prove
that, you actually need to understand the code and the basic concepts
behind it. 

If you keep up pursuing your contributions plan at the expense of my
and other peoples valuable time, I consider this as extremly impolite
from your side. The form of collaboration you are going to achieve
this way is an entry in my /dev/null mail filter.

Thanks,

	tglx

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