Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1086182pxm; Wed, 23 Feb 2022 17:46:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJxYe7lyz6xDn/D/A4zmvuINXseeV1e0PfWPJZKAWx8EbKe/U4M1ExUefwpCuLTVS0KkXwiW X-Received: by 2002:a05:6a00:bd7:b0:4f1:335c:8881 with SMTP id x23-20020a056a000bd700b004f1335c8881mr467475pfu.61.1645667179573; Wed, 23 Feb 2022 17:46:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645667179; cv=none; d=google.com; s=arc-20160816; b=eiGQSABnohRzi9LR4wO3bOyk4rI1Kw6SpMmfUjYBkJyZiuA+9grkpqpk1ADiyS2YVx BjFxc3GtNwu+xCGW/XnDJEMPCy5ESrFwVao5vXE08HdnpHajinAQJNM5FgbJJW+INry8 WCkjmKOJZq8nBu6WxVJgjtnngtt1gWiQwE+dzTGaPDDy6ZMlTzTL23h7nOUSnqdcf9RH UxeJASE+REYb/d54T+gw0xeBbRs91+MJ0IAMD1/baxoFlHg3OS2p1ScN+bBXtsblv0ZX NUCtsrl5R1iQMkwhdvyWugcS3Q/lc1N9D+kJIsqfdMhSWndznOFdHflmSajiiU5v4ElD 0dfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=dKEHIeYeoo2W3UQiSPhdnB8WqLdc3pWZDGVw9UCUamY=; b=K1I4tHrtzbgHFNjOBQlRilmStQmyaUR3ZYvAu60v91QOnAUA5kaFl0YCpOrckX7a3E fzb0cqlPsJECetRbekjKnZEoD5TamKdQezxnnchL7QJJ7YfYZPJhVvKUdSOoAhiYsy7n 5uigJeaRhW9vmlvEuwQm30fIvyhlFf/pxYoHsgHm2El2h6E7Af4hxM7zpedSivrkN9lX 8WWInEAWIw0HUgy2UYcOFVALH9dPkjgVi2uK/euwWY4afVBkqpgMBKGe0u20j8f/mCfm tpiOoCxULs5it7PzWpYu2KICDPPzz/9BSsDLzuTerOEhcCZR18p0A/JvxttjjT11pfig jplw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TwsmLqbv; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id t9si1059643plo.440.2022.02.23.17.46.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Feb 2022 17:46:19 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TwsmLqbv; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9B5B119E02E; Wed, 23 Feb 2022 17:21:08 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243817AbiBWWb0 (ORCPT + 99 others); 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 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: 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