From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
To: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, dledford@redhat.com,
Jes.Sorensen@redhat.com, rds-devel@oss.oracle.com
Subject: Re: [PATCH] rds_rdma: don't assume infiniband device is PCI
Date: Thu, 5 Jan 2012 15:05:24 -0200 [thread overview]
Message-ID: <20120105170523.GA19022@oc1711230544.ibm.com> (raw)
In-Reply-To: <ed54708d-990e-4c8f-8057-50a70f93d3d8@default>
> ----- Original Message -----
> From: cascardo@linux.vnet.ibm.com
> To: venkat.x.venkatsubra@oracle.com
> Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cascardo@linux.vnet.ibm.com, dledford@redhat.com, Jes.Sorensen@redhat.com, rds-devel@oss.oracle.com
> Sent: Wednesday, January 4, 2012 4:03:42 PM GMT -06:00 US/Canada Central
> Subject: [PATCH] rds_rdma: don't assume infiniband device is PCI
>
> RDS code assumes that the struct ib_device dma_device member, which is a
> pointer, points to a struct device embedded in a struct pci_dev.
>
> This is not the case for ehca, for example, which is a OF driver, and
> makes dma_device point to a struct device embedded in a struct
> platform_device.
>
> This will make the system crash when rds_rdma is loaded in a system
> with ehca, since it will try to access the bus member of a non-existent
> struct pci_dev.
>
> The only reason rds_rdma uses the struct pci_dev is to get the NUMA node
> the device is attached to. Using dev_to_node for that is much better,
> since it won't assume which bus the infiniband is attached to.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
> Cc: dledford@redhat.com
> Cc: Jes.Sorensen@redhat.com
> Cc: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
> Cc: rds-devel@oss.oracle.com
> ---
> net/rds/ib.h | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/net/rds/ib.h b/net/rds/ib.h
> index edfaaaf..8d2b3d5 100644
> --- a/net/rds/ib.h
> +++ b/net/rds/ib.h
> @@ -186,8 +186,7 @@ struct rds_ib_device {
> struct work_struct free_work;
> };
>
> -#define pcidev_to_node(pcidev) pcibus_to_node(pcidev->bus)
> -#define ibdev_to_node(ibdev) pcidev_to_node(to_pci_dev(ibdev->dma_device))
> +#define ibdev_to_node(ibdev) dev_to_node(ibdev->dma_device)
> #define rdsibdev_to_node(rdsibdev) ibdev_to_node(rdsibdev->dev)
>
> /* bits for i_ack_flags */
> --
> 1.7.4.4
>
On Thu, Jan 05, 2012 at 08:56:34AM -0800, Venkat Venkatsubra wrote:
> Hi Cascardo,
>
> Your changes look good to me.
> But our latest code doesn't use this rdsibdev_to_node macro anywhere.
> Checking with the people in my group who know the history of the NUMA feature.
> Trying to find out if the call to kzalloc_node() can be replaced by kzalloc().
> In which case this macro can be removed.
>
> I will keep you posted.
>
> Venkat
>
Hi, Venkat.
Do you have any public tree where we can track the last changes in RDS?
Note that I have changed ibsdev_to_node, which rdsibdev_to_node makes
use of. Anyway, replacing kzalloc_node with kzalloc has crossed my mind,
but since I was not sure if this would affect latency of RDS in any use
cases, I kept that and used a better function to get the node from the
device. And we have dev_to_node since 2.6.20, so it should not be a
problem to use it.
If possible, keep everyone copied and avoid top posting.
Regards.
Cascardo.
next parent reply other threads:[~2012-01-05 17:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ed54708d-990e-4c8f-8057-50a70f93d3d8@default>
2012-01-05 17:05 ` Thadeu Lima de Souza Cascardo [this message]
2012-01-05 18:57 ` [PATCH] rds_rdma: don't assume infiniband device is PCI David Miller
2012-01-06 15:57 ` Thadeu Lima de Souza Cascardo
2012-01-06 17:43 ` Thadeu Lima de Souza Cascardo
2012-01-06 19:27 Venkat Venkatsubra
-- strict thread matches above, loose matches on Subject: below --
2012-01-04 22:03 Thadeu Lima de Souza Cascardo
2012-01-06 17:47 ` Roland Dreier
2012-01-06 17:49 ` Roland Dreier
2012-01-13 18:17 ` Thadeu Lima de Souza Cascardo
2012-01-13 18:25 ` David Miller
2012-01-13 18:52 ` Thadeu Lima de Souza Cascardo
2012-01-13 21:12 ` David Miller
2012-01-13 21:21 ` Thadeu Lima de Souza Cascardo
2012-01-13 18:35 ` Roland Dreier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120105170523.GA19022@oc1711230544.ibm.com \
--to=cascardo@linux.vnet.ibm.com \
--cc=Jes.Sorensen@redhat.com \
--cc=davem@davemloft.net \
--cc=dledford@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rds-devel@oss.oracle.com \
--cc=venkat.x.venkatsubra@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox