Linux-RDMA Archive on lore.kernel.org
 help / color / Atom feed
From: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
To: Greg KH <greg@kroah.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
	dledford@redhat.com, linux-rdma@vger.kernel.org,
	Kaike Wan <kaike.wan@intel.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH for-rc 1/4] IB/hfi1: Call xa_destroy before freeing dummy_netdev
Date: Thu, 1 Apr 2021 10:02:30 -0400
Message-ID: <5d90f5b0-c161-bba7-5151-4d8a1c679b44@cornelisnetworks.com> (raw)
In-Reply-To: <YGVi7uT9kyfk7Mo7@kroah.com>

On 4/1/2021 2:06 AM, Greg KH wrote:
> On Wed, Mar 31, 2021 at 03:36:14PM -0400, Dennis Dalessandro wrote:
>> On 3/29/2021 10:09 AM, Jason Gunthorpe wrote:
>>> On Mon, Mar 29, 2021 at 09:48:17AM -0400, dennis.dalessandro@cornelisnetworks.com wrote:
>>>
>>>> diff --git a/drivers/infiniband/hw/hfi1/netdev_rx.c b/drivers/infiniband/hw/hfi1/netdev_rx.c
>>>> index 2c8bc02..cec02e8 100644
>>>> +++ b/drivers/infiniband/hw/hfi1/netdev_rx.c
>>>> @@ -372,7 +372,11 @@ int hfi1_netdev_alloc(struct hfi1_devdata *dd)
>>>>    void hfi1_netdev_free(struct hfi1_devdata *dd)
>>>>    {
>>>>    	if (dd->dummy_netdev) {
>>>> +		struct hfi1_netdev_priv *priv =
>>>> +			hfi1_netdev_priv(dd->dummy_netdev);
>>>> +
>>>>    		dd_dev_info(dd, "hfi1 netdev freed\n");
>>>> +		xa_destroy(&priv->dev_tbl);
>>>>    		kfree(dd->dummy_netdev);
>>>>    		dd->dummy_netdev = NULL;
>>>
>>> This is doing kfree() on a struct net_device?? Huh?
>>>
>>> You should have put this in your own struct and used container_of not
>>> co-oped netdev_priv, then free your own struct.
>>>
>>> It is a bit weird to see a xa_destroy like this, how did things get ot
>>> the point that no concurrent thread can see the xarray but there is
>>> still stuff stored in it?
>>>
>>> And it is weird this is storing two different types in it too, with no
>>> refcounting..
>>
>> We do rework this stuff in the other patch series.
>>
>> https://patchwork.kernel.org/project/linux-rdma/patch/1617026056-50483-11-git-send-email-dennis.dalessandro@cornelisnetworks.com/
>>
>> If we fix it up in the for-next series, what should we do about stable?
> 
> What does stable matter?  WHy can it not just take the same patches that
> end up in Linus's tree?

Guess it's more of a general question. What is the best way to handle 
things if the code changes drastically in Linus' tree, to the point 
where the bug no longer exists there, but does in stable?

-Denny

  reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29 13:48 [PATCH for-rc 0/4] hfi fixes dennis.dalessandro
2021-03-29 13:48 ` [PATCH for-rc 1/4] IB/hfi1: Call xa_destroy before freeing dummy_netdev dennis.dalessandro
2021-03-29 14:09   ` Jason Gunthorpe
2021-03-31 19:36     ` Dennis Dalessandro
2021-04-01  6:06       ` Greg KH
2021-04-01 14:02         ` Dennis Dalessandro [this message]
2021-04-01 14:12           ` Greg KH
2021-04-01 15:00             ` Dennis Dalessandro
2021-04-01 12:33       ` Jason Gunthorpe
2021-04-01 13:42         ` Wan, Kaike
2021-04-01 13:48           ` Jason Gunthorpe
2021-03-29 13:48 ` [PATCH for-rc 2/4] IB/hfi1: Call xa_destroy before unloading the module dennis.dalessandro
2021-03-29 14:11   ` Jason Gunthorpe
2021-04-08 13:30     ` Dennis Dalessandro
2021-03-29 13:48 ` [PATCH for-rc 3/4] IB/hfi1: Fix probe time panic when AIP is enabled with a buggy BIOS dennis.dalessandro
2021-04-07 23:04   ` Jason Gunthorpe
2021-03-29 13:48 ` [PATCH for-rc 4/4] IB/hfi1: Fix regressions in security fix dennis.dalessandro
2021-03-29 18:36   ` Ira Weiny
2021-04-07 18:33     ` Jason Gunthorpe
2021-04-07 20:20       ` Dennis Dalessandro
2021-04-13 22:55   ` 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=5d90f5b0-c161-bba7-5151-4d8a1c679b44@cornelisnetworks.com \
    --to=dennis.dalessandro@cornelisnetworks.com \
    --cc=dledford@redhat.com \
    --cc=greg@kroah.com \
    --cc=jgg@ziepe.ca \
    --cc=kaike.wan@intel.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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

Linux-RDMA Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-rdma/0 linux-rdma/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-rdma linux-rdma/ https://lore.kernel.org/linux-rdma \
		linux-rdma@vger.kernel.org
	public-inbox-index linux-rdma

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-rdma


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git