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

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

[BAIN]

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

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

[Arnd Bergmann]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Sonntag, 4. Juli 2004 16:36, BAIN wrote:
> 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);

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 <><

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[BAIN]

> > 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);
> 
> 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?
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