linux-kernel - Re: [PATCH] IB/ehca: Serialize HCA-related hCalls on POWER5

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: <OFD9564F75.44193623-ONC12573AE.002EA542-C12573AE.002F5FBC@de.ibm.com>
Date:	Tue, 11 Dec 2007 09:38:58 +0100
From:	Joachim Fenkes <FENKES@...ibm.com>
To:	Roland Dreier <rdreier@...co.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Christoph Raisch <raisch@...ibm.com>,
	OF-EWG <ewg@...ts.openfabrics.org>,
	OF-General <general@...ts.openfabrics.org>,
	LKML <linux-kernel@...r.kernel.org>, linuxppc-dev@...abs.org,
	Marcus Eder <meder@...ibm.com>,
	Stefan Roscher <stefan.roscher@...ibm.com>
Subject: Re: [PATCH] IB/ehca: Serialize HCA-related hCalls on POWER5

Roland Dreier <rdreier@...co.com> wrote on 10.12.2007 22:47:37:

> It's a big problem.  If you cannot implement FMRs in such a way that
> you can handling having map_phys_fmr being called in a context that
> can't sleep, then I think the only option is to remove your FMR
> support.

That's kind of what I feared you would say =)

> It's an optional device feature, so this should be OK
> (although the iSER driver currently seems to depend on a device
> supporting FMRs, which is probably going to be a problem with iWARP
> support in the future anyway).

I don't feel very well with removing code from the driver that iSER seems 
to depend on. Are there plans to fix this in iSER?

In reality, PHYP rarely ever returns H_LONG_BUSY, and we haven't had any 
problems with iSER in the field yet. I admit that our FMR code is 
dangerous, but I prefer "dangerous but working for the customer" over "not 
working for the customer at all".

Maybe we can agree on keeping the status quo until no more ULPs depend on 
FMR, then remove FMR from ehca? If so, we'd also let the _irqsave 
spinlocks around hCalls stay in place.

Regards,
  Joachim
--
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/