Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e1c50a59-f85a-02bc-6b48-fceaa390b2ad@nvidia.com>
Date:   Wed, 10 May 2023 10:19:58 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [PATCH v3 3/3] genirq: Use the maple tree for IRQ descriptors
 management
Content-Language: en-US
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Yujie Liu <yujie.liu@intel.com>, oe-lkp@lists.linux.dev,
        lkp@intel.com, linux-kernel@vger.kernel.org,
        Marc Zyngier <maz@kernel.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Michael Walle <michael@walle.cc>,
        Vikram Sethi <vsethi@nvidia.com>
References: <202304251035.19367560-yujie.liu@intel.com> <87a5yuzvzd.ffs@tglx>
 <ZEsiYbi8dorXTI5t@yujie-X299> <877ctw5mdp.ffs@tglx>
 <ZFdbtipfTsIF0u6z@yujie-X299> <87mt2f2mhm.ffs@tglx>
 <ZFtGvfDFLyHeFVFH@yujie-X299> <87ttwkxn96.ffs@tglx> <87r0roxmvu.ffs@tglx>
From:   Shanker Donthineni <sdonthineni@nvidia.com>
In-Reply-To: <87r0roxmvu.ffs@tglx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZU43SFB4am9IWUNIaXRtcVd6YklxQUI2L1dyQmVQUVJFdmFDc3FLOGNoMHRW?=
 =?utf-8?B?SDIxZUdKT2RoUUx3VWpCa2RYREhSdUp4T0RrQlMzUEVreXF5Y0dpc0lRanZU?=
 =?utf-8?B?dTU3cFNEUnN0NzJhUUU3VnJib2lHZUI4RzhEamN5SzUzNU5lMVN4aTV4Zllu?=
 =?utf-8?B?Um05emd4V0hvVEwrZ0x5R2JjZVM1V3A5dytpRGZDTyszWEFKWGJmU1RMaFBo?=
 =?utf-8?B?a3ZkdGN4NGVudXZHbmhUZlhhNUZ4TE1MTlJWVndWSERIUWd3a3JPd29qSkZ6?=
 =?utf-8?B?YmNuT01CWG1BN2pFV0hLbzRULzdwSlIweXYvcUlZZHNJK0ZWTzVFL1hXLzRl?=
 =?utf-8?B?b2lxVnIwQkNLSW9HWXNYVEhQaVVZUDlVRTdTaG4rRUFKVHhET3JyRjNYZ3RJ?=
 =?utf-8?B?V3VUcmgrSDAxRUdSS2VCMXVXZHNGdkhOK3k5alM4OXRVUDBsMHVwbGFDbmFE?=
 =?utf-8?B?OHByYVFNN1NDbU1Ha0RUL2x3NXJoOFdyQm13dGdQM2hJZXlWVENiZkFlMlp5?=
 =?utf-8?B?NjN3b0lpdVFweXcramdPM1djNTQyRUhVajExZDlnU1pFNTJ6SUpwUUtSakhv?=
 =?utf-8?B?aUhURk0rbXdSOHZiU014ejRXNGVOSlAyYjh5MTUyZGRJVjhWVEMzbGJmeW54?=
 =?utf-8?B?cW9FZGdNM1hJa3VyeCtlUDRmMzIwbG9XYW53Q3pGYWN6MWNKUGdqUDMrZnl0?=
 =?utf-8?B?QU9xcytKb0lFalF6bkZIdkdsd0UvY3JpOE9iMGYxUGlNT0xoSjJBRkVzMW81?=
 =?utf-8?B?M2lzcVZVdUtBeGR5bkFQRlZyVGJiYmhKN1kvc3JWcjJ1TWRpVXdkaUxheUE1?=
 =?utf-8?B?Wm5TallLNzMzK2szNmJrd3RkaURWdm5MOUFSc0Q5dGxCeXZ6ZTd4cSt5Q3c4?=
 =?utf-8?B?RnR1cEYvYTA3bWNDU08zcVlJTkY4akRtSW9jekFZZEVFRG95Snk5YmRFVTJk?=
 =?utf-8?B?VnYzYmJneFU3dnRYclFhbHVBaUJDUEREQmhjYkJyck4wQnlkR0ZCam5QMC9F?=
 =?utf-8?B?MFhKeGNLc1d6NC9icVE2cXJkYlpmTTFFVzVlUk13VFhQYlNrbjgyRXI2bVhS?=
 =?utf-8?B?cEZjcU9GeE5uR3hVWDRrTFJFcVFyTkN4aUx2eUlqZXhPbEtXSmYzd1pXUk5Q?=
 =?utf-8?B?UG1lSlh0bWc1Q0JQL1BYZHBqZEdvUm50bm5UcURDVHhvZWdYTy9taGU3eUpq?=
 =?utf-8?B?TnZzSEExendZL1U1dWJRRTlLWEhxZzhCd3RjSVV1L2tpNlpRYVVuQ2NzbGRO?=
 =?utf-8?B?MGdHckgrcHFETEZaMFJITTlHemNzU2MzVFZQVUJUVFh0bWJEKzI4dHNlaXRT?=
 =?utf-8?B?cHo4c0hSRUlHZFQrN3NjZ1ZVNkVLY2pOb0xKN1BhSnNhWkM1b1RxaXlvQ0Rx?=
 =?utf-8?B?MENKME0wTStnV1pieWlJak5VV2dTa2F3VUllcFJVOFpNS2VINXY5bm9QVktG?=
 =?utf-8?B?bGZyNlA4WEw4alJBcDNXaWFHUTYzSmUxN3FGaFZ0V0Uzc05BRDJNM3V6SG0z?=
 =?utf-8?B?MzA5SlNaZTVGRXdIc2wxekZWNE5WWVIyY25iVTIzSFpReVNFN3dHUElCQlRJ?=
 =?utf-8?B?azBnTTVkM3IxTmQvcmRydUM1ZnJlVUFVUFVsNFh0elhWZFlqR1BEOE5NdWls?=
 =?utf-8?B?UStQa2gySmdtTUFVV01iR29BVkRGd3l1ZmhycW9oVG5lOFhzT1dIdXRHeWlE?=
 =?utf-8?B?b2lIZ1ZRRFRyUzhpUGE5blVKN0MrOFZvMFM4MzZwWjUycDNxajNwNmFJM3I0?=
 =?utf-8?B?L01CWTI5OTF5OE5FaVB5TzlCWXRhVW5uYVlzZUF5Ym1JSnErOUlUSHNiclJ2?=
 =?utf-8?B?OWpFNzlUT3dITWFOYlFpNWF0TERCSDkzZUNCSWQ4anRML05pUXlYaENlWWR6?=
 =?utf-8?B?MFNkRzM4d0ZyUTI2UlArUThlS3VWMXo4TGpsdzB6UFpweHdEV3ptbEpkRFpI?=
 =?utf-8?B?UlBlVHByVG5yRG1aaUF3ZFhUNWRWeWFMSFYrRkN2SWJXOGJUaU9kUVhoQmc5?=
 =?utf-8?B?YVJmMEVOdDFza3NVRzNxckhiYkNhZU1vb0JRNURXZ2Y3bTE0VHp4RGZIT2hC?=
 =?utf-8?B?YkVrMlRyb2M2ZWMrWmUvWExUV0hBL216dDNjUkZXR2V3NENuQVlwbVVSWmtU?=
 =?utf-8?Q?sCPoAzjchskE5B0YA/CwiiV8j?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b6efb169-85e5-485f-125d-08db516a05d7
