From: liweihang <liweihang@hisilicon.com>
To: Doug Ledford <dledford@redhat.com>, Leon Romanovsky <leon@kernel.org>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>, "jgg@ziepe.ca" <jgg@ziepe.ca>
Subject: RE: [PATCH for-next 3/9] RDMA/hns: Completely release qp resources when hw err
Date: Tue, 8 Oct 2019 08:43:02 +0000 [thread overview]
Message-ID: <B82435381E3B2943AA4D2826ADEF0B3A020DA8C3@DGGEML522-MBX.china.huawei.com> (raw)
In-Reply-To: <3d51b645485b861ff7b20108c638de37e29b4c0f.camel@redhat.com>
> -----Original Message-----
> From: Linuxarm [mailto:linuxarm-bounces@huawei.com] On Behalf Of Doug
> Ledford
> Sent: Tuesday, August 20, 2019 1:40 AM
> To: Leon Romanovsky <leon@kernel.org>
> Cc: linux-rdma@vger.kernel.org; Linuxarm <linuxarm@huawei.com>;
> jgg@ziepe.ca
> Subject: Re: [PATCH for-next 3/9] RDMA/hns: Completely release qp
> resources when hw err
>
> On Wed, 2019-08-14 at 21:47 +0300, Leon Romanovsky wrote:
> > On Wed, Aug 14, 2019 at 11:05:04AM -0400, Doug Ledford wrote:
> > > On Wed, 2019-08-14 at 14:02 +0800, Yangyang Li wrote:
> > > > > I don't know your hardware, but this patch sounds
> > > > > wrong/dangerous to me.
> > > > > As long as the resources this card might access are allocated by
> > > > > the kernel, you can't get random data corruption by the card
> > > > > writing to memory used elsewhere in the kernel. So if your card
> > > > > is not responding to your requests to free the resources, it
> > > > > would seem safer to leak those resources permanently than to
> > > > > free them and risk the card coming back to life long enough to
> > > > > corrupt memory reallocated to some other task.
> > > > >
> > > > > Only if you can guarantee me that there is no way your commands
> > > > > to the card will fail and then the card start working again
> > > > > later would I consider this patch safe. And if it's possible
> > > > > for the card to hang like this, should that be triggering a
> > > > > reset of the device?
> > > > >
> > > >
> > > > Thanks for your suggestion, I agree with you, it would seem safer
> > > > to leak those resources permanently than to free them. I will
> > > > abandon this change and consider cleaning up these leaked
> > > > resources during uninstallation or reset.
> > >
> > > Ok, patch dropped from patchworks, thanks.
> >
> > Sorry for being late, but I don't like the idea of having leaked
> > memory.
> >
> > All my allocation patches are actually trying to avoid such situation
> > by ensuring that no driver does crazy stuff like this. It means that
> > once I'll have time to work on QP allocations, I'll ensure that memory
> > is freed, so it is better to free such memory now.
>
> You can't free something if the card might still access it. A leak is always
> preferable to data corruption.
>
Hi Doug,
We can confirm that hip08 hardware won't start working again when failed
to destroy after considering all possible situations. So it is safe to free qp
resources even if the destroy command failed executed. I will resend this
patch to avoid memory leaks as Jason asked.
Thanks,
Weihang
> --
> Doug Ledford <dledford@redhat.com>
> GPG KeyID: B826A3330E572FDD
> Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
next prev parent reply other threads:[~2019-10-08 8:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-09 9:40 [PATCH for-next 0/9] Bugfixes for 5.3-rc2 Lijun Ou
2019-08-09 9:40 ` [PATCH for-next 1/9] RDMA/hns: Logic optimization of wc_flags Lijun Ou
2019-08-09 9:40 ` [PATCH for-next 2/9] RDMA/hns: Bugfix for creating qp attached to srq Lijun Ou
2019-08-12 15:29 ` Doug Ledford
2019-08-09 9:41 ` [PATCH for-next 3/9] RDMA/hns: Completely release qp resources when hw err Lijun Ou
2019-08-12 15:29 ` Doug Ledford
2019-08-14 6:02 ` Yangyang Li
2019-08-14 15:05 ` Doug Ledford
2019-08-14 18:47 ` Leon Romanovsky
2019-08-19 17:39 ` Doug Ledford
2019-10-08 8:43 ` liweihang [this message]
2019-08-09 9:41 ` [PATCH for-next 4/9] RDMA/hns: Modify pi vlaue when cq overflows Lijun Ou
2019-08-09 9:41 ` [PATCH for-next 5/9] RDMA/hns: Bugfix for slab-out-of-bounds when unloading hip08 driver Lijun Ou
2019-08-09 9:41 ` [PATCH for-next 6/9] RDMA/hns: bugfix for slab-out-of-bounds when loading " Lijun Ou
2019-08-09 9:41 ` [PATCH for-next 7/9] RDMA/hns: Remove unuseful member Lijun Ou
2019-08-09 9:41 ` [PATCH for-next 8/9] RDMA/hns: Kernel notify usr space to stop ring db Lijun Ou
2019-08-12 5:52 ` Leon Romanovsky
2019-08-12 13:14 ` Jason Gunthorpe
2019-08-14 5:54 ` Yangyang Li
2019-08-09 9:41 ` [PATCH for-next 9/9] RDMA/hns: Copy some information of AV to user Lijun Ou
2019-10-21 17:23 ` Doug Ledford
2019-10-22 1:13 ` oulijun
2019-08-13 16:34 ` [PATCH for-next 0/9] Bugfixes for 5.3-rc2 Doug Ledford
2019-08-24 6:23 ` oulijun
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=B82435381E3B2943AA4D2826ADEF0B3A020DA8C3@DGGEML522-MBX.china.huawei.com \
--to=liweihang@hisilicon.com \
--cc=dledford@redhat.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linuxarm@huawei.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).