linux-kernel - Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

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: <20060901135911.bc53d89a.akpm@osdl.org>
Date:	Fri, 1 Sep 2006 13:59:11 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	Roland Dreier <rdreier@...co.com>, Adrian Bunk <bunk@...sta.de>,
	Tom Tucker <tom@...ngridcomputing.com>,
	Steve Wise <swise@...ngridcomputing.com>,
	Roland Dreier <rolandd@...co.com>,
	linux-kernel@...r.kernel.org, openib-general@...nib.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile
 error

On Fri, 1 Sep 2006 21:43:43 +0100
Russell King <rmk+lkml@....linux.org.uk> wrote:

> On Fri, Sep 01, 2006 at 01:04:44PM -0700, Andrew Morton wrote:
> > On Fri, 01 Sep 2006 12:53:47 -0700
> > Roland Dreier <rdreier@...co.com> wrote:
> > > Yes, I agree that's a good plan, especially the documentation part.
> > > However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h 
> > > is legitimate: the driver uses __raw_writeq() when it exists and uses
> > > two __raw_writel()s properly serialized with a device-specific lock to
> > > get exactly the atomicity it needs on 32-bit archs.
> > 
> > No, driver-specific workarounds are not legitimate, sorry.
> > 
> > The driver should simply fail to compile on architectures which do not
> > implement __raw_writeq().
> 
> So, what you're basically saying is that on architectures which can _NOT_
> implement an atomic __raw_writeq(), certain drivers simply will not be
> available?

If the driver *requires* an atomic __raw_writeq(), then yes.  The driver
cannot work correctly on that machine.

If, however, there is some way in which we can make the hardware work on
that machine (say, with other locking) then we got the __raw_writeq()
interface design (whatever that is) wrong.

IOW, the best way of tackling this is to work out what we're trying to do,
design an interface, then implement it.

Doing funny workarounds within individual drivers isn't the way to address
this.  In fact it's an indication that something is wrong.

> > We can speed up the process by sending helpful emails to architecture
> > maintainers, but they'll notice either way.
> 
> I think you're completely wrong in the context of the message you're
> replying to - it's talking about an _atomic_ 64-bit write.
> 
> Sure, if you want a _non-atomic_ 64-bit write then that's possible,
> but many 32-bit architectures can't do a 64-bit atomic IO write and
> that isn't something they can "fix".

If the hardware/driver absolutely requires that the 64-bit write be atomic
on-the-bus then sure, the fix is to disable that driver on that
architecture in Kconfig.

If, however, the atomicity requirement is a software thing (we need to be
atomic against other CPU reads and writes) then that can be solved with
locking, and we can design APIs for this which can be implemented
efficiently on all architectures.

-- 
VGER BF report: H 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/