Prev: x86, paravirt: Add a global synchronization point for pvclock
Next: [PATCH] x86: KVM, fix lock imbalance
From: Jiri Slaby on 7 Jul 2010 09:10
On 07/07/2010 03:05 PM, Ingo Molnar wrote:
>
> * Jiri Slaby <jirislaby(a)gmail.com> wrote:
>
>> Stanse found that there is an omitted unlock in kvm_create_pit in one fail
>> path. Add proper unlock there.
>>
>> Signed-off-by: Jiri Slaby <jirislaby(a)gmail.com>
>> Cc: Avi Kivity <avi(a)redhat.com>
>> Cc: Marcelo Tosatti <mtosatti(a)redhat.com>
>> Cc: Thomas Gleixner <tglx(a)linutronix.de>
>> Cc: Ingo Molnar <mingo(a)redhat.com>
>> Cc: "H. Peter Anvin" <hpa(a)zytor.com>
>> Cc: x86(a)kernel.org
>> Cc: Gleb Natapov <gleb(a)redhat.com>
>> Cc: "Michael S. Tsirkin" <mst(a)redhat.com>
>> Cc: Gregory Haskins <ghaskins(a)novell.com>
>> Cc: kvm(a)vger.kernel.org
>> ---
>> arch/x86/kvm/i8254.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
>> index 467cc47..70db4d4 100644
>> --- a/arch/x86/kvm/i8254.c
>> +++ b/arch/x86/kvm/i8254.c
>> @@ -696,6 +696,7 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm, u32 flags)
>>
>> pit->wq = create_singlethread_workqueue("kvm-pit-wq");
>> if (!pit->wq) {
>> + mutex_unlock(&pit->pit_state.lock);
>> kfree(pit);
>> return NULL;
>> }
>
> A cleanliness comment: why is that tear-down/dealloc sequence open-coded? It
> should be at the end of the function, with goto labels, like we do it in
> similar cases.

Because the lock is around a block only. I usually don't create a goto
fail-paths in these cases. Do you want one?

thanks,
--
js
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 7 Jul 2010 09:10

* Jiri Slaby <jirislaby(a)gmail.com> wrote:

> Stanse found that there is an omitted unlock in kvm_create_pit in one fail
> path. Add proper unlock there.
>
> Signed-off-by: Jiri Slaby <jirislaby(a)gmail.com>
> Cc: Avi Kivity <avi(a)redhat.com>
> Cc: Marcelo Tosatti <mtosatti(a)redhat.com>
> Cc: Thomas Gleixner <tglx(a)linutronix.de>
> Cc: Ingo Molnar <mingo(a)redhat.com>
> Cc: "H. Peter Anvin" <hpa(a)zytor.com>
> Cc: x86(a)kernel.org
> Cc: Gleb Natapov <gleb(a)redhat.com>
> Cc: "Michael S. Tsirkin" <mst(a)redhat.com>
> Cc: Gregory Haskins <ghaskins(a)novell.com>
> Cc: kvm(a)vger.kernel.org
> ---
> arch/x86/kvm/i8254.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
> index 467cc47..70db4d4 100644
> --- a/arch/x86/kvm/i8254.c
> +++ b/arch/x86/kvm/i8254.c
> @@ -696,6 +696,7 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm, u32 flags)
>
> pit->wq = create_singlethread_workqueue("kvm-pit-wq");
> if (!pit->wq) {
> + mutex_unlock(&pit->pit_state.lock);
> kfree(pit);
> return NULL;
> }

A cleanliness comment: why is that tear-down/dealloc sequence open-coded? It
should be at the end of the function, with goto labels, like we do it in
similar cases.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Slaby on 7 Jul 2010 09:20
On 07/07/2010 03:07 PM, Jiri Slaby wrote:
>>> --- a/arch/x86/kvm/i8254.c
>>> +++ b/arch/x86/kvm/i8254.c
>>> @@ -696,6 +696,7 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm, u32 flags)
>>>
>>> pit->wq = create_singlethread_workqueue("kvm-pit-wq");
>>> if (!pit->wq) {
>>> + mutex_unlock(&pit->pit_state.lock);
>>> kfree(pit);
>>> return NULL;
>>> }
>>
>> A cleanliness comment: why is that tear-down/dealloc sequence open-coded? It
>> should be at the end of the function, with goto labels, like we do it in
>> similar cases.
>
> Because the lock is around a block only. I usually don't create a goto
> fail-paths in these cases.

To be more precise what I mean by that:
if ()
return;

lock();
....
if () { [single if inside the crit section]
unlock();
return;
}
....
unlock()

....
if ()
return;
....
if ()
return;

--
js
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 7 Jul 2010 09:30
On 07/07/2010 04:07 PM, Jiri Slaby wrote:
>
>> A cleanliness comment: why is that tear-down/dealloc sequence open-coded? It
>> should be at the end of the function, with goto labels, like we do it in
>> similar cases.
>>
> Because the lock is around a block only. I usually don't create a goto
> fail-paths in these cases. Do you want one?
>

In any case, the patch is a minimal fix, so I'll apply it. Any clean
ups can go on top.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 7 Jul 2010 10:20

* Avi Kivity <avi(a)redhat.com> wrote:

> On 07/07/2010 04:07 PM, Jiri Slaby wrote:
> >
> >>A cleanliness comment: why is that tear-down/dealloc sequence open-coded? It
> >>should be at the end of the function, with goto labels, like we do it in
> >>similar cases.
> >Because the lock is around a block only. I usually don't create a goto
> >fail-paths in these cases. Do you want one?
>
> In any case, the patch is a minimal fix, so I'll apply it. Any clean ups
> can go on top.

The reason the pattern caught my attention is that it is one of the typical
cases where goto labels help prevent similar bugs. I.e. had it been clean to
begin with the bug might not have happened.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: x86, paravirt: Add a global synchronization point for pvclock
Next: [PATCH] x86: KVM, fix lock imbalance