From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com ([134.134.136.100]:6386 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932476AbeE2KRC (ORCPT ); Tue, 29 May 2018 06:17:02 -0400 Subject: Re: [PATCH] mei: discard messages from not connected client during power down. To: Greg KH Cc: intel-gfx-trybot@lists.freedesktop.org, Alexander Usyskin , stable@vger.kernel.org References: <20180529085616.29820-1-martin.peres@linux.intel.com> <20180529090407.GA9530@kroah.com> From: Martin Peres Message-ID: Date: Tue, 29 May 2018 13:16:46 +0300 MIME-Version: 1.0 In-Reply-To: <20180529090407.GA9530@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 29/05/18 12:04, Greg KH wrote: > On Tue, May 29, 2018 at 11:56:16AM +0300, Martin Peres wrote: >> From: Alexander Usyskin >> >> This fixes regression introduced by >> commit 8d52af6795c0 ("mei: speed up the power down flow") >> >> In power down or suspend flow a message can still be received >> from the FW because the clients fake disconnection. >> In normal case we interpret messages w/o destination as corrupted >> and link reset is performed in order to clean the channel, >> but during power down link reset is already in progress resulting >> in endless loop. To resolve the issue under power down flow we >> discard messages silently. >> >> Cc: 4.16+ >> Fixes: 8d52af6795c0 ("mei: speed up the power down flow") >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199541 >> Signed-off-by: Alexander Usyskin >> Signed-off-by: Tomas Winkler >> --- >> drivers/misc/mei/interrupt.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) > > Shouldn't this patch go through the char/misc maintainer? > > confused, Sorry for the confusion. I actually tried to avoid this situation by not Cc:ing everyone, but git send-email did not prompt me to validate the final email after setting some of the --no-*-cc. Next time, I'll add --dry-run just to be sure... Anyway, what I was trying to do is submit this patch to our CI system since we were the ones reporting the bug. If successful, we will then apply this patch as a temporary workaround (our core-for-CI branch) to gather better statistics (reproducing rate is ~5% of our CI runs), and allow it to land upstream. We'll then drop our workaround when upstream with the fix gets backmerged in drm-tip. Sorry again for the noise! Martin