Skip to contentSkip to conversation

drivers/xen/evtchn.c: Check failure for evtchn_make_refcounted()

PATCH In review Chen Gang 2 participants 9 messages Aug 28, 2014 – Aug 30, 2014 Xen hypervisor interface

lore
Share & tools
lore

Chen Gang

author
#0 lore raw

PATCH 1/1 drivers/xen/evtchn.c: Check failure for evtchn_make_refcounted()

evtchn_make_refcounted() may return failure, so need process the failure case. In failure case, it need call unbind_from_irqhandler() just like evtchn_unbind_from_user() has done.

irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed, so need not check it again.

Also still need remain the closing port code, because when the failure occurs, unbind_from_irqhandler() will not close port internally.

Signed-off-by Chen Gang <[email protected]>
---
 drivers/xen/evtchn.c | 5 +++++
 1 file changed, 5 insertions(+)
drivers/xen/evtchn.c +5 -0
index 00f40f0..8a629d6 100644
@@ -311,6 +311,11 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
 		goto err;
 
 	rc = evtchn_make_refcounted(port);
+	if (rc < 0) {
+		unbind_from_irqhandler(irq_from_evtchn(port), evtchn);
+		goto err;
+	}
+
 	return rc;
 
 err:
Signature · 1 line
1.7.11.7
#1 lore raw
Quoted 9 lines · Chen Gang

evtchn_make_refcounted() may return failure, so need process the failure case. In failure case, it need call unbind_from_irqhandler() just like evtchn_unbind_from_user() has done.

irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed, so need not check it again.

Also still need remain the closing port code, because when the failure occurs, unbind_from_irqhandler() will not close port internally.

None of the evtchn_make_refcounted() failures can occur since we know we have a valid irq and info at the single call site.

I would like to see this fixed by refactoring the code to remove evtchn_make_refcounted() by making all irqs for event channels reference counted. These no need for this refcounting to be optional.

David

#8 lore raw
In reply to Chen Gang
Quoted 9 lines · Chen Gang

evtchn_make_refcounted() may return failure, so need process the failure case. In failure case, it need call unbind_from_irqhandler() just like evtchn_unbind_from_user() has done.

irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed, so need not check it again.

Also still need remain the closing port code, because when the failure occurs, unbind_from_irqhandler() will not close port internally.

None of the evtchn_make_refcounted() failures can occur since we know we have a valid irq and info at the single call site.

I would like to see this fixed by refactoring the code to remove evtchn_make_refcounted() by making all irqs for event channels reference counted. These no need for this refcounting to be optional.

David

author
#2 lore raw
In reply to David Vrabel
Quoted 5 lines · David Vrabel
Quoted 4 lines · Chen Gang

evtchn_make_refcounted() may return failure, so need process the failure case. In failure case, it need call unbind_from_irqhandler() just like evtchn_unbind_from_user() has done.

Quoted 9 lines
Quoted 5 lines

irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed, so need not check it again.

Also still need remain the closing port code, because when the failure occurs, unbind_from_irqhandler() will not close port internally.

None of the evtchn_make_refcounted() failures can occur since we know we have a valid irq and info at the single call site.

OK, thanks. I guess what you said is correct.

But only according to the code, for me, I am not quite sure about 'info' must be always valid. If bind_evtchn_to_irqhandler() succeeds, I can not find any related code to prove 'info' must be valid.

- for a new irq, it will allocate 'info' for it.

- but for an existing irq, the code assumes it may has no 'info'. (so several areas check 'info' whether valid, although irq is OK).

So could you give some additional related proofs for it? And if 'info' must be always OK, can we remove all the related check about 'info'?

Quoted 4 lines

I would like to see this fixed by refactoring the code to remove evtchn_make_refcounted() by making all irqs for event channels reference counted. These no need for this refcounting to be optional.

If 'info' really must always be valid, what you said sounds reasonable to me.

Thanks

