>>> On 12.02.19 at 12:26, <ian.jack...@citrix.com> wrote:
> Jan, are you investigating this regression ?
No, I'm not. I've said what I can say in a reply to an earlier bisection
report (from Dec 12th), attached again here for reference.
Jan
> osstest service owner writes ("[linux-3.18 bisection] complete
> test-amd64-amd64-pair"):
>> branch xen-unstable
>> xenbranch xen-unstable
>> job test-amd64-amd64-pair
>> testid xen-boot/dst_host
>>
>> Tree: linux
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>> Tree: xen git://xenbits.xen.org/xen.git
>>
>> *** Found and reproduced problem changeset ***
>>
>> Bug is in tree: linux
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>> Bug introduced: 7b8052e19304865477e03a0047062d977309a22f
>> Bug not present: d255d18a34a8d53ccc4a019dc07e17b6e8cf6bd1
>> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/131278/
>>
>>
>> commit 7b8052e19304865477e03a0047062d977309a22f
>> Author: Jan Beulich <jbeul...@suse.com>
>> Date: Mon Oct 19 04:23:29 2015 -0600
>>
>> igb: fix NULL derefs due to skipped SR-IOV enabling
>>
>> [ Upstream commit be06998f96ecb93938ad2cce46c4289bf7cf45bc ]
>>
>> The combined effect of commits 6423fc3416 ("igb: do not re-init SR-IOV
>> during probe") and ceee3450b3 ("igb: make sure SR-IOV init uses the
>> right number of queues") causes VFs no longer getting set up, leading
>> to NULL pointer dereferences due to the adapter's ->vf_data being NULL
>> while ->vfs_allocated_count is non-zero. The first commit not only
>> neglected the side effect of igb_sriov_reinit() that the second commit
>> tried to account for, but also that of setting IGB_FLAG_HAS_MSIX,
>> without which igb_enable_sriov() is effectively a no-op. Calling
>> igb_{,re}set_interrupt_capability() as done here seems to address this,
>> but I'm not sure whether this is better than sinply reverting the other
>> two commits.
>>
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>> Tested-by: Aaron Brown <aaron.f.br...@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirs...@intel.com>
>> Signed-off-by: Sasha Levin <sas...@kernel.org>
>>
>>
>> For bisection revision-tuple graph see:
>>
> http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-am
> d64-amd64-pair.xen-boot--dst_host.html
>> Revision IDs in each graph node refer, respectively, to the Trees above.
--- Begin Message ---
>>> On 12.12.18 at 22:41, <osstest-ad...@xenproject.org> wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-pair
> testid xen-boot/src_host
>
> Tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
>
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Bug introduced: 7b8052e19304865477e03a0047062d977309a22f
> Bug not present: d255d18a34a8d53ccc4a019dc07e17b6e8cf6bd1
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/131278/
>
>
> commit 7b8052e19304865477e03a0047062d977309a22f
> Author: Jan Beulich <jbeul...@suse.com>
> Date: Mon Oct 19 04:23:29 2015 -0600
>
> igb: fix NULL derefs due to skipped SR-IOV enabling
_Very_ interesting. An over three years old commit was determined
to cause whatever regression it is. But wait - that's the date of the
mainline commit, not that of the backport (which was done a month
ago). I notice that of the two original commits the combination of
which the one here is supposed to fix, only one actually got
backported. Hence I wonder whether backporting the one here
was actually appropriate.
Jan
--- End Message ---
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel