cli()/sti() clarification

cli()/sti() clarification

Post by irfan_ha.. » Fri, 19 Jul 2002 15:30:12



Hi,

I added two system calls, blockintr() and unblockintr() to give cli()/sti()
control to userland programs (yes I know its not advisable) but I only want
to do it as a test. My test program looks like this:

        blockintr();
        /* Some long calculations */
        unblockintr();

The problem is that if I press Ctrl+C during the calculation, the program
terminates. So I checked the _syscallN() and __syscall_return() macros to
see if they explicitly call sti() before returning to userspace, but they
dont.

Reading the lkml archives, I found that cli() disables only the interrupts,
exceptions are allowed, so it makes sense that the SIGINT was delivered, but
if thats the case, then how come the SIGINT was delivered from the Ctrl+C?
Doesnt this mean that the SIGINT signal was generated as a result of the
keyboard interrupt?

I know I am missing something here, would appreciate if someone could point
me in the right direction.

Regards,
Irfan Hamid.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

cli()/sti() clarification

Post by george anzinge » Fri, 19 Jul 2002 16:10:06



> Hi,

> I added two system calls, blockintr() and unblockintr() to give cli()/sti()
> control to userland programs (yes I know its not advisable) but I only want
> to do it as a test. My test program looks like this:

>         blockintr();
>         /* Some long calculations */
>         unblockintr();

> The problem is that if I press Ctrl+C during the calculation, the program
> terminates. So I checked the _syscallN() and __syscall_return() macros to
> see if they explicitly call sti() before returning to userspace, but they
> dont.

> Reading the lkml archives, I found that cli() disables only the interrupts,
> exceptions are allowed, so it makes sense that the SIGINT was delivered, but
> if thats the case, then how come the SIGINT was delivered from the Ctrl+C?
> Doesnt this mean that the SIGINT signal was generated as a result of the
> keyboard interrupt?

> I know I am missing something here, would appreciate if someone could point
> me in the right direction.

Return from sys to user space is done by executing a "iret"
instruction.  In addition to picking up the return address
and segment it pick up EFLAGS which will contain the
interrupt flag as it was saved when the system call was
made...

> Regards,
> Irfan Hamid.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--

High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

cli()/sti() clarification

Post by Kasper Dupon » Fri, 19 Jul 2002 18:40:12



> Hi,

> I added two system calls, blockintr() and unblockintr() to give cli()/sti()
> control to userland programs (yes I know its not advisable) but I only want
> to do it as a test. My test program looks like this:

>         blockintr();
>         /* Some long calculations */
>         unblockintr();

> The problem is that if I press Ctrl+C during the calculation, the program
> terminates. So I checked the _syscallN() and __syscall_return() macros to
> see if they explicitly call sti() before returning to userspace, but they
> dont.

The flag register is saved on the stack and restored by the INT 0x80
and IRET instructions. You would want to change the interrupt flag
in that register. Here is an ugly piece of code that is known to
work on some kernel version, I don't remember which.

Another approach would be to use ioperm to get access to the IRQ
controller, and block interrupts there.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

[ cli.c 1K ]
/* This piece of code is ugly and inefficient. */

#include <stdlib.h>
#include <linux/module.h>
#include <asm/current.h>
#include "cli.h"

struct my_module {
  struct module m;
  char name[64];
  unsigned long jmp;
  unsigned long delta;

Quote:} my_module;

static int do_cli()
{
        (*(unsigned long*)(((char*)current)+0x1FF4)) &= ~0x200;
        return 0;

Quote:}

static int do_sti()
{
        (*(unsigned long*)(((char*)current)+0x1FF4)) |= 0x200;
        return 0;

Quote:}

