[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] xen: rework error handling in vcpu_create
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
- Date: Mon, 4 Aug 2025 12:57:57 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fqGMlBKs+3cFuk9MO5pxVLxWp7p4+e30DX/UL1qUw1Y=; b=hJr2FV3mRKBLdKCsdnnyo//EL9zCzitTWoJOXccnnL6T1RwvoFrk5oCu1MZHD4i1oaXDzs/b7c+O2kBWmVB4zGtjy7ZG9rd4c2uGN5KOywJoe5+donCigYyHqph0IbxgusLi9Y/a6cyD6/Kr0i4mhPR/CcP3/ki2QalHrQDlHpYXw2ItrqHMLNa7nRQll6zfTU7Ck54197EWp+wEmt5RI5m4gOZp0fZDjz4iEiWgXOPdcWSxQ5I8r7Nj5BPIZOs/tOWGH7kRQWj5/GbmClXkSJRexnq3uoEiaZ+ZnZDg7ezWe5YAzwUY9FCA+OL0JZ8TnLvUDTHTb+PTVcokiEptFg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Q4bXGrT9+WF+39WDztp2o6qOtEhc+1seR95vCfuZbL6/LBK55HgmhVoAno5OtCrTcu2vE2AsckvP6U7PalN4ImceQ0sSCdnoztRkS+e3xQYthyERelYrXmByODVCeoVaRA07HwTCzyIBQsPJR7Ae7LeZ4Uq9KA2MH55hZtagPRmweBF69Wnoc/pQAQKM8DjXWy8DD71EZzKQelON++EUBKSuumbesHEfNyQmynu4tLWsp+2gEPStlmT2LP0GO/CTdlfRRHcHMFISWwsUQn1RiAiCTcBtziGUVECrkDwBfZ10GZ2V7QyzYQvWM25z5LCo/X0psqMxHV+VcU4Q8J9irw==
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, "Julien Grall" <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "Dario Faggioli" <dfaggioli@xxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, George Dunlap <gwd@xxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 04 Aug 2025 16:58:27 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 8/4/25 03:57, Jan Beulich wrote:
> On 01.08.2025 22:24, Stewart Hildebrand wrote:
>> @@ -839,6 +839,9 @@ void sched_destroy_vcpu(struct vcpu *v)
>> {
>> struct sched_unit *unit = v->sched_unit;
>>
>> + if ( !unit )
>> + return;
>> +
>> kill_timer(&v->periodic_timer);
>> kill_timer(&v->singleshot_timer);
>> kill_timer(&v->poll_timer);
>
> What if it's the 2nd error path in sched_init_vcpu() that is taken? Then we
> might take this path (just out of context here)
>
> if ( unit->vcpu_list == v )
> {
> rcu_read_lock(&sched_res_rculock);
>
> sched_remove_unit(vcpu_scheduler(v), unit);
> sched_free_udata(vcpu_scheduler(v), unit->priv);
>
> and at least Credit1's hook doesn't look to be safe against being passed NULL.
> (Not to speak of the risk of unit->priv being used elsewhere while cleaning
> up.)
>
> Jan
Are you referring to this error path in sched_init_vcpu?
unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
if ( unit->priv == NULL )
{
sched_free_unit(unit, v);
rcu_read_unlock(&sched_res_rculock);
return 1;
}
If so, my understanding is that sched_free_unit sets
v->sched_unit = NULL, so sched_destroy_vcpu (with this patch applied)
would return before reaching that just-out-of-context condition.
Albeit I have not yet tested this with any sort of non-default
scheduling granularity, so I could have missed something...
|
