[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAE-0n51KBkt2fB_BDfFz9ON++XSn_AY0Cn+jq8WFVj8_6-jXtA@mail.gmail.com>
Date: Wed, 7 Sep 2022 19:59:34 -0500
From: Stephen Boyd <swboyd@...omium.org>
To: Deepak Kumar Singh <quic_deesin@...cinc.com>,
bjorn.andersson@...aro.org, mathieu.poirier@...aro.org,
quic_clew@...cinc.com
Cc: linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH V2 2/2] rpmsg: glink: Add lock to rpmsg_ctrldev_remove
Quoting Deepak Kumar Singh (2022-09-05 11:55:20)
> Hold ctrl device lock in rpmsg_ctrldev_remove to avoid any
> new create ept call to proceed, otherwise new ept creation
> and associted char device may suceed. Any further call from
s/associted/associated/
s/suceed/succeed/
> user space for rpmsg_eptdev_open will reference already freed
rpmsg_eptdev_open()
> rpdev and will result in crash. Below crash signature was
> observed -
>
> rpmsg_create_ept+0x40/0xa0
> rpmsg_eptdev_open+0x88/0x138
> chrdev_open+0xc4/0x1c8
> do_dentry_open+0x230/0x378
> vfs_open+0x3c/0x48
> path_openat+0x93c/0xa78
> do_filp_open+0x98/0x118
> do_sys_openat2+0x90/0x220
> do_sys_open+0x64/0x8c
Again, can you show a CPU diagram for what you're fixing? I think the
problem is device is going away, but chrdev_open() is being called and
that's accessing a device that's on the way out?
Powered by blists - more mailing lists