set_fs() preemption safety? [was sys_fs() safety oops !]

is the following block safe to be used in preemptible kernels?

old_fs = get_fs();
set_fs(KERNEL_DS);

do_your_things here; (usually call sys calls stuff from kernel space)

set_fs(old_fs);

i will explain my doubt further,
in nonpreempt kernels this changes the fs segment only on current cpu and is restored before other code is run on that cpu, you are strictly _not_ suppose to call schedule without restoring fs first.

but what about when preempt is enabled

even if i don't call schedule other code might start running on this current cpu without me restoring the fs first?

this code block appears in many places.. even in 2.6 kernels without disabling the preemption or holding spinlocks. so i am confused...

ne explanations are welcome, thanks in advance

and if this sound a lot funny please laugh your hearts out, a favour of explaining the joke to this newbee is always welcome

BAIN

On most architectures, this should not be a problem, because set_fs() only modifies the state of the current task, not any actual processor registers as the name suggests.

However, on s390 the state is actually kept in cpu control register cr7 and not in the task_struct. Martin, can you comment on how this is maintained over a schedule() or if this is a real bug?

	Arnd <><

Ok this is new info for me,...

I was under impression that i am banned from calling schedule between the two calls to set_fs.

This answers my question. Thanks,

BAIN