lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 15 Jul 2020 17:42:33 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     "Zhu, Lingshan" <lingshan.zhu@...el.com>, mst@...hat.com,
        alex.williamson@...hat.com, pbonzini@...hat.com,
        sean.j.christopherson@...el.com, wanpengli@...cent.com
Cc:     virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
        netdev@...r.kernel.org, dan.daly@...el.com
Subject: Re: [PATCH 3/7] vhost_vdpa: implement IRQ offloading functions in
 vhost_vdpa


On 2020/7/15 下午5:20, Zhu, Lingshan wrote:
>>>>
>>>> I meant something like:
>>>>
>>>> unregister();
>>>> vq->call_ctx.producer.token = ctx;
>>>> register();
>>> This is what we are doing now, or I must missed somethig:
>>> if (ctx && ctx != token) {
>>>     irq_bypass_unregister_producer(&vq->call_ctx.producer);
>>>     vq->call_ctx.producer.token = ctx;
>>>     irq_bypass_register_producer(&vq->call_ctx.producer);
>>>
>>> }
>>>
>>> It just unregister and register.
>>
>>
>> I meant there's probably no need for the check and another check and 
>> unregister before. The whole function is as simple as I suggested above.
>>
>> Thanks
> IMHO we still need the checks, this function handles three cases:
> (1)if the ctx == token, we do nothing. For this unregister and register can work, but waste of time.


But we have a more simple code and we don't care about the performance 
here since the operations is rare.


> (2)if token exists but ctx is NULL, this means user space issued an unbind, so we need to only unregister the producer.


Note that the register/unregister have a graceful check of whether or 
not there's a token.


> (3)if ctx exists and ctx!=token, this means there is a new ctx, we need to update producer by unregister and register.
>
> I think we can not simply handle all these cases by "unregister and register".


So it looks to me the functions are equivalent.

Thanks


>
> Thanks,
> BR
> Zhu Lingshan

Powered by blists - more mailing lists