[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-pair



>>> On 12.02.19 at 12:26, <ian.jackson@xxxxxxxxxx> 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 <JBeulich@xxxxxxxx>
>>   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 <jbeulich@xxxxxxxx>
>>       Tested-by: Aaron Brown <aaron.f.brown@xxxxxxxxx>
>>       Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@xxxxxxxxx>
>>       Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
>> 
>> 
>> 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-admin@xxxxxxxxxxxxxx> 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 <JBeulich@xxxxxxxx>
>   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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.