From: Leon Romanovsky <leon@kernel.org>
To: Doug Ledford <dledford@redhat.com>
Cc: Yangyang Li <liyangyang20@huawei.com>,
Lijun Ou <oulijun@huawei.com>,
jgg@ziepe.ca, linux-rdma@vger.kernel.org, linuxarm@huawei.com
Subject: Re: [PATCH for-next 3/9] RDMA/hns: Completely release qp resources when hw err
Date: Wed, 14 Aug 2019 21:47:37 +0300 [thread overview]
Message-ID: <20190814184737.GB5893@mtr-leonro.mtl.com> (raw)
In-Reply-To: <f1609a31d9b0d1cdc3b2db38dda1543126755007.camel@redhat.com>
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.
Thanks
>
> --
> 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-08-14 18:47 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 [this message]
2019-08-19 17:39 ` Doug Ledford
2019-10-08 8:43 ` liweihang
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=20190814184737.GB5893@mtr-leonro.mtl.com \
--to=leon@kernel.org \
--cc=dledford@redhat.com \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liyangyang20@huawei.com \
--cc=oulijun@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).