This is an attempt to kill two birds with one stone.
First, we kill one more user of kernel_thread, which is scheduled
for removal. Second - we kill one of the last users of kill_proc -
the function which is also to be removed, because it uses a pid_t
which is not safe now.
Signed-off-by: Pavel
Duncan Sands wrote:
> Hi Pavel,
>
>> Oh, I see. You're right - this race is possible... I'll fix that up
>> if this patch works.
>
> it seems to work fine. Thanks again for doing this!
Oh, thanks for testing. What should I do next to get this into
mainline? Send it to Andrew with you in Cc, or
Alan Stern wrote:
> On Thu, 7 Feb 2008, Pavel Emelyanov wrote:
>
>>> Does the kthread API guarantee that the kthread is not running until you
>>> call
>> It does. That's why the race, you mentioned above is impossible.
>
> That is wrong. The API guar
Duncan Sands wrote:
> Hi Pavel,
>
@@ -1014,11 +1015,7 @@ static int usbatm_do_heavy_init(void *arg)
struct usbatm_data *instance = arg;
int ret;
- daemonize(instance->driver->driver_name);
allow_signal(SIGTERM);
- instance->thread_pid = current->pid;
Duncan Sands wrote:
> Hi,
>
>> The problem is that I couldn't find the maintainer for the code
>> in drivers/usb/atm/.
>
> that would be me (though since I haven't used this modem in years I would
> be more than happy to hand it off to someone else).
>
>> Besides, I don't have a proper hardware
ainer for the code
in drivers/usb/atm/. Besides, I don't have a proper hardware to
test this.
So, who should I send this patch for review/testing?
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
index e717f5b..a994