Signature · 3 lines
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
author
#7 lore raw
In reply to David Vrabel
Quoted 5 lines · David Vrabel
Quoted 4 lines · Chen Gang

evtchn_make_refcounted() may return failure, so need process the failure case. In failure case, it need call unbind_from_irqhandler() just like evtchn_unbind_from_user() has done.

Quoted 9 lines
Quoted 5 lines

irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed, so need not check it again.

Also still need remain the closing port code, because when the failure occurs, unbind_from_irqhandler() will not close port internally.

None of the evtchn_make_refcounted() failures can occur since we know we have a valid irq and info at the single call site.

OK, thanks. I guess what you said is correct.

But only according to the code, for me, I am not quite sure about 'info' must be always valid. If bind_evtchn_to_irqhandler() succeeds, I can not find any related code to prove 'info' must be valid.

- for a new irq, it will allocate 'info' for it.

- but for an existing irq, the code assumes it may has no 'info'. (so several areas check 'info' whether valid, although irq is OK).

So could you give some additional related proofs for it? And if 'info' must be always OK, can we remove all the related check about 'info'?

Quoted 4 lines

I would like to see this fixed by refactoring the code to remove evtchn_make_refcounted() by making all irqs for event channels reference counted. These no need for this refcounting to be optional.

If 'info' really must always be valid, what you said sounds reasonable to me.

Thanks

Signature · 3 lines
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
#3 lore raw
In reply to Chen Gang
Quoted 24 lines · Chen Gang
Quoted 5 lines · David Vrabel
Quoted 4 lines · Chen Gang

evtchn_make_refcounted() may return failure, so need process the failure case. In failure case, it need call unbind_from_irqhandler() just like evtchn_unbind_from_user() has done.

Quoted 9 lines
Quoted 5 lines

irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed, so need not check it again.

Also still need remain the closing port code, because when the failure occurs, unbind_from_irqhandler() will not close port internally.

None of the evtchn_make_refcounted() failures can occur since we know we have a valid irq and info at the single call site.

OK, thanks. I guess what you said is correct.

But only according to the code, for me, I am not quite sure about 'info' must be always valid. If bind_evtchn_to_irqhandler() succeeds, I can not find any related code to prove 'info' must be valid.

Quoted 7 lines

- for a new irq, it will allocate 'info' for it.

- but for an existing irq, the code assumes it may has no 'info'. (so several areas check 'info' whether valid, although irq is OK).

So could you give some additional related proofs for it? And if 'info' must be always OK, can we remove all the related check about 'info'?

I'm not sure what you mean by an existing irq. If it's an irq for an event channel it will have had info set when it was allocated. the irq_mapping_update_lock protects against seeing partially setup irqs.

So, the checks for !info can be removed, yes.

David

#6 lore raw
In reply to Chen Gang
Quoted 24 lines · Chen Gang
Quoted 5 lines · David Vrabel
Quoted 4 lines · Chen Gang

evtchn_make_refcounted() may return failure, so need process the failure case. In failure case, it need call unbind_from_irqhandler() just like evtchn_unbind_from_user() has done.

Quoted 9 lines
Quoted 5 lines

irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed, so need not check it again.

Also still need remain the closing port code, because when the failure occurs, unbind_from_irqhandler() will not close port internally.

None of the evtchn_make_refcounted() failures can occur since we know we have a valid irq and info at the single call site.

OK, thanks. I guess what you said is correct.

But only according to the code, for me, I am not quite sure about 'info' must be always valid. If bind_evtchn_to_irqhandler() succeeds, I can not find any related code to prove 'info' must be valid.

Quoted 7 lines

- for a new irq, it will allocate 'info' for it.

- but for an existing irq, the code assumes it may has no 'info'. (so several areas check 'info' whether valid, although irq is OK).

So could you give some additional related proofs for it? And if 'info' must be always OK, can we remove all the related check about 'info'?

I'm not sure what you mean by an existing irq. If it's an irq for an event channel it will have had info set when it was allocated. the irq_mapping_update_lock protects against seeing partially setup irqs.

