public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: lijiazi <jqqlijiazi@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	"Jiazi.Li" <jiazi.li@transsion.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] driver core: Do not add a device that has been removed in device_shutdown to devices_kset list again.
Date: Fri, 22 Jul 2022 14:18:11 +0800	[thread overview]
Message-ID: <20220722061246.GA4801@Jiazi.Li> (raw)
In-Reply-To: <Ytmlih/TgGNrRTwy@kroah.com>

On Thu, Jul 21, 2022 at 09:14:18PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 21, 2022 at 08:33:25PM +0800, Jiazi.Li wrote:
> > There is a race between device_shutdown and devices_kset_move_last:
> > 1. device_shutdown remove dev from devices_kset, unlock list_lock
> > 
> > 2. supplier call device_link_add move this consummer dev to
> > last of devices_kset:
> > devices_kset_move_last+0x184/0x1fc
> > device_reorder_to_tail+0x50/0x17c
> > device_link_add+0x670/0x9c0
> > phy_get+0x88/0x300
> > 
> > 3. device_shutdown call dev->bus->shutdown first time
> > 
> > 4. in next loop, device_shutdown pick this dev from devices_kset
> > again, and call dev->bus->shutdown for the second time.
> > 
> > If the protection mechanism of dev->bus->shutdown is not perfect,
> > the following crash will occur:
> > [37.366651] [T1000001] Unable to handle kernel NULL pointer
> > dereference at virtual address 0000000000000070
> > [37.414053] [T1600001] Kernel Offset: 0x2c73800000 from 0xffffffc010000000
> > [37.414908] [T1600001] PHYS_OFFSET: 0x40000000
> > [37.415458] [T1600001] pstate: 60400005 (nZCv daif +PAN -UAO)
> > [37.416172] [T1600001] pc : [0xffffffec83eccd40] kernfs_find_ns+0x18/0x154
> > [37.417025] [T1600001] lr : [0xffffffec83ed8714] sysfs_unmerge_group+0x70/0x2e0
> > [37.417931] [T1600001] sp : ffffffc01008ba90
> > [37.418456] [T1600001] x29: ffffffc01008ba90 x28: ffffffec863c1000
> > [37.419221] [T1600001] x27: ffffffec85234e30 x26: ffffffec86490000
> > [37.419985] [T1600001] x25: ffffff80c854a4c0 x24: ffffff80c854a428
> > [37.420750] [T1600001] x23: 0000000000400100 x22: ffffffec85c4c5c8
> > [37.421514] [T1600001] x21: ffffffec85c4c5a0 x20: 0000000000000000
> > [37.422277] [T1600001] x19: ffffff80c0178000 x18: ffffffc010083068
> > [37.423043] [T1600001] x17: 0000000000000000 x16: 00000000000000d8
> > [37.423807] [T1600001] x15: ffffffec842b9314 x14: ffffffec85b04050
> > [37.424572] [T1600001] x13: 0000000000000000 x12: 000000000000000a
> > [37.425336] [T1600001] x11: 0000000000000000 x10: ffffffec863e9000
> > [37.426102] [T1600001] x9 : 0000000000000001 x8 : 0000000000000000
> > [37.426869] [T1600001] x7 : 332e37332020205b x6 : ffffffec863e6e7e
> > [37.427633] [T1600001] x5 : ffffffffffffffff x4 : 0000000000000000
> > [37.428396] [T1600001] x3 : 000000000000003c x2 : 0000000000000000
> > [37.429161] [T1600001] x1 : ffffffec85c4c5c8 x0 : 0000000000000000
> > [37.612410] [T1600001] Call trace:
> > [37.612831] [T1600001]  dump_backtrace.cfi_jt+0x0/0x8
> > [37.613457] [T1600001]  dump_stack_lvl+0xc4/0x140
> > [37.614038] [T1600001]  dump_stack+0x1c/0x2c
> > [37.614588] [T1600001]  mrdump_common_die+0x3a8/0x544 [mrdump]
> > [37.615326] [T1600001]  ipanic_die+0x24/0x38 [mrdump]
> > [37.615951] [T1600001]  die+0x344/0x748
> > [37.616425] [T1600001]  die_kernel_fault+0x84/0x94
> > [37.617016] [T1600001]  __do_kernel_fault+0x230/0x27c
> > [37.617642] [T1600001]  do_page_fault+0xb4/0x754
> > [37.618212] [T1600001]  do_translation_fault+0x48/0x64
> > [37.618846] [T1600001]  do_mem_abort+0x6c/0x164
> > [37.619406] [T1600001]  el1_abort+0x44/0x68
> > [37.619921] [T1600001]  el1_sync_handler+0x58/0x88
> > [37.620512] [T1600001]  el1_sync+0x8c/0x140
> > [37.621028] [T1600001]  kernfs_find_ns+0x18/0x154
> > [37.621608] [T1600001]  sysfs_unmerge_group+0x70/0x2e0
> > [37.622246] [T1600001]  device_del+0x198/0xd00
> > [37.622794] [T1600001]  device_unregister+0x1c/0x3c
> > [37.623409] [T1600001]  charger_device_unregister+0x40/0x54 [charger_class]
> > [37.624277] [T1600001]  sgm41516d_shutdown+0x54/0x84 [sgm41516d]
> > [37.625021] [T1600001]  i2c_device_shutdown+0x68/0x118
> > [37.625656] [T1600001]  device_shutdown+0x234/0x614
> > [37.626259] [T1600001]  kernel_restart+0x74/0x1e8
> > [37.626840] [T1600001]  __arm64_sys_reboot+0x3b0/0x424
> > [37.627475] [T1600001]  el0_svc_common+0xd4/0x270
> > [37.628056] [T1600001]  el0_svc+0x28/0x88
> > [37.628549] [T1600001]  el0_sync_handler+0x8c/0xf0
> > [37.629141] [T1600001]  el0_sync+0x1b4/0x1c0
> > 
> > because dev->kobject.sd has been set to NULL in fisrt shutdown.
> 
> We can't take kernel changes to fix bugs in out-of-tree kernel modules.
> Can you reproduce this with the in-tree drivers?  If so, which ones?
> 
> thanks,
> 
> greg k-h

I'm sorry, I am working on mobile phone base on android12+GKI2.0.
So far, I found two charger driver have this issue , maybe more.
Reproduce method is plug/unplug usb cable when device shutdown or
reboot.
GKI2.0 requires that most vendor's drivers are out-of-tree modules.
I haven't found in-tree drivers has this issue.

thanks,

Jiazi.Li

  reply	other threads:[~2022-07-22  6:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 12:33 [PATCH] driver core: Do not add a device that has been removed in device_shutdown to devices_kset list again Jiazi.Li
2022-07-21 12:40 ` Rafael J. Wysocki
2022-07-21 19:14 ` Greg Kroah-Hartman
2022-07-22  6:18   ` lijiazi [this message]
2022-07-22  6:53     ` Greg Kroah-Hartman
2022-07-22  7:31       ` lijiazi
2022-07-22  7:53         ` Greg Kroah-Hartman
2022-07-22  8:22           ` lijiazi
2022-07-22  8:40             ` Greg Kroah-Hartman
2022-07-22 10:30               ` lijiazi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220722061246.GA4801@Jiazi.Li \
    --to=jqqlijiazi@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jiazi.li@transsion.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox