Re: [PATCH 1/2] thunderbolt: Fix a leak in tb_retimer_add()

From: Jason Gunthorpe <jgg@nvidia.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Andreas Noever <andreas.noever@gmail.com>,
	Kranthi Kuntala <kranthi.kuntala@intel.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 1/2] thunderbolt: Fix a leak in tb_retimer_add()
Date: Mon, 29 Mar 2021 11:54:05 -0300	[thread overview]
Message-ID: <20210329145405.GD2356281@nvidia.com> (raw)
In-Reply-To: <20210329144323.GI2542@lahna.fi.intel.com>

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