Mark dma buffer readonly

[Rohan Puri]

On 31-Jan-2018 11:36 PM, "Saket Sinha" <saket.sinha89 at 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 at kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


- Rohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180201/4685f7a6/attachment.html>