| Message ID | 1417425166-150374-1-git-send-email-mika.westerberg@linux.intel.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | c957e8f084e0d21febcd6b8a0ea9631eccc92f36 |
| Headers | show |
Mika Westerberg <mika.westerberg@linux.intel.com> writes: > Once the current message is finished, the driver notifies SPI core about > this by calling spi_finalize_current_message(). This function queues next > message to be transferred. If there are more messages in the queue, it is > possible that the driver is asked to transfer the next message at this > point. > > When spi_finalize_current_message() returns the driver clears the > drv_data->cur_chip pointer to NULL. The problem is that if the driver > already started the next message clearing drv_data->cur_chip will cause > NULL pointer dereference which crashes the kernel like: ..zip.. > Fix this by clearing drv_data->cur_chip before we call > spi_finalize_current_message(). So with your change, we have : drv_data->cur_chip = NULL; spi_finalize_current_message(drv_data->master); In that case, if spi_finalize_current_message() queues another message, upon this next message completion, won't giveback() be called, and dereference cur_chip as well ? Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 04, 2014 at 10:01:06PM +0100, Robert Jarzmik wrote: > Mika Westerberg <mika.westerberg@linux.intel.com> writes: > > > Once the current message is finished, the driver notifies SPI core about > > this by calling spi_finalize_current_message(). This function queues next > > message to be transferred. If there are more messages in the queue, it is > > possible that the driver is asked to transfer the next message at this > > point. > > > > When spi_finalize_current_message() returns the driver clears the > > drv_data->cur_chip pointer to NULL. The problem is that if the driver > > already started the next message clearing drv_data->cur_chip will cause > > NULL pointer dereference which crashes the kernel like: > ..zip.. > > Fix this by clearing drv_data->cur_chip before we call > > spi_finalize_current_message(). > > So with your change, we have : > drv_data->cur_chip = NULL; > spi_finalize_current_message(drv_data->master); > > In that case, if spi_finalize_current_message() queues another message, upon > this next message completion, won't giveback() be called, and dereference > cur_chip as well ? When the next message is started pxa2xx_spi_transfer_one_message() gets called and that will set cur_chip again. -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mika Westerberg <mika.westerberg@linux.intel.com> writes: > On Thu, Dec 04, 2014 at 10:01:06PM +0100, Robert Jarzmik wrote: >> So with your change, we have : >> drv_data->cur_chip = NULL; >> spi_finalize_current_message(drv_data->master); >> >> In that case, if spi_finalize_current_message() queues another message, upon >> this next message completion, won't giveback() be called, and dereference >> cur_chip as well ? > > When the next message is started pxa2xx_spi_transfer_one_message() gets > called and that will set cur_chip again. Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Cheers.
On Mon, Dec 01, 2014 at 11:12:46AM +0200, Mika Westerberg wrote: > Once the current message is finished, the driver notifies SPI core about > this by calling spi_finalize_current_message(). This function queues next > message to be transferred. If there are more messages in the queue, it is > possible that the driver is asked to transfer the next message at this > point. > > When spi_finalize_current_message() returns the driver clears the > drv_data->cur_chip pointer to NULL. The problem is that if the driver > already started the next message clearing drv_data->cur_chip will cause > NULL pointer dereference which crashes the kernel like: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 > IP: [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] > PGD 78bb8067 PUD 37712067 PMD 0 > Oops: 0000 [#1] SMP > Modules linked in: > CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G O 3.18.0-rc4-mjo #5 > Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014 > task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000 > RIP: 0010:[<ffffffffa0022bc8>] [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] > RSP: 0018:ffff88007a823d08 EFLAGS: 00010202 > RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026 > RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430 > RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a > R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98 > R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000 > FS: 0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0 > Stack: > ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89 > 0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006 > ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204 > Call Trace: > [<ffffffffa0022c89>] giveback+0x69/0xa0 [spi_pxa2xx_platform] > [<ffffffffa0023be0>] pump_transfers+0x710/0x740 [spi_pxa2xx_platform] > [<ffffffff81076204>] ? pick_next_task_fair+0x744/0x830 > [<ffffffff81049679>] tasklet_action+0xa9/0xe0 > [<ffffffff81049a0e>] __do_softirq+0xee/0x280 > [<ffffffff81049bc0>] run_ksoftirqd+0x20/0x40 > [<ffffffff810646df>] smpboot_thread_fn+0xff/0x1b0 > [<ffffffff810645e0>] ? SyS_setgroups+0x150/0x150 > [<ffffffff81060f9d>] kthread+0xcd/0xf0 > [<ffffffff81060ed0>] ? kthread_create_on_node+0x180/0x180 > [<ffffffff8187a82c>] ret_from_fork+0x7c/0xb0 > > Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message(). > > Reported-by: Martin Oldfield <m@mjoldfield.com> > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Mark, any comments on this? -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 23, 2014 at 03:49:17PM +0200, Mika Westerberg wrote:
> Mark, any comments on this?
Please don't send contentless pings, they just add more e-mail. Resend
if you think something has been lost.
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c index 9e9e0f971e6c..d95656d05eb6 100644 --- a/drivers/spi/spi-pxa2xx.c +++ b/drivers/spi/spi-pxa2xx.c @@ -402,8 +402,8 @@ static void giveback(struct driver_data *drv_data) cs_deassert(drv_data); } - spi_finalize_current_message(drv_data->master); drv_data->cur_chip = NULL; + spi_finalize_current_message(drv_data->master); } static void reset_sccr1(struct driver_data *drv_data)
Once the current message is finished, the driver notifies SPI core about this by calling spi_finalize_current_message(). This function queues next message to be transferred. If there are more messages in the queue, it is possible that the driver is asked to transfer the next message at this point. When spi_finalize_current_message() returns the driver clears the drv_data->cur_chip pointer to NULL. The problem is that if the driver already started the next message clearing drv_data->cur_chip will cause NULL pointer dereference which crashes the kernel like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 IP: [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] PGD 78bb8067 PUD 37712067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G O 3.18.0-rc4-mjo #5 Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014 task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000 RIP: 0010:[<ffffffffa0022bc8>] [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] RSP: 0018:ffff88007a823d08 EFLAGS: 00010202 RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430 RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98 R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000 FS: 0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0 Stack: ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89 0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006 ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204 Call Trace: [<ffffffffa0022c89>] giveback+0x69/0xa0 [spi_pxa2xx_platform] [<ffffffffa0023be0>] pump_transfers+0x710/0x740 [spi_pxa2xx_platform] [<ffffffff81076204>] ? pick_next_task_fair+0x744/0x830 [<ffffffff81049679>] tasklet_action+0xa9/0xe0 [<ffffffff81049a0e>] __do_softirq+0xee/0x280 [<ffffffff81049bc0>] run_ksoftirqd+0x20/0x40 [<ffffffff810646df>] smpboot_thread_fn+0xff/0x1b0 [<ffffffff810645e0>] ? SyS_setgroups+0x150/0x150 [<ffffffff81060f9d>] kthread+0xcd/0xf0 [<ffffffff81060ed0>] ? kthread_create_on_node+0x180/0x180 [<ffffffff8187a82c>] ret_from_fork+0x7c/0xb0 Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message(). Reported-by: Martin Oldfield <m@mjoldfield.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> --- drivers/spi/spi-pxa2xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)