From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD7CFC4332F for ; Wed, 23 Feb 2022 22:30:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243829AbiBWWb0 (ORCPT ); Wed, 23 Feb 2022 17:31:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbiBWWbZ (ORCPT ); Wed, 23 Feb 2022 17:31:25 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2570240A16; Wed, 23 Feb 2022 14:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645655457; x=1677191457; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=xiuVkpU2Aoy7KyoYrr+wL4tziSAElrqPACskTUdyFZY=; b=TwsmLqbvRIoiTKwvLFabgwug2cYybLnmZlOmsEzW/NAsxj7B8Rwx2+vW ItLxufe1xnqhCsVRbw+CJzoDq9yGAK2BeUTExaCc70A9UxNYrqVGSvyIn xKNRV4KixYOrrqyo0tGK8ZrX5IdCIrDYnyahnchQJUEP5qC1HBrVysNKo LJugWBiVsJjdzz7czOtfk1q8xIA2dkuFtuaDEAi/k0nnTe51X5HIlavsM 45915LDRrdNdY2csU8LGLHpMTQ0Slj/7d0BRYyl4ATNA20Swi6RDQ1z8X 3tUISuH6XLhfSQ0acxc1j2B0fUWS0lQ8kWiiRYMX6exjvWpnss2fS4lMn A==; X-IronPort-AV: E=McAfee;i="6200,9189,10267"; a="249675361" X-IronPort-AV: E=Sophos;i="5.88,392,1635231600"; d="scan'208";a="249675361" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2022 14:30:57 -0800 X-IronPort-AV: E=Sophos;i="5.88,392,1635231600"; d="scan'208";a="628251199" Received: from smile.fi.intel.com ([10.237.72.59]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2022 14:30:55 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nN096-007az1-Vh; Thu, 24 Feb 2022 00:30:04 +0200 Date: Thu, 24 Feb 2022 00:30:04 +0200 From: 'Andy Shevchenko' To: David Laight Cc: Jason Gunthorpe , "linux-rdma@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Mike Marciniszyn , Dennis Dalessandro Subject: Re: [PATCH v1 1/1] IB/hfi1: Don't cast parameter in bit operations Message-ID: References: <20220223185353.51370-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 23, 2022 at 09:44:32PM +0000, David Laight wrote: > From: Andy Shevchenko > > Sent: 23 February 2022 18:54 > > > > While in this particular case it would not be a (critical) issue, > > the pattern itself is bad and error prone in case somebody blindly > > copies to their code. > > It is horribly wrong on BE systems. You mean the pattern? Yes, it has three issues regarding to endianess and potential out of boundary access. ... > > - return handled; > > + return IRQ_RETVAL(!bitmap_empty(pending, CCE_NUM_INT_CSRS * 64)); > You really don't want to scan the bitmap again. Either way it wastes cycles, the outcome depends on the actual distribution of the interrupts across the bitmap. If it gathered closer to the beginning of the bitmap, my code wins, otherwise the original ones. > Actually, of the face of it, you could merge the two loops. > Provided you clear the status bit before calling the relevant > handler I expect it will all work. True. I will consider that for v2. -- With Best Regards, Andy Shevchenko