public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: lijiazi <jqqlijiazi@gmail.com>
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 08:53:55 +0200	[thread overview]
Message-ID: <YtpJg90L0OUxa5DS@kroah.com> (raw)
In-Reply-To: <20220722061246.GA4801@Jiazi.Li>

On Fri, Jul 22, 2022 at 02:18:11PM +0800, lijiazi wrote:
> 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.

That is not true, Google would much rather accept in-tree modules that
are upstream.  It's your choice to not submit them for inclusion, please
don't pass the blame to someone else.

> I haven't found in-tree drivers has this issue.

Then perhaps your drivers are broken?  Do you have a link to the source
anywhere?

thanks,

greg k-h

  reply	other threads:[~2022-07-22  6:54 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
2022-07-22  6:53     ` Greg Kroah-Hartman [this message]
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=YtpJg90L0OUxa5DS@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=jiazi.li@transsion.com \
    --cc=jqqlijiazi@gmail.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