linux-kernel - Re: [PATCH 4/5] kgdb: Use atomic operators which use barriers

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.LFD.2.00.1004021250170.3634@i5.linux-foundation.org>
Date:	Fri, 2 Apr 2010 13:07:26 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jason Wessel <jason.wessel@...driver.com>
cc:	Will Deacon <will.deacon@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	kgdb-bugreport@...ts.sourceforge.net, linux-arm@...r.kernel.org,
	Russell King - ARM Linux <linux@....linux.org.uk>
Subject: Re: [PATCH 4/5] kgdb: Use atomic operators which use barriers

On Fri, 2 Apr 2010, Linus Torvalds wrote:
> 
> But Linux does expect that if some other CPU modifies a memory location, 
> then we _will_ see that modification eventually. If the CPU needs help to 
> do so, then cpu_relax() needs to do that. Again - this has nothing to do 
> with memory barriers. It's just a basic requirement.

Btw, this is not necessarily just limited to cpu_relax() either. The 
assumption that we'll eventually see changes to memory is pretty common.

If some architecture doesn't see updates from other CPU's (or maybe DMA) 
without extra help, I suspect that it might be a good idea to not just 
have IO instructions but also things like 'udelay()' have that "extra 
helping sauce" in them.

For the exact same reason: we have drivers that depend on things like 
jiffies updates happening automatically, eg:

	drivers/scsi/u14-34f.c:   while ((jiffies - time) < (10 * HZ) && limit++ < 200000) udelay(100L);

or

	drivers/isdn/hisax/elsa_ser.c-  while(timeout-- && cs->hw.elsa.transcnt)
	drivers/isdn/hisax/elsa_ser.c:          udelay(1000);

or

	drivers/serial/68328serial.c:   while (!(uart->utx.w & UTX_TX_AVAIL)) udelay(5);

where those variables we read may be updated from another CPU taking an 
interrupt (or by DMA - I didn't look at how UTX_TX_AVAIL gets set, for 
example).

Now, in practice, I suspect the above kind of busy loop is _way_ less 
common. It's harder to grep for (I picked 'udelay()' to look for, but 
the result is full of noise that does IO etc that would presumably fix 
things anyway, so the above two are just random examples of some drivers 
basically reading variables in a busy loop).

And for something like ARM, random drivers probably don't much matter. So 
I doubt that this udelay() thing is at _all_ as important as cpu_relax() 
is, and ARM maintainers can probably happily just ignore it.

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