lkml.org 
[lkml]   [2022]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/2] genirq: Record dangling hwirq number into struct irq_data
From


在 2022/8/25 16:27, Andy Shevchenko 写道:
> On Thu, Aug 25, 2022 at 9:11 AM Liao Chang <liaochang1@huawei.com> wrote:
>
> Use spell-checker, please. Or ask somebody for proof-reading of your
> commit messages and comments in the code.
>
>> Following interrupt allocation process lead to some interrupts are
>
> leads
>
>> mapped in the low-level domain(Arm ITS), but they are never been mapped
>
> never mapped
> ...or...
> they have never
>
>> at the higher level.
>>
>> irq_domain_alloc_irqs_hierarchy(.., nr_irqs, ...)
>> its_irq_domain_alloc(..., nr_irqs, ...)
>> its_alloc_device_irq(..., nr_irqs, ...)
>> bitmap_find_free_region(..., get_count_order(nr_irqs))
>>
>> Since ITS domain find a region of zero bits, the length of which must
>
> finds
>
>> aligned to power of two. If nr_irqs is 30, the length of zero bits is
>
> the power
>
>> actually 32, but only first 30 bits are really mapped.
>
> the first
>
>> On teardown, low-level domain only free these interrupts that actually
>
> the low-level
> ...or...
> domains
>
>> mapped, and leave last interrupts dangling in the ITS domain. Thus the
>> ITS device resources are never freed. On device driver reload, dangling
>> interrupts prevent ITS domain from allocating enough resource.
>>
>> irq_domain_free_irqs_hierarchy(..., nr_irqs, ...)
>> its_irq_domain_free(..., irq_base + i, 1)
>> bitmap_release_region(..., irq_base + i, get_count_order(1))
>>
>> John reported this problem to LKML and Marc provided a solution and fix
>> it in the generic code, see the discussion from Link tag. Marc's patch
>> fix John's problem, but does not take care of some corner case, look one
>> example below.
>>
>> Step1: 32 interrupts allocated in LPI domain, but return the first 30 to
>> higher driver.
>>
>> 111111111111111111111111111111 11
>> |<------------0~29------------>|30,31|
>>
>> Step2: interrupt #16~28 are released one by one, then #0~15 and #29~31
>> still be there.
>>
>> 1111111111111111 0000000000000 1 11
>> |<-----0~15----->|<---16~28--->|29|30,31|
>>
>> Step#: on driver teardown, generic code will invoke ITS domain code
>> twice. The first time, #0~15 will be released, the second one, only #29
>> will be released(1 align to power of two).
>>
>> 0000000000000000 0000000000000 0 11
>> |<-----0~15----->|<---16~28--->|29|30,31|
>>
>> In short summary, the dangling problem stems from the number of released
>> hwirq is less than the one of allocated hwirq in ITS domain. In order to
>
> the allocated
>
>> fix this problem, make irq_data record the number of allocated but
>> unmapped hwirq. If hwirq followed by some unmapped bits, ITS domain
>> record the number of unmapped bits to the last irq_data mapped to higher
>> level, when the last hwirq followed by unmapped hwirq is released, some
>> dangling bit will be clear eventualy, look back the trivial example
>
> eventually
>
>> above.
>>
>> Step1: record '2' into the irq_data.dangling of #29 hwirq.
>>
>> 111111111111111111111111111111 11
>> |<------------0~29------------>|30,31|
>> dangling: 000000000000000000000000000002
>>
>> Step2: no change
>>
>> 1111111111111111 0000000000000 1 11
>> |<-----0~15----->|<---16~28--->|29|30,31|
>> dangling: 0000000000000000 0000000000000 2
>>
>> Step3: ITS domain will release #30~31 since the irq_data.dangling of #29
>> is '2'.
>>
>> 0000000000000000 0000000000000 0 00
>> |<-----0~15----->|<---16~28--->|29|30,31|
>> dangling: 0000000000000000 0000000000000 2
>
>> Fixes: 4615fbc3788dd ("genirq/irqdomain: Don't try to free an interrupt
>> that has no mapping")
>
> All tags must be one-liners. I.o.w. do not split a tag to multiple lines.
>
> ...
>
>> + * @dangling: amount of dangling hardware interrupt, Arm ITS allocate
>> + * hardware interrupt more than expected, aligned to power
>> + * of two, so that unsued interrupt number become dangling.
>
> unused
> becomes
>
>> + * Use this field to record dangling bits follwoing @hwirq.
>
> following
>
Appreciate for your help, i will correct them.

--
BR,
Liao, Chang

\
 
 \ /
  Last update: 2022-08-25 10:35    [W:0.058 / U:0.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site