* [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop
@ 2018-10-02 3:22 Alexey Kardashevskiy
2018-10-02 4:44 ` David Gibson
` (3 more replies)
0 siblings, 4 replies; 7+ messages in thread
From: Alexey Kardashevskiy @ 2018-10-02 3:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Alex Williamson, kvm-ppc, David Gibson
As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered
memory. If there is a bug in memory release, the loop in
tce_iommu_release() becomes infinite; this actually happened to me.
This makes the loop finite and prints a warning on every failure to make
the code more bug prone.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
drivers/vfio/vfio_iommu_spapr_tce.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
index b1a8ab3..ece0651 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -371,6 +371,7 @@ static void tce_iommu_release(void *iommu_data)
{
struct tce_container *container = iommu_data;
struct tce_iommu_group *tcegrp;
+ struct tce_iommu_prereg *tcemem, *tmtmp;
long i;
while (tce_groups_attached(container)) {
@@ -393,13 +394,8 @@ static void tce_iommu_release(void *iommu_data)
tce_iommu_free_table(container, tbl);
}
- while (!list_empty(&container->prereg_list)) {
- struct tce_iommu_prereg *tcemem;
-
- tcemem = list_first_entry(&container->prereg_list,
- struct tce_iommu_prereg, next);
- WARN_ON_ONCE(tce_iommu_prereg_free(container, tcemem));
- }
+ list_for_each_entry_safe(tcemem, tmtmp, &container->prereg_list, next)
+ WARN_ON(tce_iommu_prereg_free(container, tcemem));
tce_iommu_disable(container);
if (container->mm)
--
2.11.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop
2018-10-02 3:22 [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop Alexey Kardashevskiy
@ 2018-10-02 4:44 ` David Gibson
2018-10-03 18:17 ` Alex Williamson
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: David Gibson @ 2018-10-02 4:44 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Alex Williamson, linuxppc-dev, kvm-ppc
[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]
On Tue, Oct 02, 2018 at 01:22:31PM +1000, Alexey Kardashevskiy wrote:
> As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered
> memory. If there is a bug in memory release, the loop in
> tce_iommu_release() becomes infinite; this actually happened to me.
>
> This makes the loop finite and prints a warning on every failure to make
> the code more bug prone.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
It does improve the current behaviour. I do suspect, however, that
leaving the failed regions in the list will probably cause another
failure later on.
> ---
> drivers/vfio/vfio_iommu_spapr_tce.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> index b1a8ab3..ece0651 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -371,6 +371,7 @@ static void tce_iommu_release(void *iommu_data)
> {
> struct tce_container *container = iommu_data;
> struct tce_iommu_group *tcegrp;
> + struct tce_iommu_prereg *tcemem, *tmtmp;
> long i;
>
> while (tce_groups_attached(container)) {
> @@ -393,13 +394,8 @@ static void tce_iommu_release(void *iommu_data)
> tce_iommu_free_table(container, tbl);
> }
>
> - while (!list_empty(&container->prereg_list)) {
> - struct tce_iommu_prereg *tcemem;
> -
> - tcemem = list_first_entry(&container->prereg_list,
> - struct tce_iommu_prereg, next);
> - WARN_ON_ONCE(tce_iommu_prereg_free(container, tcemem));
> - }
> + list_for_each_entry_safe(tcemem, tmtmp, &container->prereg_list, next)
> + WARN_ON(tce_iommu_prereg_free(container, tcemem));
>
> tce_iommu_disable(container);
> if (container->mm)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop
2018-10-02 3:22 [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop Alexey Kardashevskiy
2018-10-02 4:44 ` David Gibson
@ 2018-10-03 18:17 ` Alex Williamson
2018-10-08 7:29 ` Serhii Popovych
2018-12-23 13:28 ` [RFC,kernel] " Michael Ellerman
3 siblings, 0 replies; 7+ messages in thread
From: Alex Williamson @ 2018-10-03 18:17 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, kvm-ppc, David Gibson
On Tue, 2 Oct 2018 13:22:31 +1000
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered
> memory. If there is a bug in memory release, the loop in
> tce_iommu_release() becomes infinite; this actually happened to me.
>
> This makes the loop finite and prints a warning on every failure to make
> the code more bug prone.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> drivers/vfio/vfio_iommu_spapr_tce.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
Should this have a stable/fixes tag? Looks like it's relevant to:
4b6fad7097f8 powerpc/mm/iommu, vfio/spapr: Put pages on VFIO container shutdown
Also, not sure who you're wanting to take this since it was sent to ppc
lists. If it's me, let me know, otherwise
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Thanks,
Alex
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> index b1a8ab3..ece0651 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -371,6 +371,7 @@ static void tce_iommu_release(void *iommu_data)
> {
> struct tce_container *container = iommu_data;
> struct tce_iommu_group *tcegrp;
> + struct tce_iommu_prereg *tcemem, *tmtmp;
> long i;
>
> while (tce_groups_attached(container)) {
> @@ -393,13 +394,8 @@ static void tce_iommu_release(void *iommu_data)
> tce_iommu_free_table(container, tbl);
> }
>
> - while (!list_empty(&container->prereg_list)) {
> - struct tce_iommu_prereg *tcemem;
> -
> - tcemem = list_first_entry(&container->prereg_list,
> - struct tce_iommu_prereg, next);
> - WARN_ON_ONCE(tce_iommu_prereg_free(container, tcemem));
> - }
> + list_for_each_entry_safe(tcemem, tmtmp, &container->prereg_list, next)
> + WARN_ON(tce_iommu_prereg_free(container, tcemem));
>
> tce_iommu_disable(container);
> if (container->mm)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop
2018-10-02 3:22 [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop Alexey Kardashevskiy
2018-10-02 4:44 ` David Gibson
2018-10-03 18:17 ` Alex Williamson
@ 2018-10-08 7:29 ` Serhii Popovych
2018-10-08 10:18 ` Michael Ellerman
2018-12-23 13:28 ` [RFC,kernel] " Michael Ellerman
3 siblings, 1 reply; 7+ messages in thread
From: Serhii Popovych @ 2018-10-08 7:29 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Alex Williamson, kvm-ppc, David Gibson
[-- Attachment #1.1: Type: text/plain, Size: 2107 bytes --]
Alexey Kardashevskiy wrote:
> As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered
> memory. If there is a bug in memory release, the loop in
> tce_iommu_release() becomes infinite; this actually happened to me.
>
> This makes the loop finite and prints a warning on every failure to make
> the code more bug prone.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> drivers/vfio/vfio_iommu_spapr_tce.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> index b1a8ab3..ece0651 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -371,6 +371,7 @@ static void tce_iommu_release(void *iommu_data)
> {
> struct tce_container *container = iommu_data;
> struct tce_iommu_group *tcegrp;
> + struct tce_iommu_prereg *tcemem, *tmtmp;
> long i;
>
> while (tce_groups_attached(container)) {
> @@ -393,13 +394,8 @@ static void tce_iommu_release(void *iommu_data)
> tce_iommu_free_table(container, tbl);
> }
>
> - while (!list_empty(&container->prereg_list)) {
> - struct tce_iommu_prereg *tcemem;
> -
> - tcemem = list_first_entry(&container->prereg_list,
> - struct tce_iommu_prereg, next);
> - WARN_ON_ONCE(tce_iommu_prereg_free(container, tcemem));
> - }
> + list_for_each_entry_safe(tcemem, tmtmp, &container->prereg_list, next)
> + WARN_ON(tce_iommu_prereg_free(container, tcemem));
I'm not sure that tce_iommu_prereg_free() call under WARN_ON() is good
idea because WARN_ON() is a preprocessor macro:
if CONFIG_WARN=n is added by the analogy with CONFIG_BUG=n defining
WARN_ON() as empty we will loose call to tce_iommu_prereg_free()
leaking resources.
There is no problem at the moment: WARN_ON() defined for PPC in
arch/powerpc/include/asm/bug.h unconditionally.
So your first version with intermediate variable looks better to me.
>
> tce_iommu_disable(container);
> if (container->mm)
>
--
Thanks,
Serhii
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop
2018-10-08 7:29 ` Serhii Popovych
@ 2018-10-08 10:18 ` Michael Ellerman
2018-12-19 4:44 ` Alexey Kardashevskiy
0 siblings, 1 reply; 7+ messages in thread
From: Michael Ellerman @ 2018-10-08 10:18 UTC (permalink / raw)
To: Serhii Popovych, Alexey Kardashevskiy, linuxppc-dev
Cc: Alex Williamson, kvm-ppc, David Gibson
Serhii Popovych <spopovyc@redhat.com> writes:
> Alexey Kardashevskiy wrote:
>> As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered
>> memory. If there is a bug in memory release, the loop in
>> tce_iommu_release() becomes infinite; this actually happened to me.
>>
>> This makes the loop finite and prints a warning on every failure to make
>> the code more bug prone.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> drivers/vfio/vfio_iommu_spapr_tce.c | 10 +++-------
>> 1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
>> index b1a8ab3..ece0651 100644
>> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
>> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
>> @@ -393,13 +394,8 @@ static void tce_iommu_release(void *iommu_data)
>> tce_iommu_free_table(container, tbl);
>> }
>>
>> - while (!list_empty(&container->prereg_list)) {
>> - struct tce_iommu_prereg *tcemem;
>> -
>> - tcemem = list_first_entry(&container->prereg_list,
>> - struct tce_iommu_prereg, next);
>> - WARN_ON_ONCE(tce_iommu_prereg_free(container, tcemem));
>> - }
>> + list_for_each_entry_safe(tcemem, tmtmp, &container->prereg_list, next)
>> + WARN_ON(tce_iommu_prereg_free(container, tcemem));
>
> I'm not sure that tce_iommu_prereg_free() call under WARN_ON() is good
> idea because WARN_ON() is a preprocessor macro:
>
> if CONFIG_WARN=n is added by the analogy with CONFIG_BUG=n defining
> WARN_ON() as empty we will loose call to tce_iommu_prereg_free()
> leaking resources.
I don't think that's likely to ever happen though, we have a large
number of uses that would need to be checked one-by-one:
$ git grep "if (WARN_ON(" | wc -l
2853
So if we ever did add CONFIG_WARN, I think it would still need to
evaluate the condition, just not emit a warning.
cheers
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop
2018-10-08 10:18 ` Michael Ellerman
@ 2018-12-19 4:44 ` Alexey Kardashevskiy
0 siblings, 0 replies; 7+ messages in thread
From: Alexey Kardashevskiy @ 2018-12-19 4:44 UTC (permalink / raw)
To: Michael Ellerman, Serhii Popovych, linuxppc-dev
Cc: Alex Williamson, kvm-ppc, David Gibson
On 08/10/2018 21:18, Michael Ellerman wrote:
> Serhii Popovych <spopovyc@redhat.com> writes:
>> Alexey Kardashevskiy wrote:
>>> As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered
>>> memory. If there is a bug in memory release, the loop in
>>> tce_iommu_release() becomes infinite; this actually happened to me.
>>>
>>> This makes the loop finite and prints a warning on every failure to make
>>> the code more bug prone.
>>>
>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>> ---
>>> drivers/vfio/vfio_iommu_spapr_tce.c | 10 +++-------
>>> 1 file changed, 3 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
>>> index b1a8ab3..ece0651 100644
>>> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
>>> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
>>> @@ -393,13 +394,8 @@ static void tce_iommu_release(void *iommu_data)
>>> tce_iommu_free_table(container, tbl);
>>> }
>>>
>>> - while (!list_empty(&container->prereg_list)) {
>>> - struct tce_iommu_prereg *tcemem;
>>> -
>>> - tcemem = list_first_entry(&container->prereg_list,
>>> - struct tce_iommu_prereg, next);
>>> - WARN_ON_ONCE(tce_iommu_prereg_free(container, tcemem));
>>> - }
>>> + list_for_each_entry_safe(tcemem, tmtmp, &container->prereg_list, next)
>>> + WARN_ON(tce_iommu_prereg_free(container, tcemem));
>>
>> I'm not sure that tce_iommu_prereg_free() call under WARN_ON() is good
>> idea because WARN_ON() is a preprocessor macro:
>>
>> if CONFIG_WARN=n is added by the analogy with CONFIG_BUG=n defining
>> WARN_ON() as empty we will loose call to tce_iommu_prereg_free()
>> leaking resources.
>
> I don't think that's likely to ever happen though, we have a large
> number of uses that would need to be checked one-by-one:
>
> $ git grep "if (WARN_ON(" | wc -l
> 2853
>
>
> So if we ever did add CONFIG_WARN, I think it would still need to
> evaluate the condition, just not emit a warning.
Is anyone taking this?
--
Alexey
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC,kernel] vfio/spapr_tce: Get rid of possible infinite loop
2018-10-02 3:22 [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop Alexey Kardashevskiy
` (2 preceding siblings ...)
2018-10-08 7:29 ` Serhii Popovych
@ 2018-12-23 13:28 ` Michael Ellerman
3 siblings, 0 replies; 7+ messages in thread
From: Michael Ellerman @ 2018-12-23 13:28 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Alexey Kardashevskiy, Alex Williamson, kvm-ppc, David Gibson
On Tue, 2018-10-02 at 03:22:31 UTC, Alexey Kardashevskiy wrote:
> As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered
> memory. If there is a bug in memory release, the loop in
> tce_iommu_release() becomes infinite; this actually happened to me.
>
> This makes the loop finite and prints a warning on every failure to make
> the code more bug prone.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> Acked-by: Alex Williamson <alex.williamson@redhat.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/517ad4ae8aa93dccdb9a88c27257ec
cheers
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-12-23 14:19 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-02 3:22 [RFC PATCH kernel] vfio/spapr_tce: Get rid of possible infinite loop Alexey Kardashevskiy
2018-10-02 4:44 ` David Gibson
2018-10-03 18:17 ` Alex Williamson
2018-10-08 7:29 ` Serhii Popovych
2018-10-08 10:18 ` Michael Ellerman
2018-12-19 4:44 ` Alexey Kardashevskiy
2018-12-23 13:28 ` [RFC,kernel] " Michael Ellerman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).