So, the checks for !info can be removed, yes.

David

author
#4 lore raw
In reply to David Vrabel
Quoted 30 lines · David Vrabel
Quoted 29 lines · Chen Gang
Quoted 5 lines · David Vrabel
Quoted 4 lines · Chen Gang

evtchn_make_refcounted() may return failure, so need process the failure case. In failure case, it need call unbind_from_irqhandler() just like evtchn_unbind_from_user() has done.

Quoted 9 lines
Quoted 5 lines

irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed, so need not check it again.

Also still need remain the closing port code, because when the failure occurs, unbind_from_irqhandler() will not close port internally.

None of the evtchn_make_refcounted() failures can occur since we know we have a valid irq and info at the single call site.

OK, thanks. I guess what you said is correct.

But only according to the code, for me, I am not quite sure about 'info' must be always valid. If bind_evtchn_to_irqhandler() succeeds, I can not find any related code to prove 'info' must be valid.

- for a new irq, it will allocate 'info' for it.

- but for an existing irq, the code assumes it may has no 'info'. (so several areas check 'info' whether valid, although irq is OK).

Quoted 7 lines
Quoted 2 lines

So could you give some additional related proofs for it? And if 'info' must be always OK, can we remove all the related check about 'info'?

I'm not sure what you mean by an existing irq. If it's an irq for an event channel it will have had info set when it was allocated. the irq_mapping_update_lock protects against seeing partially setup irqs.

After check the code details again. I guess, really no "existing irq", just like you said.

But in honest, only based on the code, for me, it is not quite clear ( I guess it is OK, but I am not sure it must be OK -- still worry about it).

Quoted 2 lines

So, the checks for !info can be removed, yes.

So for me, for safety (also easy understanding) reason, I still prefer my original patch, although it is not the best one.

If you are sure about it (I guess you are sure), please help send patch for it (skip checking "!info"). If necessary, may mark Cc or Reported-by to me.

Thanks.

Signature · 3 lines
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
author
#5 lore raw
In reply to David Vrabel
Quoted 30 lines · David Vrabel
Quoted 29 lines · Chen Gang
Quoted 5 lines · David Vrabel
Quoted 4 lines · Chen Gang

evtchn_make_refcounted() may return failure, so need process the failure case. In failure case, it need call unbind_from_irqhandler() just like evtchn_unbind_from_user() has done.

Quoted 9 lines
Quoted 5 lines

irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed, so need not check it again.

Also still need remain the closing port code, because when the failure occurs, unbind_from_irqhandler() will not close port internally.

None of the evtchn_make_refcounted() failures can occur since we know we have a valid irq and info at the single call site.

OK, thanks. I guess what you said is correct.

But only according to the code, for me, I am not quite sure about 'info' must be always valid. If bind_evtchn_to_irqhandler() succeeds, I can not find any related code to prove 'info' must be valid.

- for a new irq, it will allocate 'info' for it.

- but for an existing irq, the code assumes it may has no 'info'. (so several areas check 'info' whether valid, although irq is OK).

Quoted 7 lines
Quoted 2 lines

So could you give some additional related proofs for it? And if 'info' must be always OK, can we remove all the related check about 'info'?

I'm not sure what you mean by an existing irq. If it's an irq for an event channel it will have had info set when it was allocated. the irq_mapping_update_lock protects against seeing partially setup irqs.

After check the code details again. I guess, really no "existing irq", just like you said.

But in honest, only based on the code, for me, it is not quite clear ( I guess it is OK, but I am not sure it must be OK -- still worry about it).

Quoted 2 lines

So, the checks for !info can be removed, yes.

So for me, for safety (also easy understanding) reason, I still prefer my original patch, although it is not the best one.

If you are sure about it (I guess you are sure), please help send patch for it (skip checking "!info"). If necessary, may mark Cc or Reported-by to me.

Thanks.

Signature · 3 lines
Chen Gang

Open, share, and attitude like air, water, and life which God blessed