On Wed, Apr 21, 2021 at 3:06 AM Rick Lindsley <rickl...@linux.vnet.ibm.com> wrote:
Please describe the advantage in deferring it further by routing it through do_hard_reset(). I don't see one.
On 4/21/21 10:12 PM, Lijun Pan replied:
It is not deferred. It exits with error and calls do_hard_reset. See my reply to Suka's.
I saw your reply, but it does not answer the question I asked. The patch would have us reinitialize and restart the communication queues. Your suggestion would do more work than that. Please describe the advantage in deferring the reinitialization - and yes, defer is the right word - by routing it through do_hard_reset() and executing that extra code. I see that route as doing more work than necessary and so introducing additional risk, for no clear advantage. So I would find it helpful if you would describe the advantage.
The testing was done on this patch. It was not performed on a full hard reset. So I don't think you could even compare the two results.
A problem has been noted, a patch has been proposed, and the reasoning that the patch is correct has been given. Testing with this patch has demonstrated the problem has not returned. So far, that sounds like a pretty reasonable solution. Your comment is curious - why would testing for this patch be done on a full hard reset when this patch does not invoke a full hard reset? If you have data to consider then let's have it. I'm willing to be convinced, but so far this just sounds like "I wouldn't do it that way myself, and I have a bad feeling about doing it any other way." Rick