public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andy Shevchenko' <andriy.shevchenko@linux.intel.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>,
	"Dennis Dalessandro" <dennis.dalessandro@cornelisnetworks.com>
Subject: RE: [PATCH v1 1/1] IB/hfi1: Don't cast parameter in bit operations
Date: Wed, 23 Feb 2022 21:44:32 +0000	[thread overview]
Message-ID: <e39730af26cc4a4d944fa3205fa17b3c@AcuMS.aculab.com> (raw)
In-Reply-To: <20220223185353.51370-1-andriy.shevchenko@linux.intel.com>

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.

> Don't cast parameter to unsigned long pointer in the bit operations.
> Instead copy to a local variable on stack of a proper type and use.
> 
> Fixes: 7724105686e7 ("IB/hfi1: add driver files")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/infiniband/hw/hfi1/chip.c | 29 ++++++++++++++---------------
>  1 file changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/hfi1/chip.c b/drivers/infiniband/hw/hfi1/chip.c
> index f1245c94ae26..100274b926d3 100644
> --- a/drivers/infiniband/hw/hfi1/chip.c
> +++ b/drivers/infiniband/hw/hfi1/chip.c
> @@ -8286,34 +8286,33 @@ static void is_interrupt(struct hfi1_devdata *dd, unsigned int source)
>  irqreturn_t general_interrupt(int irq, void *data)
>  {
>  	struct hfi1_devdata *dd = data;
> -	u64 regs[CCE_NUM_INT_CSRS];
> +	DECLARE_BITMAP(pending, CCE_NUM_INT_CSRS * 64);
> +	u64 value;
>  	u32 bit;
>  	int i;
> -	irqreturn_t handled = IRQ_NONE;
> 
>  	this_cpu_inc(*dd->int_counter);
> 
>  	/* phase 1: scan and clear all handled interrupts */
>  	for (i = 0; i < CCE_NUM_INT_CSRS; i++) {
> -		if (dd->gi_mask[i] == 0) {
> -			regs[i] = 0;	/* used later */
> -			continue;
> -		}
> -		regs[i] = read_csr(dd, CCE_INT_STATUS + (8 * i)) &
> -				dd->gi_mask[i];
> +		if (dd->gi_mask[i] == 0)
> +			value = 0;	/* used later */
> +		else
> +			value = read_csr(dd, CCE_INT_STATUS + (8 * i)) & dd->gi_mask[i];
> +
> +		/* save for further use */
> +		bitmap_from_u64(&pending[BITS_TO_LONGS(i * 64)], value);
> +
>  		/* only clear if anything is set */
> -		if (regs[i])
> -			write_csr(dd, CCE_INT_CLEAR + (8 * i), regs[i]);
> +		if (value)
> +			write_csr(dd, CCE_INT_CLEAR + (8 * i), value);
>  	}

I think I'd leave all that alone.

>  	/* phase 2: call the appropriate handler */
> -	for_each_set_bit(bit, (unsigned long *)&regs[0],
> -			 CCE_NUM_INT_CSRS * 64) {
> +	for_each_set_bit(bit, pending, CCE_NUM_INT_CSRS * 64)

And do something else for that loop instead.

>  		is_interrupt(dd, bit);
> -		handled = IRQ_HANDLED;
> -	}
> 
> -	return handled;
> +	return IRQ_RETVAL(!bitmap_empty(pending, CCE_NUM_INT_CSRS * 64));

You really don't want to scan the bitmap again.

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.

	David

>  }
> 
>  irqreturn_t sdma_interrupt(int irq, void *data)
> --
> 2.34.1

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  reply	other threads:[~2022-02-23 21:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23 18:53 [PATCH v1 1/1] IB/hfi1: Don't cast parameter in bit operations Andy Shevchenko
2022-02-23 21:44 ` David Laight [this message]
2022-02-23 22:30   ` 'Andy Shevchenko'
2022-02-23 22:50     ` David Laight
2022-02-24  1:00       ` 'Andy Shevchenko'
2022-02-24 13:44     ` Dennis Dalessandro
2022-02-24 13:38   ` Dennis Dalessandro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e39730af26cc4a4d944fa3205fa17b3c@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dennis.dalessandro@cornelisnetworks.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mike.marciniszyn@cornelisnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox