xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org
Subject: [xen-unstable-smoke bisection] complete build-amd64
Date: Tue, 10 Nov 2020 23:25:24 +0000	[thread overview]
Message-ID: <E1kcd0u-00047b-VZ@osstest.test-lab.xenproject.org> (raw)

branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build

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:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  5f2df45ead7c1195142f68b7923047a1e9479d54
  Bug not present: 3059178798a23ba870ff86ff54d442a07e6651fc
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/156660/


  commit 5f2df45ead7c1195142f68b7923047a1e9479d54
  Author: Juergen Gross <jgross@suse.com>
  Date:   Tue Nov 10 14:36:15 2020 +0100
  
      xen/evtchn: rework per event channel lock
      
      Currently the lock for a single event channel needs to be taken with
      interrupts off, which causes deadlocks in some cases.
      
      Rework the per event channel lock to be non-blocking for the case of
      sending an event and removing the need for disabling interrupts for
      taking the lock.
      
      The lock is needed for avoiding races between event channel state
      changes (creation, closing, binding) against normal operations (set
      pending, [un]masking, priority changes).
      
      Use a rwlock, but with some restrictions:
      
      - Changing the state of an event channel (creation, closing, binding)
        needs to use write_lock(), with ASSERT()ing that the lock is taken as
        writer only when the state of the event channel is either before or
        after the locked region appropriate (either free or unbound).
      
      - Sending an event needs to use read_trylock() mostly, in case of not
        obtaining the lock the operation is omitted. This is needed as
        sending an event can happen with interrupts off (at least in some
        cases).
      
      - Dumping the event channel state for debug purposes is using
        read_trylock(), too, in order to avoid blocking in case the lock is
        taken as writer for a long time.
      
      - All other cases can use read_lock().
      
      Fixes: e045199c7c9c54 ("evtchn: address races with evtchn_reset()")
      Signed-off-by: Juergen Gross <jgross@suse.com>
      Reviewed-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Julien Grall <jgrall@amazon.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build --summary-out=tmp/156660.bisection-summary --basis-template=156622 --blessings=real,real-bisect,real-retry xen-unstable-smoke build-amd64 xen-build
Searching for failure / basis pass:
 156642 fail [host=himrod1] / 156622 [host=himrod2] 156532 [host=himrod2] 156523 ok.
Failure / basis pass flights: 156642 / 156523
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
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
Latest 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 628e1becb6fb121475a6ce68e3f1cb4499851255
Basis pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 2a5f9f6a6932214fda76b9b3c03e024772882d34
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#677cbe1324c29294bb1d1b8454b3f214725e40fd-7ea428895af2840d85c524f0bd11a38aac308308 git://xenbits.xen.org/xen.git#2a5f9f6a6932214fda76b9b3c03e024772882d34-628e1becb6fb121475a6ce68e3f1cb4499851255
Loaded 10007 nodes in revision graph
Searching for test results:
 156523 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 2a5f9f6a6932214fda76b9b3c03e024772882d34
 156532 [host=himrod2]
 156622 [host=himrod2]
 156628 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 e6e85b662be9eab96f4cfc58e9945580cce8b2bb
 156641 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 2a5f9f6a6932214fda76b9b3c03e024772882d34
 156644 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 e6e85b662be9eab96f4cfc58e9945580cce8b2bb
 156647 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
 156650 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 b5ad37f8e9284cc147218f7a5193d739ae7b956f
 156652 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 3059178798a23ba870ff86ff54d442a07e6651fc
 156654 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 5f2df45ead7c1195142f68b7923047a1e9479d54
 156642 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 628e1becb6fb121475a6ce68e3f1cb4499851255
 156655 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 3059178798a23ba870ff86ff54d442a07e6651fc
 156657 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 5f2df45ead7c1195142f68b7923047a1e9479d54
 156658 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 3059178798a23ba870ff86ff54d442a07e6651fc
 156660 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 5f2df45ead7c1195142f68b7923047a1e9479d54
