[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210329145405.GD2356281@nvidia.com>
Date: Mon, 29 Mar 2021 11:54:05 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Dan Carpenter <dan.carpenter@...cle.com>,
Andreas Noever <andreas.noever@...il.com>,
Kranthi Kuntala <kranthi.kuntala@...el.com>,
Michael Jamet <michael.jamet@...el.com>,
Yehezkel Bernat <YehezkelShB@...il.com>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 1/2] thunderbolt: Fix a leak in tb_retimer_add()
On Mon, Mar 29, 2021 at 05:43:23PM +0300, Mika Westerberg wrote:
> The nvm is a separate (physical Linux) device that gets added under this
> one. It cannot be added before AFAICT.
Hum, yes, but then it is odd that a parent is holding sysfs attributes
that refer to a child.
> The code you refer actually looks like this:
>
> static ssize_t nvm_authenticate_store(struct device *dev,
> struct device_attribute *attr, const char *buf, size_t count)
> {
> ...
> if (!mutex_trylock(&rt->tb->lock)) {
> ret = restart_syscall();
> goto exit_rpm;
> }
Is that lock held during tb_retimer_nvm_add() I looked for a bit and
didn't find something. So someplace more than 4 call site above
mandatory locking is being held?
static void tb_retimer_remove(struct tb_retimer *rt)
{
dev_info(&rt->dev, "retimer disconnected\n");
tb_nvm_free(rt->nvm);
device_unregister(&rt->dev);
}
Here too?
And this is why it is all trylock because it deadlocks with unregister
otherwise?
Jason
Powered by blists - more mailing lists