[PATCH 4/4] staging:iio:adc:ad7280a: Use GFP_ATOMIC in interrupt handler

[PATCH 4/4] staging:iio:adc:ad7280a: Use GFP_ATOMIC in interrupt handler

[Karim Eshapa]

Use GFP_ATOMIC rather GFP_KERNEL in interrupt handler,
as GFP_KERNEL may sleep according to slab allocator.

Signed-off-by: Karim Eshapa <karim.eshapa@gmail.com>
---
 drivers/staging/iio/adc/ad7280a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/adc/ad7280a.c b/drivers/staging/iio/adc/ad7280a.c
index b736275c10f5..25c4fbc303f7 100644
--- a/drivers/staging/iio/adc/ad7280a.c
+++ b/drivers/staging/iio/adc/ad7280a.c
@@ -692,7 +692,7 @@ static irqreturn_t ad7280_event_handler(int irq, void *private)
 	unsigned int *channels;
 	int i, ret;
 
-	channels = kcalloc(st->scan_cnt, sizeof(*channels), GFP_KERNEL);
+	channels = kcalloc(st->scan_cnt, sizeof(*channels), GFP_ATOMIC);
 	if (!channels)
 		return IRQ_HANDLED;
 
-- 
2.17.1

Re: [PATCH 4/4] staging:iio:adc:ad7280a: Use GFP_ATOMIC in interrupt handler

[Dan Carpenter]

On Fri, Jun 29, 2018 at 01:49:28AM +0200, Karim Eshapa wrote:
> Use GFP_ATOMIC rather GFP_KERNEL in interrupt handler,
> as GFP_KERNEL may sleep according to slab allocator.
> 

This is a threaded IRQ so it can sleep.

You should always think about the impact of a bug.  If this were a bug
it would have showed up in testing right away.  Most of my patches are
in error handling and so the impact is zero unless you deliberately try
to inject errors that's why they can go undetected for years.

Also you should always use the Fixes tag to see how the patch was
introduced.  I often see bugs where the patch is new and it was
introduced by someone doing major subsystem cleanups and they don't have
the hardware so I know it hasn't been tested.  If the patch is a couple
years old and the bug is in the success path which every one tests then
I wonder if I am misreading the code somehow.

regards,
dan carpenter

Re: [PATCH 4/4] staging:iio:adc:ad7280a: Use GFP_ATOMIC in interrupt handler

[karim eshapa]

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

On Fri, 29 Jun 2018 00:45:54 -0700, Dan Carpenter wrote:
>This is a threaded IRQ so it can sleep.
>
>You should always think about the impact of a bug.  If this were a bug
>it would have showed up in testing right away.  Most of my patches are
>in error handling and so the impact is zero unless you deliberately try
>to inject errors that's why they can go undetected for years.
>
>Also you should always use the Fixes tag to see how the patch was
>introduced.  I often see bugs where the patch is new and it was
>introduced by someone doing major subsystem cleanups and they don't have
>the hardware so I know it hasn't been tested.  If the patch is a couple
>years old and the bug is in the success path which every one tests then
>I wonder if I am misreading the code somehow.

Thanks Dan for your precious advises, I'm always trying to find
where it may causes a problem or improve performance to make
the code looks good and bug free.

Thanks,
Karim

On 29 June 2018 at 09:45, Dan Carpenter <dan.carpenter@oracle.com> wrote:

> On Fri, Jun 29, 2018 at 01:49:28AM +0200, Karim Eshapa wrote:
> > Use GFP_ATOMIC rather GFP_KERNEL in interrupt handler,
> > as GFP_KERNEL may sleep according to slab allocator.
> >
>
> This is a threaded IRQ so it can sleep.
>
> You should always think about the impact of a bug.  If this were a bug
> it would have showed up in testing right away.  Most of my patches are
> in error handling and so the impact is zero unless you deliberately try
> to inject errors that's why they can go undetected for years.
>
> Also you should always use the Fixes tag to see how the patch was
> introduced.  I often see bugs where the patch is new and it was
> introduced by someone doing major subsystem cleanups and they don't have
> the hardware so I know it hasn't been tested.  If the patch is a couple
> years old and the bug is in the success path which every one tests then
> I wonder if I am misreading the code somehow.
>
> regards,
> dan carpenter
>
>

[-- Attachment #2: Type: text/html, Size: 4910 bytes --]