All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2021-03-29 14:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29  6:07 [PATCH 1/2] thunderbolt: Fix a leak in tb_retimer_add() Dan Carpenter
2021-03-29  6:08 ` [PATCH 2/2] thunderbolt: Fix off by one in tb_port_find_retimer() Dan Carpenter
2021-03-29 13:02 ` [PATCH 1/2] thunderbolt: Fix a leak in tb_retimer_add() Jason Gunthorpe
2021-03-29 14:43   ` Mika Westerberg
2021-03-29 14:54     ` Jason Gunthorpe [this message]
2021-03-29 15:06       ` Mika Westerberg
2021-03-30 10:41 ` Mika Westerberg

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=20210329145405.GD2356281@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=YehezkelShB@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=kranthi.kuntala@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=michael.jamet@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.