current->state after kmalloc

current->state after kmalloc

[Oliver Neukum]

Hi,

if I do

set_current_state(TASK_INTERRUPTIBLE);
kmalloc(sizeof(struct x), GFP_KERNEL);

what is current->state after kmalloc ?

	Regards
		Oliver

Re: current->state after kmalloc

[arjan]

In article <16Xt8Y-1SQ44eC@fwd04.sul.t-online.com> 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

Re: current->state after kmalloc

[Oliver Neukum]

On Tuesday 05 February 2002 01:23, arjan@fenrus.demon.nl wrote:
> In article <16Xt8Y-1SQ44eC@fwd04.sul.t-online.com> 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

Re: current->state after kmalloc

[Robert Love]

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

Re: current->state after kmalloc

[Oliver Neukum]

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

Re: current->state after kmalloc

[arjan]

In article <16Xu62-2F1K08C@fwd04.sul.t-online.com> 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

Re: current->state after kmalloc

[Oliver Neukum]

On Tuesday 05 February 2002 09:16, arjan@fenrus.demon.nl wrote:
> In article <16Xu62-2F1K08C@fwd04.sul.t-online.com> 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