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] [day] [month] [year] [list]
Message-ID: <adaabj62ebg.fsf@cisco.com>
Date:	Sun, 04 May 2008 10:01:55 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	benh@...nel.crashing.org
Cc:	"Moore\, Eric" <Eric.Moore@....com>, linux-kernel@...r.kernel.org
Subject: Re: HELP:  Is writeq an atomic operation??

 > > I don't have an authoritative answer, but I can say that I coded
 > > drivers/infiniband/hw/mthca and .../mlx4 assuming that writeq() is
 > > atomic in the sense that you say, and no one has reported any problems.
 > > 
 > > But I'm sure no one has stressed the drivers on 64-bit mips or anything
 > > unusual like that.
 > 
 > Surely only on 64 bits archs right ?

Your question is a bit too terse for me to know exactly what you're
asking, but it is true that these IB drivers use writeq() only on 64-bit
architectures (since no 32-bit architectures even define writeq()!).

The hardware I'm dealing with is smart enough to cope with a driver that
does a write to these 64-bit registers in two 32-bit chunks, as long as
no other writes come in the middle.  So on 32-bit architectures I just
have a spinlock around two writel()s.

The assumption I'm making is that no locking or anything is needed on
64-bit architectures to avoid the writeq() being split into two
transactions with a third unrelated transaction in the middle.

It sounds as though Eric's hardware is much harder to deal with in that
it requires the write to a 64-bit register to be done in a single
transaction, and I'm not sure there is a way to do that on all 32-bit
architectures; certainly we have nothing clean and portable that a
driver can use to do that.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