Re: vfio: powerpc/spapr: One function call less in tce_iommu_attach_group() after kzalloc() failure
On 06/30/2015 04:08 PM, SF Markus Elfring wrote: than the existing one should have been renamed to "free_exit" or "free_unlock_exit" and new one would be "unlock_exit". I chose a smaller change at this place. I'd just drop this patch. How do you think about to improve the affected jump labels a bit more there? This branch is very unlikely to work ever so I cannot think of any improvement here. -- Alexey -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vfio: powerpc/spapr: One function call less in tce_iommu_attach_group() after kzalloc() failure
>>> than the existing one should have been renamed to "free_exit" or >>> "free_unlock_exit" >>> and new one would be "unlock_exit". >> >> I chose a smaller change at this place. > > I'd just drop this patch. How do you think about to improve the affected jump labels a bit more there? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vfio: powerpc/spapr: One function call less in tce_iommu_attach_group() after kzalloc() failure
On 06/29/2015 04:02 PM, SF Markus Elfring wrote: tcegrp will be NULL and kfree() can handle this just fine The affected function did not show this API knowledge, did it? but you fixed this in 1/2 :) (is not it the whole point of this patchset - remove the check and just call kfree() even if the pointer is NULL?). Partly, yes. And if you wanted another label, I suggest this to improve corresponding exception handling. than the existing one should have been renamed to "free_exit" or "free_unlock_exit" and new one would be "unlock_exit". I chose a smaller change at this place. I'd just drop this patch. I am not familiar enough with other called functions there at the moment. Are the remaining goto statements also update candidates? -- Alexey -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vfio: powerpc/spapr: One function call less in tce_iommu_attach_group() after kzalloc() failure
> tcegrp will be NULL and kfree() can handle this just fine The affected function did not show this API knowledge, did it? > (is not it the whole point of this patchset > - remove the check and just call kfree() even if the pointer is NULL?). Partly, yes. > And if you wanted another label, I suggest this to improve corresponding exception handling. > than the existing one should have been renamed to "free_exit" or > "free_unlock_exit" > and new one would be "unlock_exit". I chose a smaller change at this place. I am not familiar enough with other called functions there at the moment. Are the remaining goto statements also update candidates? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] vfio: powerpc/spapr: One function call less in tce_iommu_attach_group() after kzalloc() failure
On 06/29/2015 02:24 AM, SF Markus Elfring wrote:
From: Markus Elfring
Date: Sun, 28 Jun 2015 17:58:42 +0200
The kfree() function was called even if a previous memory allocation
try failed.
tcegrp will be NULL and kfree() can handle this just fine (is not it the
whole point of this patchset - remove the check and just call kfree() even
if the pointer is NULL?). And if you wanted another label, than the
existing one should have been renamed to "free_exit" or "free_unlock_exit"
and new one would be "unlock_exit".
This implementation detail could be improved by the introduction
of another jump label.
Signed-off-by: Markus Elfring
---
drivers/vfio/vfio_iommu_spapr_tce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 50ddfac..2523075 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -1200,7 +1200,7 @@ static int tce_iommu_attach_group(void *iommu_data,
tcegrp = kzalloc(sizeof(*tcegrp), GFP_KERNEL);
if (!tcegrp) {
ret = -ENOMEM;
- goto unlock_exit;
+ goto unlock_container;
}
if (!table_group->ops || !table_group->ops->take_ownership ||
@@ -1217,7 +1217,7 @@ static int tce_iommu_attach_group(void *iommu_data,
unlock_exit:
if (ret)
kfree(tcegrp);
-
+unlock_container:
mutex_unlock(&container->lock);
return ret;
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] vfio: powerpc/spapr: One function call less in tce_iommu_attach_group() after kzalloc() failure
From: Markus Elfring
Date: Sun, 28 Jun 2015 17:58:42 +0200
The kfree() function was called even if a previous memory allocation
try failed.
This implementation detail could be improved by the introduction
of another jump label.
Signed-off-by: Markus Elfring
---
drivers/vfio/vfio_iommu_spapr_tce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 50ddfac..2523075 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -1200,7 +1200,7 @@ static int tce_iommu_attach_group(void *iommu_data,
tcegrp = kzalloc(sizeof(*tcegrp), GFP_KERNEL);
if (!tcegrp) {
ret = -ENOMEM;
- goto unlock_exit;
+ goto unlock_container;
}
if (!table_group->ops || !table_group->ops->take_ownership ||
@@ -1217,7 +1217,7 @@ static int tce_iommu_attach_group(void *iommu_data,
unlock_exit:
if (ret)
kfree(tcegrp);
-
+unlock_container:
mutex_unlock(&container->lock);
return ret;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
