[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201203161859.35104.oliver@neukum.org>
Date: Fri, 16 Mar 2012 18:59:35 +0100
From: Oliver Neukum <oliver@...kum.org>
To: santosh prasad nayak <santoshprasadnayak@...il.com>
Cc: mchehab@...radead.org, gregkh@...uxfoundation.org,
khoroshilov@...ras.ru, linux-media@...r.kernel.org,
devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] [media] staging: Return -EINTR in s2250_probe() if fails to get lock.
Am Freitag, 16. März 2012, 17:56:20 schrieb santosh prasad nayak:
> On Fri, Mar 16, 2012 at 10:02 PM, Oliver Neukum <oliver@...kum.org> wrote:
> >
> > Indeed there's a lot wrong here. The idea of having an interruptible
> > sleep in probe() is arcane. You need a very, very, very good reason for that.
>
> Can you please explain why interruptible sleep should not be in probe() ?
> I am curious to know.
-EINTR is supposed to be returned to user space, so that it can repeat
an interrupted syscall.
- There is no user space for probe()
- probe() cannot be easily repeated from user space
- there is no syscall for probe
>
>
> > The sane fix is using an uninterruptable sleep here.
> >
> > Second, while you are at it, fix the error case for no initialization
> > due to a failing kmalloc(). You need to return -ENOMEM.
>
> Are you talking about kmalloc or kzalloc ?
> Because for failing kmalloc -ENOMEM is returned as shown below:
data = kzalloc(16, GFP_KERNEL);
if (data != NULL) {
int rc;
rc = go7007_usb_vendor_request(go, 0x41, 0, 0,
data, 16, 1);
if (rc > 0) {
u8 mask;
data[0] = 0;
mask = 1<<5;
data[0] &= ~mask;
data[1] |= mask;
go7007_usb_vendor_request(go, 0x40, 0,
(data[1]<<8)
+ data[1],
data, 16, 0);
}
kfree(data);
}
mutex_unlock(&usb->i2c_lock)
This code has no error handling.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists