Return-Path: Received: from quartz.orcorp.ca ([184.70.90.242]:56892 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752993AbbGOTRy (ORCPT ); Wed, 15 Jul 2015 15:17:54 -0400 Date: Wed, 15 Jul 2015 13:17:46 -0600 From: Jason Gunthorpe To: "'Christoph Hellwig'" Cc: Sagi Grimberg , Steve Wise , "'Steve Wise'" , "'Tom Talpey'" , "'Doug Ledford'" , sagig@mellanox.com, ogerlitz@mellanox.com, roid@mellanox.com, linux-rdma@vger.kernel.org, eli@mellanox.com, target-devel@vger.kernel.org, linux-nfs@vger.kernel.org, trond.myklebust@primarydata.com, bfields@fieldses.org, "'Oren Duer'" Subject: Re: [PATCH V3 1/5] RDMA/core: Transport-independent access flags Message-ID: <20150715191746.GH23588@obsidianresearch.com> References: <20150710161108.GA19042@obsidianresearch.com> <55A24571.60902@dev.mellanox.co.il> <00e201d0be6a$e49bc910$add35b30$@opengridcomputing.com> <20150714192941.GA26292@obsidianresearch.com> <00e401d0be6b$d3952750$7abf75f0$@opengridcomputing.com> <20150714195511.GB7716@infradead.org> <20150714202943.GB26927@obsidianresearch.com> <55A61E38.20201@dev.mellanox.co.il> <20150715121926.GB14993@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20150715121926.GB14993@infradead.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Wed, Jul 15, 2015 at 05:19:26AM -0700, 'Christoph Hellwig' wrote: > On Wed, Jul 15, 2015 at 11:47:52AM +0300, Sagi Grimberg wrote: > > > struct ib_pd *ib_alloc_pd(struct ib_device *device) > > > { > > > struct ib_pd *pd; > > >+ struct ib_device_attr devattr; > > >+ int rc; > > >+ > > >+ rc = ib_query_device(device, &devattr); > > >+ if (rc) > > >+ return ERR_PTR(rc); > > > > Unrelated question, > > Can we just cache the dev_attr in ib_device already? It's pretty > > obvious that each consumer that opens a device will automatically > > query its attributes... > > Instead of caching it I'd suggest to kill ib_device_attr and move > the field into struct ib_device, similar to how all major kernel > subsystems work. Otherwise fully agreed. Indeed, I think there are quite a few weird cases like this floating around for someone to work on :) Jason