linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Bob Pearson <rpearsonhpe@gmail.com>
Cc: zyjzyj2000@gmail.com, linux-rdma@vger.kernel.org
Subject: Re: [PATCH for-next v10 07/17] RDMA/rxe: Use kzmalloc/kfree for mca
Date: Tue, 1 Feb 2022 16:14:52 -0400	[thread overview]
Message-ID: <20220201201452.GO1786498@nvidia.com> (raw)
In-Reply-To: <e1b6b398-ebe2-f5aa-e34f-58b786608b1b@gmail.com>

On Tue, Feb 01, 2022 at 02:00:09PM -0600, Bob Pearson wrote:


> as currently written the local variable has a kref obtained from the kref_get in
> rxe_lookup_mcg or the kref_init in rxe_init_mcg if it is newly created. This ref is
> dropped when the local variable goes out of scope. To protect the mcg when it is
> inactive at least one more ref is required. I take an additional ref in rxe_get_mcg
> if the mcg is created to protect the pointer in the red-black tree. This persists
> for the lifetime of the object until it is destroyed when it is removed from the tree
> and has the longest scope. This is enough to keep the object alive (it works fine BTW.)
> It is also possible to take ref's representing the pointers in the list but they
> wouldn't add anything.

I think I got it upside down, but OK this works for me. What was
kbuild complaining about?

> On the other point. Is it standard practice to user ERRPTRs in the
> kernel rather than return arguments? I seem to have seen both styles
> used but it may have been my imagination. I don't have any
> preference here but sometimes choose one or the other in parallel
> flows to make comparable routines in the flows have similar
> interfaces.

Always prefer errptrs.

Jason

  reply	other threads:[~2022-02-01 20:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 22:08 [PATCH for-next v10 00/17] Move two object pools to rxe_mcast.c Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 01/17] RDMA/rxe: Move rxe_mcast_add/delete " Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 02/17] RDMA/rxe: Move rxe_mcast_attach/detach " Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 03/17] RDMA/rxe: Rename rxe_mc_grp and rxe_mc_elem Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 04/17] RDMA/rxe: Enforce IBA o10-2.2.3 Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 05/17] RDMA/rxe: Remove rxe_drop_all_macst_groups Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 06/17] RDMA/rxe: Remove qp->grp_lock and qp->grp_list Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 07/17] RDMA/rxe: Use kzmalloc/kfree for mca Bob Pearson
2022-02-01  1:03   ` kernel test robot
2022-02-01 14:53   ` Jason Gunthorpe
2022-02-01 20:00     ` Bob Pearson
2022-02-01 20:14       ` Jason Gunthorpe [this message]
2022-02-01 20:30         ` Bob Pearson
2022-02-01 18:20   ` kernel test robot
2022-01-31 22:08 ` [PATCH for-next v10 08/17] RDMA/rxe: Rename grp to mcg and mce to mca Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 09/17] RDMA/rxe: Introduce RXECB(skb) Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 10/17] RDMA/rxe: Split rxe_rcv_mcast_pkt into two phases Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 11/17] RDMA/rxe: Replace mcg locks by rxe->mcg_lock Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 12/17] RDMA/rxe: Replace pool key by rxe->mcg_tree Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 13/17] RDMA/rxe: Remove key'ed object support Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 14/17] RDMA/rxe: Remove mcg from rxe pools Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 15/17] RDMA/rxe: Add code to cleanup mcast memory Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 16/17] RDMA/rxe: Add comments to rxe_mcast.c Bob Pearson
2022-01-31 22:08 ` [PATCH for-next v10 17/17] RDMA/rxe: Finish cleanup of rxe_mcast.c Bob Pearson
2022-02-01 14:36 ` [PATCH for-next v10 00/17] Move two object pools to rxe_mcast.c Jason Gunthorpe

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=20220201201452.GO1786498@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=rpearsonhpe@gmail.com \
    --cc=zyjzyj2000@gmail.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).