| 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
| ||
|
Date: Fri, 01 Sep 2006 13:45:27 -0700 From: Bryan O'Sullivan <bos@...hscale.com> To: Roland Dreier <rdreier@...co.com> Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org, openib-general@...nib.org, Adrian Bunk <bunk@...sta.de>, "David S. Miller" <davem@...emloft.net> Subject: Re: [openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error On Fri, 2006-09-01 at 12:53 -0700, Roland Dreier 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. On the off chance that you might be arguing that mthca_write64 could be a candidate drop-in for writeq on 32-bit arches: That approach might work on mthca hardware, but it's not safe in general. The ipath driver requires a proper writeq(), for example, because the hardware will quite legitimately treat 32-bit writes to some registers as separate accesses, and screw things up royally. You get atomicity from the perspective of software with this approach, but you can do exciting and bad things to hardware. <b -- VGER BF report: H 3.23386e-12 - 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