X-MS-Exchange-CrossTenant-AuthSource: MN0PR12MB5762.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2023 15:20:01.1310
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: GXOUIuSqNvc9s/htxZv3K/KkAqh9+MAiudIkh6HE3YGC17zM4anOK9fWc0s2FgQfRkYmNv4ZNsImHdT05qrkuw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4581
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,
        SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


Hi Thomas & Marc,


Apologies for my lack of familiarity with the maple tree data structure and
not testing all functions. I received advice from the review comments below
regarding the iterator. I am looking for your guidance to address the issue
with the iterator if not possible can we increase NR_IRQS for ARM64 arch.


https://lore.kernel.org/linux-arm-kernel/875ydej9ur.ffs@tglx/

static unsigned int irq_find_next_irq(unsigned int offset)
{
         MA_STATE(mas, &sparse_irqs, offset, nr_irqs);
         struct irq_desc *desc = mas_next(&mas, nr_irqs);

         return desc ? irq_desc_get_irq(desc) : nr_irqs;
}

-Shanker

On 5/10/23 09:49, Thomas Gleixner wrote:
> External email: Use caution opening links or attachments
> 
> 
> Shanker!
> 
> On Wed, May 10 2023 at 16:41, Thomas Gleixner wrote:
>> On Wed, May 10 2023 at 15:24, Yujie Liu wrote:
>> I decoded it by now and that maple_tree conversion is the culprit. It
>> broke irq_get_next_irq() which is used during hotplug. It misses every
>> other interrupt, so affinities are not fixed up.
> 
> I'm seriously grumpy. You throw that untested stuff over the fence,
> pester me about merging it and then ignore the fallout.
> 
> This breaks cpuhotplug, debugfs, /proc/stat, x86/IOAPIC and some more.
> 
> It's not asked too much that if you change an iterator implementation to
> validate that the outcome is still the same on the usage sites.
> 
> That change has never seen CPU hotplug testing. It reproduces
> instantaneously in a VM even without running blktest.
> 
> I grant you that the documentation of mt_next() is incorrect, but that's
> absolutely no excuse for not testing such a fundamental change at
> all. It's neither an excuse for ignoring the fallout and wasting other
> peoples time.
> 
> I'm dropping this from my to-merge list.
> 
> Yours grumpy
> 
>        Thomas