On 31-Jan-2018 11:36 PM, "Saket Sinha" <saket.sinha89@gmail.com> wrote:

...

However, I am using this in kthreads and I want to protect it without using mutex/spilock. Apart from protecting it with spinlock or mutex, is their anyway to mark this dma buffer as read-only so that other threads(after concerned thread has accessed it) cannot access the dma buffer.

Basic locking theory states that if one section of code is already using

one

type of locking primitive, and you want a lock on the resource, you need to use the same type of lock, and the same instance.

I just love this above sentence, well put in a general sense, Valdis.

In other words, you need to use a spinlock on dma_spin_lock as well, or things *will* fail (and when it's a DMA controller in question, the failure will almost certainly be spectacular). So using a mutex is probably out of the question.

Have you considered restructuring your code so a spinlock is usable?

Thanks Valdis for the prompt reply. I would go ahead and check if spinlock could work instead of mutex which I am currently using. However, let me also explain the context how I am using mutex by below pseudo code- MUTEX_INIT(dma_lock); void dummy_worker_thread() { ................... mutex_lock(&dma_lock) CHECK_BIT(hw_register, nth_bit); mutex_unlock(&dma_lock); .................... } Lets suppose the nth_bit is set in hw_register every X ms. Do you think spinlock will be more advantageous here than mutex ? See basic difference between mutex and spinlock is, the former puts the thread waiting on the lock to sleep and later does a busy wait. Since the nth bit is set every X ms, I think sleeping and waking up would turn out to be costly operations/overhead so no mutex. Spinlock would be good enough here. Note: I am on ARMv8 SMP system using kernel version 4.4 . Regards, Saket Sinha Regards, Saket Sinha _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies - Rohan