lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOD=uF6wD1sx2=Rk3ZaxtykBR32_GMsHmiuXuAQP2U_=c-Ytbw@mail.gmail.com>
Date:	Sat, 17 Mar 2012 21:30:36 +0530
From:	santosh prasad nayak <santoshprasadnayak@...il.com>
To:	Oliver Neukum <oliver@...kum.org>
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.

Oliver,

The following changes are for review only  not a formal patch.

-------------------------------------------------------------------------------------------------------------
-       if (mutex_lock_interruptible(&usb->i2c_lock) == 0) {
+       mutex_lock(&usb->i2c_lock);
                data = kzalloc(16, GFP_KERNEL);
-               if (data != NULL) {
+               if(data == NULL) {
+                       i2c_unregister_device(audio);
+                       kfree(state);
+                       return -ENOMEM;
+               } else {
                        int rc;
                        rc = go7007_usb_vendor_request(go, 0x41, 0, 0,
                                                       data, 16, 1);
@@ -657,7 +661,7 @@ static int s2250_probe(struct i2c_client *client,
                        kfree(data);
                }
                mutex_unlock(&usb->i2c_lock);
-       }
+

----------------------------------------------------------------------


Is it ok ?


regards
Santosh


On Fri, Mar 16, 2012 at 11:29 PM, Oliver Neukum <oliver@...kum.org> wrote:
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