Re: [PATCH 00/50] USB: cleanup spin_lock in URB-complete()
On Thu, 2013-07-11 at 17:05 +0800, Ming Lei wrote: Hi, As we are going to run URB-complete() in tasklet context[1][2], Hi, Please pardon my naivete, but why was it decided to use tasklets to defer work, as opposed to some other deferred work mechanism? It seems to me that getting rid of tasklets has been an objective for years: http://lwn.net/Articles/239633/ http://lwn.net/Articles/520076/ http://lwn.net/Articles/240054/ Regards, Andy and hard interrupt may be enabled when running URB completion handler[3], so we might need to disable interrupt when acquiring one lock in the completion handler for the below reasons: - URB-complete() holds a subsystem wide lock which may be acquired in another hard irq context, and the subsystem wide lock is acquired by spin_lock()/read_lock()/write_lock() in complete() - URB-complete() holds a private lock with spin_lock()/read_lock()/write_lock() but driver may export APIs to make other drivers acquire the same private lock in its interrupt handler. For the sake of safety and making the change simple, this patch set converts all spin_lock()/read_lock()/write_lock() in completion handler path into their irqsave version mechanically. But if you are sure the above two cases do not happen in your driver, please let me know and I can drop the unnecessary change. Also if you find some conversions are missed, also please let me know so that I can add it in the next round. [1], http://marc.info/?l=linux-usbm=137286322526312w=2 [2], http://marc.info/?l=linux-usbm=137286326726326w=2 [3], http://marc.info/?l=linux-usbm=137286330626363w=2 [snip] Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] kfifo: log based kfifo API
Dmitry Torokhov dmitry.torok...@gmail.com wrote:
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct
dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct
dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order,
GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Why don't you simply change __kfifo_alloc to round the allocation up
instead of down?
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-media
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Dmitry,
I agree. I don't see the benefit in pushing up the change to a kfifo internal
decision/problem to many different places in the kernel.
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
