> -----Original Message----- > From: Linuxarm [mailto:linuxarm-bounces@xxxxxxxxxx] On Behalf Of Doug > Ledford > Sent: Tuesday, August 20, 2019 1:40 AM > To: Leon Romanovsky <leon@xxxxxxxxxx> > Cc: linux-rdma@xxxxxxxxxxxxxxx; Linuxarm <linuxarm@xxxxxxxxxx>; > jgg@xxxxxxxx > 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@xxxxxxxxxx> > GPG KeyID: B826A3330E572FDD > Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
