Messages in this thread | | | Subject | Re: [PATCH] scsi: wd719x Replace GFP_KERNEL with GFP_ATOMIC in wd719x_chip_init | From | Douglas Gilbert <> | Date | Mon, 14 Jan 2019 11:31:21 -0500 |
| |
On 2019-01-14 10:29 a.m., Christoph Hellwig wrote: > On Mon, Jan 14, 2019 at 11:24:49PM +0800, wangbo wrote: >> wd719x_host_reset get spinlock first then call wd719x_chip_init, >> so replace GFP_KERNEL with GFP_ATOMIC in wd719x_chip_init. > > Please move the allocation outside the lock instead. GFP_ATOMIC > DMA allocations are generally a bad idea and should be avoided where > we can. > > More importantly we should never actually trigger the allocation > under the lock as far as fw_virt will always be set already > in that case. > > So I think you can safely move the request firmware + allocation > + memcpy from wd719x_chip_init to wd719x_board_found, but I'd rather > have Ondrej review that plan.
Further to this, the result of holding a lock (probably with _irqsave() tacked onto it) during a GFP_KERNEL is a message like this in the log: hrtimer: interrupt took 1084 ns
It is not always easy to find since it is a "_once" message. The sg v3 driver (the one in production) produces these. I have been able to stamp them out by taking care in the sg v4 driver (in testing) around allocations. It also meant adding a new state in my state machine to fend off "bad things" happening to that object while it is unlocked. So there may be a cost to dropping the lock.
Doug Gilbert
| |