Skip to content

acrn-config: scenario setting UI with xsd schema config#10

Open
szhen11 wants to merge 1 commit intojunjiemao1:config_schemafrom
szhen11:xsd_ui
Open

acrn-config: scenario setting UI with xsd schema config#10
szhen11 wants to merge 1 commit intojunjiemao1:config_schemafrom
szhen11:xsd_ui

Conversation

@szhen11
Copy link

@szhen11 szhen11 commented Jan 19, 2021

render scenario setting UI with xsd schema config, validate scenario
setting with xsd validation.

Signed-off-by: Shuang Zheng shuang.zheng@intel.com

Flask==1.1.1
flask_bootstrap==3.3.7.1

xmlschema==1.3.1
Copy link
Owner

@junjiemao1 junjiemao1 Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latest xmlschema library is 1.4.1. Shall we use that?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I will update it to version 1.4.1

render scenario setting UI with xsd schema config, validate scenario
setting with xsd validation.

Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
junjiemao1 pushed a commit that referenced this pull request Feb 24, 2022
 'mevent_lmutex' is initialized as default type,
 while attempting to recursively lock on this
 kind of mutext results in undefined behaviour.

 Recursively lock on 'mevent_lmutex' can be detected
 in mevent thread when user tries to trigger system
 reset from user VM, in this case, user VM reboot hang.

 The backtrace for this issue:
  #1 in mevent_qlock () at core/mevent.c:93
  #2 in mevent_delete_even at core/mevent.c:357
    ===>Recursively LOCK
  #3 in mevent_delete_close at core/mevent.c:387
  #4 in acrn_timer_deinit at core/timer.c:106
  #5 in virtio_reset_dev at hw/pci/virtio/virtio.c:171
  #6 in virtio_console_reset at
     hw/pci/virtio/virtio_console.c:196
  #7 in virtio_console_destroy at
    hw/pci/virtio/virtio_console.c:1015
  #8 in virtio_console_teardown_backend at
    hw/pci/virtio/virtio_console.c:1042
  #9 in mevent_drain_del_list () at
    core/mevent.c:348 ===> 1st LOCK
  #10 in mevent_dispatch () at core/mevent.c:472
  #11 in main at core/main.c:1110

  So the root cause is:
  mevent_mutex lock is recursively locked by mevent thread
  itself (#9 for this first lock and #2 for recursively lock),
  which is not allowed for mutex with default attribute.

  This patch changes the mutex type of 'mevent_lmutex'
  from default to "PTHREAD_MUTEX_RECURSIVE", because
  recrusively lock shall be allowed as user of mevent
  may call mevent functions (where mutex lock maybe required)
  in teardown callbacks.

Tracked-On: projectacrn#7133
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants