Hi,
if I do
set_current_state(TASK_INTERRUPTIBLE);
kmalloc(sizeof(struct x), GFP_KERNEL);
what is current->state after kmalloc ?
Regards
Oliver
In article <[email protected]> you wrote:
> set_current_state(TASK_INTERRUPTIBLE);
> kmalloc(sizeof(struct x), GFP_KERNEL);
> what is current->state after kmalloc ?
undefined. If kmalloc slept and you survived (due to setting
TASK_INTERRUPTIBLE that's not guaranteed) then it'll most likely be
TASK_RUNNING.
If you depend on this your kernel code is broken in that has subtle
dependencies on unspecified behavior and will break whenever kmalloc changes
internal behavior.
Greetings,
Arjan van de Ven
On Tuesday 05 February 2002 01:23, [email protected] wrote:
> In article <[email protected]> you wrote:
> > set_current_state(TASK_INTERRUPTIBLE);
> > kmalloc(sizeof(struct x), GFP_KERNEL);
> >
> > what is current->state after kmalloc ?
>
> undefined. If kmalloc slept and you survived (due to setting
> TASK_INTERRUPTIBLE that's not guaranteed) then it'll most likely be
> TASK_RUNNING.
> If you depend on this your kernel code is broken in that has subtle
> dependencies on unspecified behavior and will break whenever kmalloc
> changes internal behavior.
Is it safe with GFP_ATOMIC ?
Regards
Oliver
On Mon, 2002-02-04 at 19:43, Oliver Neukum wrote:
> Is it safe with GFP_ATOMIC ?
You are guaranteed kmalloc will not sleep if you use GFP_ATOMIC, yes.
But I still find it gross to mark yourself sleeping but not sleep
immediately.
Robert Love
On Tuesday 05 February 2002 01:50, Robert Love wrote:
> On Mon, 2002-02-04 at 19:43, Oliver Neukum wrote:
> > Is it safe with GFP_ATOMIC ?
>
> You are guaranteed kmalloc will not sleep if you use GFP_ATOMIC, yes.
>
> But I still find it gross to mark yourself sleeping but not sleep
> immediately.
usb_submit_urb() uses kmalloc internally.
To code a simple waiting for the results of an urb,
it is necessary.
Regards
Oliver
In article <[email protected]> you wrote:
> usb_submit_urb() uses kmalloc internally.
> To code a simple waiting for the results of an urb,
> it is necessary.
Can't you just alloc the memory outside this "current" area ?
Even if that means you have to release it if you don't use it
On Tuesday 05 February 2002 09:16, [email protected] wrote:
> In article <[email protected]> you wrote:
> > usb_submit_urb() uses kmalloc internally.
> > To code a simple waiting for the results of an urb,
> > it is necessary.
>
> Can't you just alloc the memory outside this "current" area ?
> Even if that means you have to release it if you don't use it
No. The individual USB device drivers must not know the memory
requirements of the HCD layer.
Regards
Oliver