Re: [KVM-RFC PATCH 1/2] eventfd: add an explicit srcu based notifierinterface

[Gregory Haskins]

Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 12:17:22PM -0400, Gregory Haskins wrote:
>   
>>> Maybe I misunderstand what iosignalfd is - isn't it true that you get eventfd
>>> and kvm will signal that when guest performs io write to a specific
>>> address, and then drivers can get eventfd and poll it to detect
>>> these writes?
>>>   
>>>       
>> Correct.
>>
>>     
>>> If yes, you have no way to know that the other end of eventfd
>>> is connected to kvm, so you don't know you can access current->mm.
>>>   
>>>       
>> Well, my intended use for them *does* know its connected to KVM. 
>>     
>
> How does it know? You get a file descriptor and you even figure out it's an
> eventfd. Now what? Any process can write there.
>   

Well, I suppose that is true.  Unlike my current hypercall coupling
deployed in vbus v3, anyone can signal the event for the iosignalfd. 
However, it wouldn't matter other than looking like an errant signal as
I do not use "current" for anything. (e.g. all the virtio pointers are
stored independently to the iosignalfd)
>   
>> Perhaps there will be others that do not in the future, but like I said
>> it could be addressed as those actually arise.
>>
>>
>>     
>>>   
>>>       
>>>> So since I cannot use it accurately for the hardirq/threaded-irq type
>>>> case, and I don't actually need it for the iosignalfd case, I am not
>>>> sure its the right direction (at least for now).  I do think it might
>>>> have merit for syscal/vmexit uses outside of iosignalfd, but I do not
>>>> see a current use-case for it so perhaps it can wait until one arises.
>>>>
>>>> -Greg
>>>>     
>>>>         
>>> But, it addresses the CONFIG_PREEMPT off case, which your design doesn't
>>> seem to.
>>>   
>>>       
>> Well, the problem is that it only addresses it partially in a limited
>> set of circumstances, and doesn't address the broader problem.  I'll
>> give you an example:
>>
>> (First off, lets assume that we are not going to have
>> eventfd_signal_task(), but rather eventfd_signal() with two option
>> flags: EVENTFD_SIGNAL_CANSLEEP, and EVENTFD_SIGNAL_CURRENTVALID
>>
>> Today vbus-enet has a rx-thread and a tx-thread at least partially
>> because I need process-context to do the copy_to_user(other->mm) type
>> stuff (and we will need similar for our virtio-net backend as well).  I
>> also utilize irqfd to do interrupt injection.  Now, since I know that I
>> have kthread_context, I could modify vbus-enet to inject interrupts with
>> EVENTFD_SIGNAL_CANSLEEP set, and this is fine.  I know that is safe.
>>
>> However, the problem is above that!  I would like to optimize out the
>> tx-thread to begin with with a similar "can_sleep()" pattern whenever
>> possible.
>>
>> For instance, if the netif stack calls me to do a transmit and it
>> happens to be in a sleepable context, it would be nice to just skip
>> waking up the tx-thread.  I would therefore just do the
>> copy_to_user(other->mm) + irqfd directly in the netif callback, thereby
>> skipping the context switch.
>>     
>
> What do you mean by copy_to_user(other->mm) here?  If you are going to switch
> to another mm, then I think current->mm must be valid (I think it's not enough
> that you can sleep). So preemptible() might not be enough.
>   

I dont currently use switch_mm, if that is what you mean.  I save the
task_struct into the appropriate context so current->mm doesn't matter
to me.  I never use it.  All I need (afaik) is to acquire the proper
mutex first.  I am not an MM expert, so perhaps I have this wrong but it
does appear to work properly even from kthread context.

-Greg

Attachment: signature.asc
Description: OpenPGP digital signature