From: Roland Dreier <rdreier@cisco.com>
To: Hannes Hering <hannes.hering@linux.vnet.ibm.com>
Cc: alexs@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
ewg@lists.openfabrics.org, linuxppc-dev@ozlabs.org,
raisch@de.ibm.com, ossrosch@linux.vnet.ibm.com
Subject: Re: [PATCH 2.6.31] ehca: Tolerate dynamic memory operations and huge pages
Date: Fri, 12 Jun 2009 21:50:58 -0700 [thread overview]
Message-ID: <adar5xoybwt.fsf@cisco.com> (raw)
In-Reply-To: <200906091559.24661.hannes.hering@linux.vnet.ibm.com> (Hannes Hering's message of "Tue, 9 Jun 2009 15:59:24 +0200")
OK, one major issue with this patch and a few minor nits.
First, the major issue is that I don't see anything in the patch that
changes the code in ehca_mem_notifier() in ehca_main.c:
case MEM_GOING_ONLINE:
case MEM_GOING_OFFLINE:
/* only ok if no hca is attached to the lpar */
spin_lock_irqsave(&shca_list_lock, flags);
if (list_empty(&shca_list)) {
spin_unlock_irqrestore(&shca_list_lock, flags);
return NOTIFY_OK;
} else {
spin_unlock_irqrestore(&shca_list_lock, flags);
if (printk_timed_ratelimit(&ehca_dmem_warn_time,
30 * 1000))
ehca_gen_err("DMEM operations are not allowed"
"in conjunction with eHCA");
return NOTIFY_BAD;
}
But your patch description says:
> This patch implements toleration of dynamic memory operations....
But it seems you're still going to hit the same NOTIFY_BAD case above
after your patch. So something doesn't compute for me. Could you
explain more?
Second, a nit:
> +#define EHCA_REG_MR 0
> +#define EHCA_REG_BUSMAP_MR (~0)
and you pass these as the reg_busmap parm in:
> int ehca_reg_mr(struct ehca_shca *shca,
> struct ehca_mr *e_mr,
> u64 *iova_start,
> @@ -991,7 +1031,8 @@
> struct ehca_pd *e_pd,
> struct ehca_mr_pginfo *pginfo,
> u32 *lkey, /*OUT*/
> - u32 *rkey) /*OUT*/
> + u32 *rkey, /*OUT*/
> + int reg_busmap)
and test it as:
> + if (reg_busmap)
> + ret = ehca_reg_bmap_mr_rpages(shca, e_mr, pginfo);
> + else
> + ret = ehca_reg_mr_rpages(shca, e_mr, pginfo);
So the ~0 for true looks a bit odd. One option would be to make
reg_busmap a bool, since that's how you're using it, but then you lose
the nice self-documenting macro where you call things.
So I think it would be cleaner to do something like
enum ehca_reg_type {
EHCA_REG_MR,
EHCA_REG_BUSMAP_MR
};
and make the "int reg_busmap" parameter into "enum ehca_reg_type reg_type"
and have the code become
+ if (reg_type == EHCA_REG_BUSMAP_MR)
+ ret = ehca_reg_bmap_mr_rpages(shca, e_mr, pginfo);
+ else if (reg_type == EHCA_REG_MR)
+ ret = ehca_reg_mr_rpages(shca, e_mr, pginfo);
+ else
+ ret = -EINVAL
or something like that.
> +struct ib_dma_mapping_ops ehca_dma_mapping_ops = {
> + .mapping_error = ehca_dma_mapping_error,
> + .map_single = ehca_dma_map_single,
> + .unmap_single = ehca_dma_unmap_single,
> + .map_page = ehca_dma_map_page,
> + .unmap_page = ehca_dma_unmap_page,
> + .map_sg = ehca_dma_map_sg,
> + .unmap_sg = ehca_dma_unmap_sg,
> + .dma_address = ehca_dma_address,
> + .dma_len = ehca_dma_len,
> + .sync_single_for_cpu = ehca_dma_sync_single_for_cpu,
> + .sync_single_for_device = ehca_dma_sync_single_for_device,
> + .alloc_coherent = ehca_dma_alloc_coherent,
> + .free_coherent = ehca_dma_free_coherent,
> +};
I always think structures like this are easier to read if you align the
'=' signs. But no big deal.
> + ret = ehca_create_busmap();
> + if (ret) {
> + ehca_gen_err("Cannot create busmap.");
> + goto module_init2;
> + }
> +
> ret = ibmebus_register_driver(&ehca_driver);
> if (ret) {
> ehca_gen_err("Cannot register eHCA device driver");
> ret = -EINVAL;
> - goto module_init2;
> + goto module_init3;
> }
>
> ret = register_memory_notifier(&ehca_mem_nb);
> if (ret) {
> ehca_gen_err("Failed registering memory add/remove notifier");
> - goto module_init3;
> + goto module_init4;
Having to renumber unrelated things is when something changes is why I
don't like this style of error path labels. But I think it's well and
truly too late to fix that in ehca.
- R.
next prev parent reply other threads:[~2009-06-13 4:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-09 13:59 [PATCH 2.6.31] ehca: Tolerate dynamic memory operations and huge pages Hannes Hering
2009-06-10 0:02 ` Michael Ellerman
2009-06-10 8:54 ` Hannes Hering
2009-06-13 4:50 ` Roland Dreier [this message]
2009-06-16 7:08 ` Alexander Schmidt
2009-06-16 16:10 ` [ewg] " Roland Dreier
2009-06-17 6:41 ` Alexander Schmidt
2009-06-16 7:10 ` [PATCH 2.6.31 try 2] " Alexander Schmidt
2009-06-23 5:19 ` [ewg] " Roland Dreier
2009-06-23 8:11 ` Alexander Schmidt
2009-06-23 17:30 ` 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=adar5xoybwt.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=alexs@linux.vnet.ibm.com \
--cc=ewg@lists.openfabrics.org \
--cc=hannes.hering@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=ossrosch@linux.vnet.ibm.com \
--cc=raisch@de.ibm.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;
as well as URLs for NNTP newsgroup(s).