Question

Recently I attended couple of interviews. Out of all kernel questions which were asked, there is one specific question which I couldn’t find convincing answer of.

How will you use different synchronization techniques while sharing data between user space process and interrupt context function? My convincing answer was:

In interrupt context code:

1. do *spin_lock_irqsave*
2. access data buffer which is shared between user space app and kernel
3. do *spin_lock_irqrestore*

Then this was not convincing answer. Do I have to do irqsave and irqrestore in all the instances of data access?

Was it helpful?

Solution

You cannot directly transfer data from interrupt context to user space context. In interrupt process there is no process information, so you don't know where to send the data. You need to use the intermediate process context from the kernel space.

Now, to answer the question. In your device data you'll have a buffer in which you'll store data from interrupt context. You need to protect your data using spinlocks but without the irqsave/irqrestore part. Because you are in interrupt context.

Then, your device will offer a way for userspace to get this data. Either via a char device or a netlink socket or an ioctl call or any other method, you decide. When the user space requires this data, you'll memcpy from the device buffer to the userspace buffer. But you'll protect the device buffer using spin_lock_irqsave / spin_lock_irqrestore pair because you don't want an interrupt code to deadlock.

When userspace uses one of the methods presented above (char device read, netlink socket, ioctl call, ...) the kernel takes care of providing locking mechanism but for the interface between userspace and process.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top