void init_struct(int (*func)(),struct my_module *dst, struct my_module *p)
{
  dst->m.size_of_struct = sizeof(struct module);
  dst->m.next=NULL;
  dst->m.name=p->name;
  dst->m.size=sizeof(my_module);
  dst->m.flags=0;
  dst->m.nsyms=0;
  dst->m.ndeps=0;
  dst->m.syms=NULL;
  dst->m.deps=NULL;
  dst->m.refs=NULL;
  dst->m.init=(void*)&(p->jmp);
  dst->m.cleanup=NULL;
  dst->m.ex_table_start=NULL;
  dst->m.ex_table_end=NULL;
  dst->m.persist_start=NULL;
  dst->m.persist_end=NULL;
  dst->m.can_unload=NULL;
  sprintf(dst->name,"hack_%d_hack",getpid());
  dst->jmp=0xE9909090;
  dst->delta=(unsigned long)func-(unsigned long)(p+1);

Quote:}

static void kernel_call(int (*func)())
{
  struct my_module my_module;
  init_struct(func,&my_module,&my_module);
  init_struct(func,&my_module,(void*)create_module(my_module.name,my_module.m.size));
  init_module(my_module.name,&my_module.m);
  delete_module(my_module.name);

Quote:}

void cli()
{
  kernel_call(do_cli);

Quote:}

void sti()
{
  kernel_call(do_sti);

- Show quoted text -

Quote:}

 
 
 

cli()/sti() clarification

Post by Marco Colomb » Sat, 20 Jul 2002 00:00:12



Quote:> Hi,

> I added two system calls, blockintr() and unblockintr() to give cli()/sti()
> control to userland programs (yes I know its not advisable) but I only want
> to do it as a test. My test program looks like this:

>    blockintr();
>    /* Some long calculations */
>    unblockintr();

May I ask what are you trying to achieve?

.TM.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

cli()/sti() clarification

Post by irfan_ha.. » Tue, 23 Jul 2002 16:30:12


Thankyou all for explaining the system call internals to me. Feel like an
idiot now :)

Marco Colombo: As for what I am trying to achieve, it is simply this. I need
to do plot extraction from radar raw returns. The scan time for one
revolution is 2.44 secs. I need to extract plots for each pi/2 radians in
less than 2.44/4 secs. I have already optimized the extraction algo upto
SSE2 in assembly and am running the process as realtime, but it just cant
seem to cut it. So now I am going to try and block interrupts while I do the
DSP.

Regards,
Irfan Hamid.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. How to execute sti() and cli()?

As my 386sx is somewhat too slow to enjoy vi's in several xterms,
I'm doing most of my program development in VC's. To distinguish
them quickly I have different fg/bg-colors for them (setterm).
Using the predefined palette entries is no fun as most of the
colors are far too agressive (eg red) as background and even
eye-contraining as foreground.

So I have written a program to change the palette-entries and
thus I can use a dark blue where setterm thinks of a bright red...
But I have one problem:

I get access to the registers (0x3c8/0x3c9) by ioperm without
problems. But I like to enclose the sequence of io-port-accesses
with cli() and sti(), to make sure no other process can disturb
the action.

But I always end up with a general protection fault and I don't
know how to tell the kernel to permit the operations. I think,
I'd need some syscall to set CPL and IOPL. According to my
386/486 datasheet it would be even enough if IOPL<CPL to enable
sti and cli. This would not require CPL 0, as I understand this
would be dangerous (LDT/GDT beeing subject to changes).

Any suggestion?
(Up to now I had no problem even when reprogramming all 256
 palette registers without cli/sti, but this is pure luck)

BTW: The X386-server seems to leave ioperm's on when finished.
     This may result in a nonroot-process changing video-ports.

Michael Hermann

2. Any way to force a DHCP lease to expire?

3. cli()/sti() fix for drivers/net/depca.c

4. ftp and ftp_proxy

5. i2c-elektor (2.5.43) non-fatal error: unresolved symbol cli, sti

6. AppleTalk on Solaris 8 Sparc

7. drivers/ide/qd65xx: no cli/sti (2.4.19-pre3 & 2.5.28)

8. Starting X Windows with xinit ...

9. 2.5: ewrk3 cli/sti removal by VDA

10. 2.5.29 sound/oss/trident.c [2/2] remove cli/sti calls

11. what means cli() and sti()?

12. cli()/sti() and flags

13. Documentation for system calls cli, sti, etc.