From: Oliver Graute <[email protected]>
remove edt_ft5x06_ts_readwrite() call because this result in a stack
corruption crash on EP011M09
[ 2.968250] edt_ft5x06 1-0038: 1-0038 supply vcc not found, using dummy regulator
[ 2.991327] input: EP0110M09 as /devices/platform/bus@5a000000/5a820000.i2c/i2c-1/1-0038/input/input0
[ 3.011818] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: edt_ft5x06_ts_probe+0x9e4/0xa98
[ 3.022519] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.6.0-rc1-next-20200214+ #69
[ 3.030261] Hardware name: Advantech iMX8QM DMSSE20 (DT)
[ 3.035583] Workqueue: events deferred_probe_work_func
[ 3.040724] Call trace:
[ 3.043179] dump_backtrace+0x0/0x1c0
[ 3.046839] show_stack+0x14/0x20
[ 3.050161] dump_stack+0xb4/0xfc
[ 3.053477] panic+0x158/0x320
[ 3.056531] print_tainted+0x0/0xa8
[ 3.060015] edt_ft5x06_ts_probe+0x9e4/0xa98
[ 3.064286] i2c_device_probe+0x2d0/0x2f8
[ 3.068299] really_probe+0xd8/0x438
[ 3.071874] driver_probe_device+0xdc/0x130
[ 3.076064] __device_attach_driver+0x88/0x108
[ 3.080511] bus_for_each_drv+0x74/0xc0
[ 3.084349] __device_attach+0xdc/0x160
[ 3.088189] device_initial_probe+0x10/0x18
[ 3.092376] bus_probe_device+0x90/0x98
[ 3.096210] device_add+0x434/0x770
[ 3.099699] device_register+0x1c/0x28
[ 3.103447] i2c_new_client_device+0x134/0x2a8
[ 3.107897] of_i2c_register_device+0xb0/0xd8
[ 3.112253] of_i2c_register_devices+0x9c/0x198
[ 3.116780] i2c_register_adapter+0x150/0x418
[ 3.121141] __i2c_add_numbered_adapter+0x58/0xa0
[ 3.125849] i2c_add_adapter+0x9c/0xc8
[ 3.129598] lpi2c_imx_probe+0x1b0/0x2a0
[ 3.133523] platform_drv_probe+0x50/0xa0
[ 3.137534] really_probe+0xd8/0x438
[ 3.141105] driver_probe_device+0xdc/0x130
[ 3.145284] __device_attach_driver+0x88/0x108
[ 3.149731] bus_for_each_drv+0x74/0xc0
[ 3.153562] __device_attach+0xdc/0x160
[ 3.157394] device_initial_probe+0x10/0x18
[ 3.161581] bus_probe_device+0x90/0x98
[ 3.165412] deferred_probe_work_func+0x88/0xd8
[ 3.169942] process_one_work+0x19c/0x320
[ 3.173952] worker_thread+0x1f0/0x420
[ 3.177703] kthread+0xf0/0x120
[ 3.180843] ret_from_fork+0x10/0x18
[ 3.184432] SMP: stopping secondary CPUs
[ 3.188362] Kernel Offset: disabled
[ 3.191853] CPU features: 0x10002,2100600c
[ 3.195951] Memory Limit: none
Signed-off-by: Oliver Graute <[email protected]>
---
drivers/input/touchscreen/edt-ft5x06.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 06aa8ba0b6d7..6fbc87d041a1 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -819,10 +819,6 @@ static int edt_ft5x06_ts_identify(struct i2c_client *client,
* to have garbage in there
*/
memset(rdbuf, 0, sizeof(rdbuf));
- error = edt_ft5x06_ts_readwrite(client, 1, "\xBB",
- EDT_NAME_LEN - 1, rdbuf);
- if (error)
- return error;
/* Probe content for something consistent.
* M06 starts with a response byte, M12 gives the data directly.
--
2.17.1
On Thu, Apr 09, 2020 at 11:27:01AM +0200, Oliver Graute wrote:
> From: Oliver Graute <[email protected]>
>
> remove edt_ft5x06_ts_readwrite() call because this result in a stack
> corruption crash on EP011M09
And how it's supposed now to work on the rest of variants?
> [ 2.968250] edt_ft5x06 1-0038: 1-0038 supply vcc not found, using dummy regulator
> [ 2.991327] input: EP0110M09 as /devices/platform/bus@5a000000/5a820000.i2c/i2c-1/1-0038/input/input0
> [ 3.011818] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: edt_ft5x06_ts_probe+0x9e4/0xa98
> [ 3.022519] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.6.0-rc1-next-20200214+ #69
> [ 3.030261] Hardware name: Advantech iMX8QM DMSSE20 (DT)
> [ 3.035583] Workqueue: events deferred_probe_work_func
> [ 3.040724] Call trace:
> [ 3.043179] dump_backtrace+0x0/0x1c0
> [ 3.046839] show_stack+0x14/0x20
> [ 3.050161] dump_stack+0xb4/0xfc
> [ 3.053477] panic+0x158/0x320
> [ 3.056531] print_tainted+0x0/0xa8
> [ 3.060015] edt_ft5x06_ts_probe+0x9e4/0xa98
> [ 3.064286] i2c_device_probe+0x2d0/0x2f8
No need to have below attached to the commit message. It's irrelevant.
> [ 3.068299] really_probe+0xd8/0x438
> [ 3.071874] driver_probe_device+0xdc/0x130
> [ 3.076064] __device_attach_driver+0x88/0x108
--
With Best Regards,
Andy Shevchenko
Hi Oliver,
thanks for your patch.
On 20-04-09 11:27, Oliver Graute wrote:
> From: Oliver Graute <[email protected]>
...
> drivers/input/touchscreen/edt-ft5x06.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> index 06aa8ba0b6d7..6fbc87d041a1 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -819,10 +819,6 @@ static int edt_ft5x06_ts_identify(struct i2c_client *client,
> * to have garbage in there
> */
> memset(rdbuf, 0, sizeof(rdbuf));
> - error = edt_ft5x06_ts_readwrite(client, 1, "\xBB",
> - EDT_NAME_LEN - 1, rdbuf);
> - if (error)
> - return error;
I don't see how this call can corrupt the stack..
Regards,
Marco
On 09/04/20, Marco Felsch wrote:
> Hi Oliver,
>
> thanks for your patch.
>
> On 20-04-09 11:27, Oliver Graute wrote:
> > From: Oliver Graute <[email protected]>
>
> ...
>
> > drivers/input/touchscreen/edt-ft5x06.c | 4 ----
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> > index 06aa8ba0b6d7..6fbc87d041a1 100644
> > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > @@ -819,10 +819,6 @@ static int edt_ft5x06_ts_identify(struct i2c_client *client,
> > * to have garbage in there
> > */
> > memset(rdbuf, 0, sizeof(rdbuf));
> > - error = edt_ft5x06_ts_readwrite(client, 1, "\xBB",
> > - EDT_NAME_LEN - 1, rdbuf);
> > - if (error)
> > - return error;
>
>
> I don't see how this call can corrupt the stack..
I admit that this is strange. The patch fixed my problems so I posted
it. Still interested in the root-cause.
Best regards,
Oliver
On Thu, Apr 09, 2020 at 02:02:42PM +0200, Oliver Graute wrote:
> On 09/04/20, Marco Felsch wrote:
> > Hi Oliver,
> >
> > thanks for your patch.
> >
> > On 20-04-09 11:27, Oliver Graute wrote:
> > > From: Oliver Graute <[email protected]>
> >
> > ...
> >
> > > drivers/input/touchscreen/edt-ft5x06.c | 4 ----
> > > 1 file changed, 4 deletions(-)
> > >
> > > diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> > > index 06aa8ba0b6d7..6fbc87d041a1 100644
> > > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > > @@ -819,10 +819,6 @@ static int edt_ft5x06_ts_identify(struct i2c_client *client,
> > > * to have garbage in there
> > > */
> > > memset(rdbuf, 0, sizeof(rdbuf));
> > > - error = edt_ft5x06_ts_readwrite(client, 1, "\xBB",
> > > - EDT_NAME_LEN - 1, rdbuf);
> > > - if (error)
> > > - return error;
> >
> >
> > I don't see how this call can corrupt the stack..
>
> I admit that this is strange. The patch fixed my problems so I posted
> it. Still interested in the root-cause.
I'm wondering how you nailed down to this function? Have you able to use kASAN?
By the way, what I?C controller behind this? Maybe the bug in its driver?
--
With Best Regards,
Andy Shevchenko
On Thu, Apr 09, 2020 at 03:36:22PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 09, 2020 at 02:02:42PM +0200, Oliver Graute wrote:
> > On 09/04/20, Marco Felsch wrote:
> > > Hi Oliver,
> > >
> > > thanks for your patch.
> > >
> > > On 20-04-09 11:27, Oliver Graute wrote:
> > > > From: Oliver Graute <[email protected]>
> > >
> > > ...
> > >
> > > > drivers/input/touchscreen/edt-ft5x06.c | 4 ----
> > > > 1 file changed, 4 deletions(-)
> > > >
> > > > diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> > > > index 06aa8ba0b6d7..6fbc87d041a1 100644
> > > > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > > > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > > > @@ -819,10 +819,6 @@ static int edt_ft5x06_ts_identify(struct i2c_client *client,
> > > > * to have garbage in there
> > > > */
> > > > memset(rdbuf, 0, sizeof(rdbuf));
> > > > - error = edt_ft5x06_ts_readwrite(client, 1, "\xBB",
> > > > - EDT_NAME_LEN - 1, rdbuf);
> > > > - if (error)
> > > > - return error;
> > >
> > >
> > > I don't see how this call can corrupt the stack..
> >
> > I admit that this is strange. The patch fixed my problems so I posted
> > it. Still interested in the root-cause.
>
> I'm wondering how you nailed down to this function? Have you able to use kASAN?
>
> By the way, what I?C controller behind this? Maybe the bug in its driver?
I would try instrumenting drivers/i2c/busses/i2c-imx-lpi2c.c to make
sure it does not try to stuff into the rdbuf more data than requested...
Thanks.
--
Dmitry