From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aosZZ-0004Fg-GC for qemu-devel@nongnu.org; Sat, 09 Apr 2016 09:05:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aosZU-00046o-Sw for qemu-devel@nongnu.org; Sat, 09 Apr 2016 09:05:09 -0400 Received: from [59.151.112.132] (port=1129 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aosZT-00045R-LF for qemu-devel@nongnu.org; Sat, 09 Apr 2016 09:05:04 -0400 References: <1459855602-16727-1-git-send-email-caoj.fnst@cn.fujitsu.com> <1459855602-16727-4-git-send-email-caoj.fnst@cn.fujitsu.com> <87a8l4tvry.fsf@dusky.pond.sub.org> From: Cao jin Message-ID: <5708FEA1.5070802@cn.fujitsu.com> Date: Sat, 9 Apr 2016 21:07:45 +0800 MIME-Version: 1.0 In-Reply-To: <87a8l4tvry.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 3/5] megasas: bugfix List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: mst@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, dmitry@daynix.com, alex.williamson@redhat.com, hare@suse.de, marcel@redhat.com, pbonzini@redhat.com, jsnow@redhat.com, kraxel@redhat.com On 04/08/2016 03:16 PM, Markus Armbruster wrote: > Please use a more descriptive title. Suggest "megasas: Fix > > Cao jin writes: > >> msi_init returns non-zero value on both failure and success > > This is a sentence, should end with a period. > > Bug's impact? Here's my guess. > > msi_init() either succeeds and returns 0x50, or fails and returns a > negative errno. If it succeeds, we mistakenly clear > MEGASAS_MASK_USE_MSI. Its only use is in megasas_scsi_uninit(), via > megasas_use_msi(). There, we fail to msi_uninit() on unrealize due to > the bug. > > I figure that's harmless if we destroy the device next. This is the > common case. > > If we don't destroy it, and then realize it again, msi_init() fails, FYI: if realize it again, I guess msi_init() won`t be executed again, because megasas_use_msi() will fail first. > because there's no space at 0x50: the MSI capability we neglected to > delete is still there. We report the problem to the user, then realize > the device anyway (I hate that, but it's a separate issue). > -- Yours Sincerely, Cao jin