linux-kernel - Re: [RFC] w1: Disable irqs in critical section

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]

Date:	Tue, 13 Sep 2011 15:41:42 -0700
From:	Andrew Morton <akpm@...gle.com>
To:	J.Weitzel@...tec.de
Cc:	Evgeniy Polyakov <zbr@...emap.net>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC] w1: Disable irqs in critical section

On Thu, 08 Sep 2011 07:46:21 +0200
Jan Weitzel <J.Weitzel@...tec.de> wrote:

> Am Mittwoch, den 07.09.2011, 21:50 +0400 schrieb Evgeniy Polyakov:
> > On Wed, Sep 07, 2011 at 10:48:32AM +0200, Jan Weitzel (j.weitzel@...tec.de) wrote:
> > > Interrupting w1_delay in w1_read_bit results in missing the low level
> > > on the w1 line and receiving "1" instead of "0".
> > > Adding local_irq_save / local_irq_restore around the critical section
> > 
> > This means that CPU will be essentially stuck for 15 useconds for every
> > bit transferred, doesn't really look like a good idea.
> > 
> > Are you absolutely sure that missing bit is because of timings and not
> > some other bug?
> > 
> 
> I trigger a gpio line after the samplepoint. I case of a wrong bit the
> sample is taken after the "0 gap". The cycle time (samplt to sample)is
> increased form about 80__s to 95__s. 
> I did the measurement with the w1-gpio driver on a OMAP4 board.
> 

I'm not clear on how w1 actually works.  Is it a bit-banging
protocol in which the timing is provided by the host CPU?  If so then
yes, we should carefully disable interrupts in places where an
interrupt would disrupt critical timing.  (But what to do about NMIs
and SMIs?)

Disabling interrupts for 15us is pretty obnoxious, but there's a 55us
delay there with interrupts enabled, so the overall effect shouldn't be
too bad.

Finally, can we fine-tune the interrupt-disabled section a bit?  For
example, can the local_irq_disable() be moved to after the
write_bit(..., 0)?

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