Hi, This is regarding dma memory usage in my kernel driver on arm64 processor. I have a structure in my kernel driver as shown below- struct dummy_dc_dmabuf { struct dma_buf *buf; struct dma_buf_attachment *attach; struct sg_table *sgt; }; For this I am able to get memory allocated like below void pin_window(struct dummy_dmabuf **dum_buf, int fd, struct device *dev) { struct dummy_dmabuf *dum_dmabuf; dma_addr_t dma_addr; dum_dmabuf = kzalloc(sizeof(*dum_dmabuf), GFP_KERNEL); if (!dum_dmabuf) return -ENOMEM; dum_dmabuf->buf = dma_buf_get(fd); dum_dmabuf->attach = dma_buf_attach(dum_dmabuf->buf, dev->parent); dum_dmabuf->sgt = dma_buf_map_attachment(dum_dmabuf->attach, DMA_TO_DEVICE); *dum_buf = dum_dmabuf; } As per ldd3 , Chapter 15 - "The DMA controller is a shared resource, and confusion could arise if more than one processor attempts to program it simultaneously. For that reason, the controller is protected by a spinlock, called dma_spin_lock. Drivers should not manipulate the lock directly;" 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. Regards, Saket Sinha
On Wed, 31 Jan 2018 19:49:29 +0530, Saket Sinha said:
As per ldd3 , Chapter 15 - "The DMA controller is a shared resource, and confusion could arise if more than one processor attempts to program it simultaneously. For that reason, the controller is protected by a spinlock, called dma_spin_lock. Drivers should not manipulate the lock directly;"
Yes, that way lies great pain and confusion.
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. 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?
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.
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 ? Note: I am on ARMv8 SMP system using kernel version 4.4 . Regards, Saket Sinha Regards, Saket Sinha
participants (2)
-
Saket Sinha -
valdis.kletnieks＠vt.edu