From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Gerald Schaefer
<gerald.schaefer-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>,
Sebastian Ott
<sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/2] iommu/s390: Fix IOMMU groups
Date: Thu, 27 Apr 2017 23:12:32 +0200 [thread overview]
Message-ID: <20170427211232.GF1332@8bytes.org> (raw)
In-Reply-To: <20170427201142.18d467a3@thinkpad>
On Thu, Apr 27, 2017 at 08:11:42PM +0200, Gerald Schaefer wrote:
> > +void zpci_destroy_iommu(struct zpci_dev *zdev)
> > +{
> > + iommu_group_put(zdev->group);
> > + zdev->group = NULL;
> > +}
>
> While the rest of this patch doesn't seem to make much of a difference to
> the current behavior, I'm wondering where this extra iommu_group_put()
> comes from. It either was erroneously missing before this patch, or it
> is erroneously introduced by this patch.
This is the way to free an iommu-group. It was missing before probably
because it was unclear whether the add_device function allocated a group
or not. So there was no way to know if it needs to be put again in the
remove_device function.
With this patch the iommu-group is explicitly allocated when the
zpci_dev is created and destroyed again with it.
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
Joerg Roedel <jroedel@suse.de>
Subject: Re: [PATCH 1/2] iommu/s390: Fix IOMMU groups
Date: Thu, 27 Apr 2017 23:12:32 +0200 [thread overview]
Message-ID: <20170427211232.GF1332@8bytes.org> (raw)
In-Reply-To: <20170427201142.18d467a3@thinkpad>
On Thu, Apr 27, 2017 at 08:11:42PM +0200, Gerald Schaefer wrote:
> > +void zpci_destroy_iommu(struct zpci_dev *zdev)
> > +{
> > + iommu_group_put(zdev->group);
> > + zdev->group = NULL;
> > +}
>
> While the rest of this patch doesn't seem to make much of a difference to
> the current behavior, I'm wondering where this extra iommu_group_put()
> comes from. It either was erroneously missing before this patch, or it
> is erroneously introduced by this patch.
This is the way to free an iommu-group. It was missing before probably
because it was unclear whether the add_device function allocated a group
or not. So there was no way to know if it needs to be put again in the
remove_device function.
With this patch the iommu-group is explicitly allocated when the
zpci_dev is created and destroyed again with it.
Joerg
next prev parent reply other threads:[~2017-04-27 21:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-27 15:28 [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support Joerg Roedel
2017-04-27 15:28 ` Joerg Roedel
[not found] ` <1493306905-32334-1-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-27 15:28 ` [PATCH 1/2] iommu/s390: Fix IOMMU groups Joerg Roedel
2017-04-27 15:28 ` Joerg Roedel
[not found] ` <1493306905-32334-2-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-27 18:11 ` Gerald Schaefer
2017-04-27 18:11 ` Gerald Schaefer
2017-04-27 21:12 ` Joerg Roedel [this message]
2017-04-27 21:12 ` Joerg Roedel
[not found] ` <20170427211232.GF1332-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-28 13:20 ` Gerald Schaefer
2017-04-28 13:20 ` Gerald Schaefer
2017-04-28 14:40 ` Joerg Roedel
2017-04-28 14:40 ` Joerg Roedel
2017-04-28 17:50 ` kbuild test robot
2017-04-28 17:50 ` kbuild test robot
2017-04-27 15:28 ` [PATCH 2/2] iommu/s390: Add support for iommu_device handling Joerg Roedel
2017-04-27 15:28 ` Joerg Roedel
[not found] ` <1493306905-32334-3-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-28 23:02 ` kbuild test robot
2017-04-28 23:02 ` kbuild test robot
2017-04-27 18:10 ` [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support Gerald Schaefer
2017-04-27 18:10 ` Gerald Schaefer
2017-04-27 21:03 ` Joerg Roedel
2017-04-27 21:03 ` Joerg Roedel
[not found] ` <20170427210325.GE1332-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-28 12:46 ` Gerald Schaefer
2017-04-28 12:46 ` Gerald Schaefer
2017-04-28 14:55 ` Joerg Roedel
2017-04-28 14:55 ` Joerg Roedel
[not found] ` <20170428145513.GH1332-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-28 15:25 ` Sebastian Ott
2017-04-28 15:25 ` Sebastian Ott
[not found] ` <alpine.LFD.2.20.1704281709350.1788-+lzQMq5bIdMXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2017-04-28 22:29 ` Joerg Roedel
2017-04-28 22:29 ` Joerg Roedel
2017-04-28 18:06 ` Gerald Schaefer
2017-04-28 18:06 ` Gerald Schaefer
2017-04-28 22:40 ` Joerg Roedel
2017-04-28 22:40 ` Joerg Roedel
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=20170427211232.GF1332@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=gerald.schaefer-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jroedel-l3A5Bk7waGM@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.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.