On Fri, May 21, 2021 at 07:15:21PM +0800, Zheyu Ma wrote: > On Fri, May 21, 2021 at 2:51 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Fri, May 21, 2021 at 06:08:43AM +0000, Zheyu Ma wrote: > > > In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls > > > 'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the > > > firmware don't exists, function just return without initializing ports > > > of 'rp2_card'. But now the interrupt handler function has been > > > registered, and when an interrupt comes, 'rp2_uart_interrupt' may access > > > those ports then causing NULL pointer dereference or other bugs. > > > > > > Because the driver does some initialization work in 'rp2_fw_cb', in > > > order to make the driver ready to handle interrupts, 'request_firmware' > > > should be used instead of asynchronous 'request_firmware_nowait'. > > > > You just now slowed down the probe function. Are you _sure_ this is ok? > > Sorry, I'm not an expert in the field, but from my point of view, the > previous function 'rp2_fw_cb' does some initialization work that is > not suitable for asynchronous execution. Because after these initial > work, the driver can work normally (including preparing to handle > interrupts). > > > Do you have this hardware to test this? If so, what is the init time > > before and after this change? > > To be honest, I don't have real hardware, I tested it with QEMU. I > made a total of 5 attempts. Before this change, the average boot time > required by kernel is 6.382s, the time required for insmoding this > module is 0.139s; After this change, the average boot time required by > kernel is 6.426s, the time required for insmoding this module is > 0.160s. This change really slowed down the probe function. Ok, at least you've tested it :) I'll take a slower init over a broken init any day. I'll go queue this up, thanks. greg k-h
