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: <1a7190d4-f3ef-744c-4e46-8cb255dee6cf@amd.com>
Date: Mon, 7 Jul 2025 20:26:20 +0530
From: Abhijit Gangurde <abhijit.gangurde@....com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Jason Gunthorpe <jgg@...pe.ca>, shannon.nelson@....com,
 brett.creeley@....com, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, corbet@....net, andrew+netdev@...n.ch,
 allen.hubbe@....com, nikhil.agarwal@....com, linux-rdma@...r.kernel.org,
 netdev@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, Andrew Boyer <andrew.boyer@....com>
Subject: Re: [PATCH v3 10/14] RDMA/ionic: Register device ops for control path


On 7/7/25 12:51, Leon Romanovsky wrote:
> On Mon, Jul 07, 2025 at 10:57:13AM +0530, Abhijit Gangurde wrote:
>> On 7/4/25 22:38, Leon Romanovsky wrote:
>>> On Thu, Jul 03, 2025 at 12:49:30PM +0530, Abhijit Gangurde wrote:
>>>> On 7/2/25 23:30, Leon Romanovsky wrote:
>>>>> On Wed, Jul 02, 2025 at 10:18:03AM -0300, Jason Gunthorpe wrote:
>>>>>> On Tue, Jul 01, 2025 at 01:38:44PM +0300, Leon Romanovsky wrote:
>>>>>>>> +static void ionic_flush_qs(struct ionic_ibdev *dev)
>>>>>>>> +{
>>>>>>>> +	struct ionic_qp *qp, *qp_tmp;
>>>>>>>> +	struct ionic_cq *cq, *cq_tmp;
>>>>>>>> +	LIST_HEAD(flush_list);
>>>>>>>> +	unsigned long index;
>>>>>>>> +
>>>>>>>> +	/* Flush qp send and recv */
>>>>>>>> +	rcu_read_lock();
>>>>>>>> +	xa_for_each(&dev->qp_tbl, index, qp) {
>>>>>>>> +		kref_get(&qp->qp_kref);
>>>>>>>> +		list_add_tail(&qp->ibkill_flush_ent, &flush_list);
>>>>>>>> +	}
>>>>>>>> +	rcu_read_unlock();
>>>>>>> Same question as for CQ. What does RCU lock protect here?
>>>>>> It should protect the kref_get against free of qp. The qp memory must
>>>>>> be RCU freed.
>>>>> I'm not sure that this was intension here. Let's wait for an answer from the author.
>>>> As Jason mentioned, It was intended to protect the kref_get against free of
>>>> cq and qp
>>>> in the destroy path.
>>> How is it possible? IB/core is supposed to protect from accessing verbs
>>> resources post their release/destroy.
>>>
>>> After you answered what RCU is protecting, I don't see why you would
>>> have custom kref over QP/CQ/e.t.c objects.
>>>
>>> Thanks
>> The RCU protected kref here is making sure that all the hw events are
>> processed before destroy callback returns. Similarly, when driver is
>> going for ib_unregister_device, it is draining the pending WRs and events.
> I asked why do you have kref in first place? When ib_unregister_device
> is called all "pending MR" already supposed to be destroyed.
>
> Thansk

The custom kref on QP/CQ object is holding the completion for the 
destroy callback.
If any pending async hw events are being processed, destroy would wait 
on this completion
before it returns.

Thanks


Powered by blists - more mailing lists