linux-kernel - Re: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib

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: <20150416174547.GA23263@obsidianresearch.com>
Date:	Thu, 16 Apr 2015 11:45:47 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Roland Dreier <roland@...nel.org>
Cc:	Michael Wang <yun.wang@...fitbricks.com>,
	"Hefty, Sean" <sean.hefty@...el.com>,
	"Weiny, Ira" <ira.weiny@...el.com>,
	Hal Rosenstock <hal.rosenstock@...il.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tom Tucker <tom@...ngridcomputing.com>,
	Steve Wise <swise@...ngridcomputing.com>,
	Hoang-Nam Nguyen <hnguyen@...ibm.com>,
	Christoph Raisch <raisch@...ibm.com>,
	infinipath <infinipath@...el.com>, Eli Cohen <eli@...lanox.com>,
	"Latif, Faisal" <faisal.latif@...el.com>,
	Jack Morgenstein <jackm@....mellanox.co.il>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Haggai Eran <haggaie@...lanox.com>,
	Tom Talpey <tom@...pey.com>, Doug Ledford <dledford@...hat.com>
Subject: Re: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib

On Thu, Apr 16, 2015 at 10:02:46AM -0700, Roland Dreier wrote:
> On Thu, Apr 16, 2015 at 9:44 AM, Jason Gunthorpe
> <jgunthorpe@...idianresearch.com> wrote:
> >> We can give client->add() callback a return value and make
> >> ib_register_device() return -ENOMEM when it failed, just wondering
> >> why we don't do this at first, any special reason?
> 
> > No idea, but having ib_register_device fail and unwind if a client
> > fails to attach makes sense to me.
> 
> It seems a bit unfriendly to fail an entire device if one ULP has a
> problem.  Let's say you have a system whose main network connection is
> IPoIB.  Would you want that connection to come up even if, say, the
> NFS/RDMA server fails to find the memory registration type it likes?

That is true, but we also never test any of the cases where one
expected ULP fails to load but another one needs it. Like IPoIB needs
sa_query, for instance.

I'm not saying ULPs should error for soft reasons, like your NFS
example, this unwind would be for OOM, or other 'impossible' class
errors.

That said, the driver core does not fail a bus driver register if a
client probe fails (we could copy this), but it also doesn't just
silently eat the error code either.

What about ib_register_client? If any add's fail should it unwind and
fail upwards?

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