All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Will Deacon <will@kernel.org>
Cc: joro@8bytes.org, vivek.gautam@arm.com, guohanjun@huawei.com,
	linux-acpi@vger.kernel.org, zhangfei.gao@linaro.org,
	lenb@kernel.org, devicetree@vger.kernel.org,
	kevin.tian@intel.com, robh+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
	iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
	robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org
Subject: Re: [PATCH v13 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure
Date: Fri, 26 Mar 2021 10:49:57 +0100	[thread overview]
Message-ID: <YF2uRXoUwFSAmQWI@myrica> (raw)
In-Reply-To: <20210325174807.GD15504@willie-the-truck>

On Thu, Mar 25, 2021 at 05:48:07PM +0000, Will Deacon wrote:
> > +/* smmu->streams_mutex must be held */
> 
> Can you add a lockdep assertion for that?

Sure

> > +__maybe_unused
> > +static struct arm_smmu_master *
> > +arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid)
> > +{
> > +	struct rb_node *node;
> > +	struct arm_smmu_stream *stream;
> > +
> > +	node = smmu->streams.rb_node;
> > +	while (node) {
> > +		stream = rb_entry(node, struct arm_smmu_stream, node);
> > +		if (stream->id < sid)
> > +			node = node->rb_right;
> > +		else if (stream->id > sid)
> > +			node = node->rb_left;
> > +		else
> > +			return stream->master;
> > +	}
> > +
> > +	return NULL;
> > +}
> 
> [...]
> 
> > +static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
> > +				  struct arm_smmu_master *master)
> > +{
> > +	int i;
> > +	int ret = 0;
> > +	struct arm_smmu_stream *new_stream, *cur_stream;
> > +	struct rb_node **new_node, *parent_node = NULL;
> > +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
> > +
> > +	master->streams = kcalloc(fwspec->num_ids, sizeof(*master->streams),
> > +				  GFP_KERNEL);
> > +	if (!master->streams)
> > +		return -ENOMEM;
> > +	master->num_streams = fwspec->num_ids;
> > +
> > +	mutex_lock(&smmu->streams_mutex);
> > +	for (i = 0; i < fwspec->num_ids; i++) {
> > +		u32 sid = fwspec->ids[i];
> > +
> > +		new_stream = &master->streams[i];
> > +		new_stream->id = sid;
> > +		new_stream->master = master;
> > +
> > +		/*
> > +		 * Check the SIDs are in range of the SMMU and our stream table
> > +		 */
> > +		if (!arm_smmu_sid_in_range(smmu, sid)) {
> > +			ret = -ERANGE;
> > +			break;
> > +		}
> > +
> > +		/* Ensure l2 strtab is initialised */
> > +		if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
> > +			ret = arm_smmu_init_l2_strtab(smmu, sid);
> > +			if (ret)
> > +				break;
> > +		}
> > +
> > +		/* Insert into SID tree */
> > +		new_node = &(smmu->streams.rb_node);
> > +		while (*new_node) {
> > +			cur_stream = rb_entry(*new_node, struct arm_smmu_stream,
> > +					      node);
> > +			parent_node = *new_node;
> > +			if (cur_stream->id > new_stream->id) {
> > +				new_node = &((*new_node)->rb_left);
> > +			} else if (cur_stream->id < new_stream->id) {
> > +				new_node = &((*new_node)->rb_right);
> > +			} else {
> > +				dev_warn(master->dev,
> > +					 "stream %u already in tree\n",
> > +					 cur_stream->id);
> > +				ret = -EINVAL;
> > +				break;
> > +			}
> > +		}
> > +		if (ret)
> > +			break;
> > +
> > +		rb_link_node(&new_stream->node, parent_node, new_node);
> > +		rb_insert_color(&new_stream->node, &smmu->streams);
> > +	}
> > +
> > +	if (ret) {
> > +		for (i--; i >= 0; i--)
> 
> Is 'i--' really what you want for the initial value? Doesn't that correspond
> to the ID you *didn't* add to the tree?

In case of error we break out of the loop, with i corresponding to the
stream that caused a fault but wasn't yet added to the tree. So i-- is
the last stream that was successfully added, or -1 in which case we don't
enter this for loop.

> > +			rb_erase(&master->streams[i].node, &smmu->streams);
> > +		kfree(master->streams);
> 
> Do you need to NULLify master->streams and/or reset master->num_streams
> after this? Seems like they're left dangling.

master is freed by arm_smmu_probe_device() when we return an error. Since
this function is unlikely to ever have another caller I didn't bother
cleaning up here

Thanks,
Jean

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Will Deacon <will@kernel.org>
Cc: devicetree@vger.kernel.org, kevin.tian@intel.com,
	linux-acpi@vger.kernel.org, sudeep.holla@arm.com,
	rjw@rjwysocki.net, vivek.gautam@arm.com,
	iommu@lists.linux-foundation.org, robh+dt@kernel.org,
	linux-accelerators@lists.ozlabs.org, guohanjun@huawei.com,
	zhangfei.gao@linaro.org, robin.murphy@arm.com,
	linux-arm-kernel@lists.infradead.org, lenb@kernel.org
Subject: Re: [PATCH v13 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure
Date: Fri, 26 Mar 2021 10:49:57 +0100	[thread overview]
Message-ID: <YF2uRXoUwFSAmQWI@myrica> (raw)
In-Reply-To: <20210325174807.GD15504@willie-the-truck>

On Thu, Mar 25, 2021 at 05:48:07PM +0000, Will Deacon wrote:
> > +/* smmu->streams_mutex must be held */
> 
> Can you add a lockdep assertion for that?

Sure

> > +__maybe_unused
> > +static struct arm_smmu_master *
> > +arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid)
> > +{
> > +	struct rb_node *node;
> > +	struct arm_smmu_stream *stream;
> > +
> > +	node = smmu->streams.rb_node;
> > +	while (node) {
> > +		stream = rb_entry(node, struct arm_smmu_stream, node);
> > +		if (stream->id < sid)
> > +			node = node->rb_right;
> > +		else if (stream->id > sid)
> > +			node = node->rb_left;
> > +		else
> > +			return stream->master;
> > +	}
> > +
> > +	return NULL;
> > +}
> 
> [...]
> 
> > +static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
> > +				  struct arm_smmu_master *master)
> > +{
> > +	int i;
> > +	int ret = 0;
> > +	struct arm_smmu_stream *new_stream, *cur_stream;
> > +	struct rb_node **new_node, *parent_node = NULL;
> > +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
> > +
> > +	master->streams = kcalloc(fwspec->num_ids, sizeof(*master->streams),
> > +				  GFP_KERNEL);
> > +	if (!master->streams)
> > +		return -ENOMEM;
> > +	master->num_streams = fwspec->num_ids;
> > +
> > +	mutex_lock(&smmu->streams_mutex);
> > +	for (i = 0; i < fwspec->num_ids; i++) {
> > +		u32 sid = fwspec->ids[i];
> > +
> > +		new_stream = &master->streams[i];
> > +		new_stream->id = sid;
> > +		new_stream->master = master;
> > +
> > +		/*
> > +		 * Check the SIDs are in range of the SMMU and our stream table
> > +		 */
> > +		if (!arm_smmu_sid_in_range(smmu, sid)) {
> > +			ret = -ERANGE;
> > +			break;
> > +		}
> > +
> > +		/* Ensure l2 strtab is initialised */
> > +		if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
> > +			ret = arm_smmu_init_l2_strtab(smmu, sid);
> > +			if (ret)
> > +				break;
> > +		}
> > +
> > +		/* Insert into SID tree */
> > +		new_node = &(smmu->streams.rb_node);
> > +		while (*new_node) {
> > +			cur_stream = rb_entry(*new_node, struct arm_smmu_stream,
> > +					      node);
> > +			parent_node = *new_node;
> > +			if (cur_stream->id > new_stream->id) {
> > +				new_node = &((*new_node)->rb_left);
> > +			} else if (cur_stream->id < new_stream->id) {
> > +				new_node = &((*new_node)->rb_right);
> > +			} else {
> > +				dev_warn(master->dev,
> > +					 "stream %u already in tree\n",
> > +					 cur_stream->id);
> > +				ret = -EINVAL;
> > +				break;
> > +			}
> > +		}
> > +		if (ret)
> > +			break;
> > +
> > +		rb_link_node(&new_stream->node, parent_node, new_node);
> > +		rb_insert_color(&new_stream->node, &smmu->streams);
> > +	}
> > +
> > +	if (ret) {
> > +		for (i--; i >= 0; i--)
> 
> Is 'i--' really what you want for the initial value? Doesn't that correspond
> to the ID you *didn't* add to the tree?

In case of error we break out of the loop, with i corresponding to the
stream that caused a fault but wasn't yet added to the tree. So i-- is
the last stream that was successfully added, or -1 in which case we don't
enter this for loop.

> > +			rb_erase(&master->streams[i].node, &smmu->streams);
> > +		kfree(master->streams);
> 
> Do you need to NULLify master->streams and/or reset master->num_streams
> after this? Seems like they're left dangling.

master is freed by arm_smmu_probe_device() when we return an error. Since
this function is unlikely to ever have another caller I didn't bother
cleaning up here

Thanks,
Jean
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Will Deacon <will@kernel.org>
Cc: joro@8bytes.org, vivek.gautam@arm.com, guohanjun@huawei.com,
	linux-acpi@vger.kernel.org, zhangfei.gao@linaro.org,
	lenb@kernel.org, devicetree@vger.kernel.org,
	kevin.tian@intel.com, robh+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
	iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
	robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org
Subject: Re: [PATCH v13 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure
Date: Fri, 26 Mar 2021 10:49:57 +0100	[thread overview]
Message-ID: <YF2uRXoUwFSAmQWI@myrica> (raw)
In-Reply-To: <20210325174807.GD15504@willie-the-truck>

On Thu, Mar 25, 2021 at 05:48:07PM +0000, Will Deacon wrote:
> > +/* smmu->streams_mutex must be held */
> 
> Can you add a lockdep assertion for that?

Sure

> > +__maybe_unused
> > +static struct arm_smmu_master *
> > +arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid)
> > +{
> > +	struct rb_node *node;
> > +	struct arm_smmu_stream *stream;
> > +
> > +	node = smmu->streams.rb_node;
> > +	while (node) {
> > +		stream = rb_entry(node, struct arm_smmu_stream, node);
> > +		if (stream->id < sid)
> > +			node = node->rb_right;
> > +		else if (stream->id > sid)
> > +			node = node->rb_left;
> > +		else
> > +			return stream->master;
> > +	}
> > +
> > +	return NULL;
> > +}
> 
> [...]
> 
> > +static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
> > +				  struct arm_smmu_master *master)
> > +{
> > +	int i;
> > +	int ret = 0;
> > +	struct arm_smmu_stream *new_stream, *cur_stream;
> > +	struct rb_node **new_node, *parent_node = NULL;
> > +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
> > +
> > +	master->streams = kcalloc(fwspec->num_ids, sizeof(*master->streams),
> > +				  GFP_KERNEL);
> > +	if (!master->streams)
> > +		return -ENOMEM;
> > +	master->num_streams = fwspec->num_ids;
> > +
> > +	mutex_lock(&smmu->streams_mutex);
> > +	for (i = 0; i < fwspec->num_ids; i++) {
> > +		u32 sid = fwspec->ids[i];
> > +
> > +		new_stream = &master->streams[i];
> > +		new_stream->id = sid;
> > +		new_stream->master = master;
> > +
> > +		/*
> > +		 * Check the SIDs are in range of the SMMU and our stream table
> > +		 */
> > +		if (!arm_smmu_sid_in_range(smmu, sid)) {
> > +			ret = -ERANGE;
> > +			break;
> > +		}
> > +
> > +		/* Ensure l2 strtab is initialised */
> > +		if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
> > +			ret = arm_smmu_init_l2_strtab(smmu, sid);
> > +			if (ret)
> > +				break;
> > +		}
> > +
> > +		/* Insert into SID tree */
> > +		new_node = &(smmu->streams.rb_node);
> > +		while (*new_node) {
> > +			cur_stream = rb_entry(*new_node, struct arm_smmu_stream,
> > +					      node);
> > +			parent_node = *new_node;
> > +			if (cur_stream->id > new_stream->id) {
> > +				new_node = &((*new_node)->rb_left);
> > +			} else if (cur_stream->id < new_stream->id) {
> > +				new_node = &((*new_node)->rb_right);
> > +			} else {
> > +				dev_warn(master->dev,
> > +					 "stream %u already in tree\n",
> > +					 cur_stream->id);
> > +				ret = -EINVAL;
> > +				break;
> > +			}
> > +		}
> > +		if (ret)
> > +			break;
> > +
> > +		rb_link_node(&new_stream->node, parent_node, new_node);
> > +		rb_insert_color(&new_stream->node, &smmu->streams);
> > +	}
> > +
> > +	if (ret) {
> > +		for (i--; i >= 0; i--)
> 
> Is 'i--' really what you want for the initial value? Doesn't that correspond
> to the ID you *didn't* add to the tree?

In case of error we break out of the loop, with i corresponding to the
stream that caused a fault but wasn't yet added to the tree. So i-- is
the last stream that was successfully added, or -1 in which case we don't
enter this for loop.

> > +			rb_erase(&master->streams[i].node, &smmu->streams);
> > +		kfree(master->streams);
> 
> Do you need to NULLify master->streams and/or reset master->num_streams
> after this? Seems like they're left dangling.

master is freed by arm_smmu_probe_device() when we return an error. Since
this function is unlikely to ever have another caller I didn't bother
cleaning up here

Thanks,
Jean

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-03-26  9:51 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02  9:26 [PATCH v13 00/10] iommu: I/O page faults for SMMUv3 Jean-Philippe Brucker
2021-03-02  9:26 ` Jean-Philippe Brucker
2021-03-02  9:26 ` Jean-Philippe Brucker
2021-03-02  9:26 ` [PATCH v13 01/10] iommu: Fix comment for struct iommu_fwspec Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-25 17:37   ` Will Deacon
2021-03-25 17:37     ` Will Deacon
2021-03-25 17:37     ` Will Deacon
2021-03-02  9:26 ` [PATCH v13 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-25 17:36   ` Will Deacon
2021-03-25 17:36     ` Will Deacon
2021-03-25 17:36     ` Will Deacon
2021-03-02  9:26 ` [PATCH v13 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-03  5:04   ` Lu Baolu
2021-03-03  5:04     ` Lu Baolu
2021-03-03  5:04     ` Lu Baolu
2021-03-02  9:26 ` [PATCH v13 04/10] iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26 ` [PATCH v13 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26 ` [PATCH v13 06/10] iommu: Add a page fault handler Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02 23:59   ` Jacob Pan
2021-03-02 23:59     ` Jacob Pan
2021-03-02 23:59     ` Jacob Pan
2021-03-23 10:50     ` Jean-Philippe Brucker
2021-03-23 10:50       ` Jean-Philippe Brucker
2021-03-23 10:50       ` Jean-Philippe Brucker
2021-03-03  5:27   ` Lu Baolu
2021-03-03  5:27     ` Lu Baolu
2021-03-03  5:27     ` Lu Baolu
2021-03-23 10:51     ` Jean-Philippe Brucker
2021-03-23 10:51       ` Jean-Philippe Brucker
2021-03-23 10:51       ` Jean-Philippe Brucker
2021-03-03  5:57   ` Raj, Ashok
2021-03-03  5:57     ` Raj, Ashok
2021-03-03  5:57     ` Raj, Ashok
2021-03-23 10:53     ` Jean-Philippe Brucker
2021-03-23 10:53       ` Jean-Philippe Brucker
2021-03-23 10:53       ` Jean-Philippe Brucker
2021-03-02  9:26 ` [PATCH v13 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02 12:24   ` Keqian Zhu
2021-03-02 12:24     ` Keqian Zhu
2021-03-02 12:24     ` Keqian Zhu
2021-03-25 17:48   ` Will Deacon
2021-03-25 17:48     ` Will Deacon
2021-03-25 17:48     ` Will Deacon
2021-03-26  9:49     ` Jean-Philippe Brucker [this message]
2021-03-26  9:49       ` Jean-Philippe Brucker
2021-03-26  9:49       ` Jean-Philippe Brucker
2021-03-02  9:26 ` [PATCH v13 08/10] dt-bindings: document stall property for IOMMU masters Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26 ` [PATCH v13 09/10] ACPI/IORT: Enable stall support for platform devices Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26 ` [PATCH v13 10/10] iommu/arm-smmu-v3: Add " Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-02  9:26   ` Jean-Philippe Brucker
2021-03-19 17:40   ` Auger Eric
2021-03-19 17:40     ` Auger Eric
2021-03-19 17:40     ` Auger Eric
2021-03-26  9:52   ` Auger Eric
2021-03-26  9:52     ` Auger Eric
2021-03-26  9:52     ` Auger Eric
2021-03-18  0:25 ` [PATCH v13 00/10] iommu: I/O page faults for SMMUv3 Krishna Reddy
2021-03-18  0:25   ` Krishna Reddy
2021-03-18  0:25   ` Krishna Reddy
2021-03-30 17:17 ` Jean-Philippe Brucker
2021-03-30 17:17   ` Jean-Philippe Brucker
2021-03-30 17:17   ` Jean-Philippe Brucker
2021-04-01  8:57   ` Will Deacon
2021-04-01  8:57     ` Will Deacon
2021-04-01  8:57     ` Will Deacon

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=YF2uRXoUwFSAmQWI@myrica \
    --to=jean-philippe@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-accelerators@lists.ozlabs.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=vivek.gautam@arm.com \
    --cc=will@kernel.org \
    --cc=zhangfei.gao@linaro.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 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.