Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 2/3] genirq/irqdomain: Re-check mapping after associate in
 irq_create_mapping()
To:     Marc Zyngier <maz@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Grant Likely <grant.likely@secretlab.ca>
Cc:     Mark Brown <broonie@opensource.wolfsonmicro.com>,
        Jon Hunter <jonathanh@nvidia.com>,
        "Glavinic-Pecotic, Matija (EXT - DE/Ulm)" 
        <matija.glavinic-pecotic.ext@nokia.com>,
        "Adamski, Krzysztof (Nokia - PL/Wroclaw)" 
        <krzysztof.adamski@nokia.com>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
References: <20190912094343.5480-1-alexander.sverdlin@nokia.com>
 <20190912094343.5480-3-alexander.sverdlin@nokia.com>
 <2c02b9d5-2394-7dcb-ee89-9950c6071dd1@kernel.org>
From:   Alexander Sverdlin <alexander.sverdlin@nokia.com>
Message-ID: <39bcb24e-9e30-6932-be38-b9f2962734fc@nokia.com>
Date:   Wed, 8 Jan 2020 16:07:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.1
In-Reply-To: <2c02b9d5-2394-7dcb-ee89-9950c6071dd1@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Received-SPF: None (protection.outlook.com: nokia.com does not designate
 permitted sender hosts)
X-MS-Exchange-CrossTenant-Network-Message-Id: dcf61354-bc75-4e52-1a4a-08d7944c809b
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2020 15:07:39.4047
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bOHhTTGpienlHID+XJBYnRRs/H/2141E2gfbzCosn23zub3T2ENAiXj1nwsPH+oxU6js5Fk4VY7wCvQrxVBWYJr6Dxk6Yrif/5SmTbjrM/Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6013
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello Marc,

On 20/09/2019 17:52, Marc Zyngier wrote:
> On 12/09/2019 10:44, Sverdlin, Alexander (Nokia - DE/Ulm) wrote:
>> From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
>>
>> If two irq_create_mapping() calls perform a mapping of the same hwirq on
>> two CPU cores in parallel they both will get 0 from irq_find_mapping(),
>> both will allocate unique virq using irq_domain_alloc_descs() and both
>> will finally irq_domain_associate() it. Giving different virq numbers
>> to their callers.
>>
>> In practice the first caller is usually an interrupt controller driver and
>> the seconds is some device requesting the interrupt providede by the above
>> interrupt controller.
> I disagree with this "In practice". An irqchip controller should *very
> rarely* call irq_create_mapping on its own. It usually indicates some
> level of brokenness, unless the mapped interrupt is exposed by the
> irqchip itself (the GIC maintenance interrupt, for example).
> 
>> In this case either the interrupt controller driver configures virq which
>> is not the one being "associated" with hwirq, or the "slave" device
>> requests the virq which is never being triggered.
> Why should the interrupt controller configure that interrupt? On any
> sane platform, the mapping should be created by the user of the
> interrupt, and not by the provider.
> 
> This doesn't mean we shouldn't fix the irqdomain races, but I tend to
> disagree with the analysis here.

would you have time to review v2 of this series?

-- 
Best regards,
Alexander Sverdlin.