Searching for interesting versions
 Result found: flight 156523 (pass), for basis pass
 For basis failure, parent search stopping at 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 3059178798a23ba870ff86ff54d442a07e6651fc, results HASH(0x55985838a5c8) HASH(0x559858388d40) HASH(0x55985838df78) For basis failure, parent search stopping at 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258, results HASH(0x559858385030) For basis failure, parent search stopping at 3d273dd05e51e5a1\
 ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 2a5f9f6a6932214fda76b9b3c03e024772882d34, results HASH(0x55985837a3b8) HASH(0x559858372e78) Result found: flight 156628 (fail), for basis failure (at ancestor ~531)
 Repro found: flight 156641 (pass), for basis pass
 Repro found: flight 156642 (fail), for basis failure
 0 revisions at 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 3059178798a23ba870ff86ff54d442a07e6651fc
No revisions left to test, checking graph state.
 Result found: flight 156652 (pass), for last pass
 Result found: flight 156654 (fail), for first failure
 Repro found: flight 156655 (pass), for last pass
 Repro found: flight 156657 (fail), for first failure
 Repro found: flight 156658 (pass), for last pass
 Repro found: flight 156660 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  5f2df45ead7c1195142f68b7923047a1e9479d54
  Bug not present: 3059178798a23ba870ff86ff54d442a07e6651fc
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/156660/


  commit 5f2df45ead7c1195142f68b7923047a1e9479d54
  Author: Juergen Gross <jgross@suse.com>
  Date:   Tue Nov 10 14:36:15 2020 +0100
  
      xen/evtchn: rework per event channel lock
      
      Currently the lock for a single event channel needs to be taken with
      interrupts off, which causes deadlocks in some cases.
      
      Rework the per event channel lock to be non-blocking for the case of
      sending an event and removing the need for disabling interrupts for
      taking the lock.
      
      The lock is needed for avoiding races between event channel state
      changes (creation, closing, binding) against normal operations (set
      pending, [un]masking, priority changes).
      
      Use a rwlock, but with some restrictions:
      
      - Changing the state of an event channel (creation, closing, binding)
        needs to use write_lock(), with ASSERT()ing that the lock is taken as
        writer only when the state of the event channel is either before or
        after the locked region appropriate (either free or unbound).
      
      - Sending an event needs to use read_trylock() mostly, in case of not
        obtaining the lock the operation is omitted. This is needed as
        sending an event can happen with interrupts off (at least in some
        cases).
      
      - Dumping the event channel state for debug purposes is using
        read_trylock(), too, in order to avoid blocking in case the lock is
        taken as writer for a long time.
      
      - All other cases can use read_lock().
      
      Fixes: e045199c7c9c54 ("evtchn: address races with evtchn_reset()")
      Signed-off-by: Juergen Gross <jgross@suse.com>
      Reviewed-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Julien Grall <jgrall@amazon.com>

Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
156660: tolerable ALL FAIL

flight 156660 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/156660/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-amd64                   6 xen-build               fail baseline untested


jobs:
 build-amd64                                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary



             reply	other threads:[~2020-11-10 23:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10 23:25 osstest service owner [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-11-28 17:02 [xen-unstable-smoke bisection] complete build-amd64 osstest service owner
2023-09-06 16:46 osstest service owner
2023-06-07 16:24 osstest service owner
2023-03-24 22:28 osstest service owner
2022-10-16  8:24 osstest service owner
2022-03-15  2:25 osstest service owner
2022-01-21  3:38 osstest service owner
2022-01-21  7:54 ` Jan Beulich
2021-08-16 23:23 osstest service owner
2021-07-10  0:19 osstest service owner
2021-07-06 17:29 osstest service owner
2021-02-24 16:57 osstest service owner
2021-02-10 19:10 osstest service owner
2021-01-28 18:38 osstest service owner
2020-12-21 20:07 osstest service owner
2020-10-23 23:30 osstest service owner
2020-10-07 18:40 osstest service owner
2020-04-25  8:57 osstest service owner
2019-05-15  8:13 osstest service owner
2019-04-13  5:09 osstest service owner
2019-04-13 15:51 ` Julien Grall
2019-04-13 15:53   ` Andrew Cooper
2019-01-02 21:14 osstest service owner
2018-11-12 23:38 osstest service owner
2018-09-25 21:39 osstest service owner
2018-04-07  6:19 osstest service owner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1kcd0u-00047b-VZ@osstest.test-lab.xenproject.org \
    --to=osstest-admin@xenproject.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).