The reason that I need it to spend CPU time is that I'm developing a fault
injector. The purpose of a fault injection tool is, as you could imagine,
to test some critical systems and it's capacity to recover from fails. The
reason for changing the code of a process is that process must be delayed
but without leaving the CPU - everything must look like nothing wrong is
happening, except for other processes that are waiting for something from
the delayed process...
Maybe I should have explained this before... sorry.
I suppose now you can understand why SIGSTOP won't work. Hope you can help
me :)
About using udelay... this soluction seemed fine to me at first but if I
hang the CPU with udelay the scheduler will no be doing it's job (isn't
it?). This would give me even more intrusiveness (another requirement: the
less intrusiveness as possible).
Isn't there any doubt that copy_to_user can handle my problem? When I use
it to change CS, this function returns the correct number of bytes (and no
error) but, when I try to read... the old data is still there. I suppose
there is a page/segment protection against writing to CS, isn't it?
Luis Henriques
On Tue, 20 Nov 2001 20:54:42 +0000 (WET), Luis Miguel Correia
Henriques <[email protected]> wrote:
>The reason that I need it to spend CPU time is that I'm developing a fault
>injector. The purpose of a fault injection tool is, as you could imagine,
>to test some critical systems and it's capacity to recover from fails. The
>reason for changing the code of a process is that process must be delayed
>but without leaving the CPU - everything must look like nothing wrong is
>happening, except for other processes that are waiting for something from
>the delayed process...
>
>Maybe I should have explained this before... sorry.
>
>I suppose now you can understand why SIGSTOP won't work. Hope you can help
>me :)
>
>About using udelay... this soluction seemed fine to me at first but if I
>hang the CPU with udelay the scheduler will no be doing it's job (isn't
>it?). This would give me even more intrusiveness (another requirement: the
>less intrusiveness as possible).
>
>Isn't there any doubt that copy_to_user can handle my problem? When I use
>it to change CS, this function returns the correct number of bytes (and no
>error) but, when I try to read... the old data is still there. I suppose
>there is a page/segment protection against writing to CS, isn't it?
Maybe the kernel logic could lock the relevent page so it couldn't be
paged out...
john alvord
On Nov 20, 2001 20:54 +0000, Luis Miguel Correia Henriques wrote:
> The reason that I need it to spend CPU time is that I'm developing a fault
> injector. The purpose of a fault injection tool is, as you could imagine,
> to test some critical systems and it's capacity to recover from fails. The
> reason for changing the code of a process is that process must be delayed
> but without leaving the CPU - everything must look like nothing wrong is
> happening, except for other processes that are waiting for something from
> the delayed process...
>
> I suppose now you can understand why SIGSTOP won't work.
If you put the process in (un)interruptible sleep in the kernel, won't this
be enough? This is different than SIGSTOP. Is the requirement that this
process not leave the kernel call, or that it is actually consuming CPU
cycles as well?
> About using udelay... this soluction seemed fine to me at first but if I
> hang the CPU with udelay the scheduler will no be doing it's job (isn't
> it?). This would give me even more intrusiveness (another requirement: the
> less intrusiveness as possible).
It would probably work OK on an SMP system, since tasks can still be run
on the other CPU.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Ignoring the merits of what you are trying to do why don't you put your
new code on the target's stack? This avoids all of the problems associated
with changing the code section (which is doable but tricky, after all if
`gdb' can change the code section you certainly could).
On Tue, Nov 20, 2001 at 08:54:42PM +0000, Luis Miguel Correia Henriques wrote:
> The reason that I need it to spend CPU time is that I'm developing a fault
> injector. The purpose of a fault injection tool is, as you could imagine,
> to test some critical systems and it's capacity to recover from fails. The
> reason for changing the code of a process is that process must be delayed
> but without leaving the CPU - everything must look like nothing wrong is
> happening, except for other processes that are waiting for something from
> the delayed process...
>
> Maybe I should have explained this before... sorry.
>
> I suppose now you can understand why SIGSTOP won't work. Hope you can help
> me :)
>
> About using udelay... this soluction seemed fine to me at first but if I
> hang the CPU with udelay the scheduler will no be doing it's job (isn't
> it?). This would give me even more intrusiveness (another requirement: the
> less intrusiveness as possible).
>
> Isn't there any doubt that copy_to_user can handle my problem? When I use
> it to change CS, this function returns the correct number of bytes (and no
> error) but, when I try to read... the old data is still there. I suppose
> there is a page/segment protection against writing to CS, isn't it?
>
> Luis Henriques
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/652-0870x117
* Luis Miguel Correia Henriques ([email protected]) wrote:
> The reason that I need it to spend CPU time is that I'm developing a fault
> injector. The purpose of a fault injection tool is, as you could imagine,
> to test some critical systems and it's capacity to recover from fails. The
> reason for changing the code of a process is that process must be delayed
> but without leaving the CPU - everything must look like nothing wrong is
> happening, except for other processes that are waiting for something from
> the delayed process...
with ptrace(2) you can write into the program's .bss, whatever...add a
little shellcode and you're dangerous ;-)
-chris
On 20-Nov-2001 Luis Miguel Correia Henriques wrote:
> I suppose now you can understand why SIGSTOP won't work. Hope you can help
> me :)
how about making a signal handler for SIGUSR1 that checks a global variable and
loops. an other signal handler for SIGUSR2 to clear the variable so the SIGUSR1
handler can exit.
All in user space. (to delay execution kill -USR1 $pid, to continue: kill -USR2
$pid)
me
--
me
> > I suppose now you can understand why SIGSTOP won't work. Hope you can help
> > me :)
>
> how about making a signal handler for SIGUSR1 that checks a global variable and
> loops. an other signal handler for SIGUSR2 to clear the variable so the SIGUSR1
> handler can exit.
>
> All in user space. (to delay execution kill -USR1 $pid, to continue: kill -USR2
> $pid)
The same is possible within the kernel too! Add default handler to some
unused signals (there are more user-defineable signals than SIGUSR[12]
and noone cares to install handler for them) to do the loop in kernel.
Just make sure, that you call shedule() from time to time in that loop,
because in kernel you can't be preempted as you would in user-space.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <[email protected]>
> If you put the process in (un)interruptible sleep in the kernel, won't this
> be enough? This is different than SIGSTOP. Is the requirement that this
> process not leave the kernel call, or that it is actually consuming CPU
> cycles as well?
The process needs to be using CPU time, however, there must be a chance to
the scheduler to change the current process... if this occurs, than the delay
has to be aborted.
>
> > About using udelay... this soluction seemed fine to me at first but if I
> > hang the CPU with udelay the scheduler will no be doing it's job (isn't
> > it?). This would give me even more intrusiveness (another requirement:
> > the less intrusiveness as possible).
>
> It would probably work OK on an SMP system, since tasks can still be run
> on the other CPU.
>
> Cheers, Andreas
--
Lu?s Henriques
Luis Henriques--
Before making my suggestion: Apologies to the list if this has already
been settled. I'm trying to catch up on my LKML reading, and I'm only
up to Nov 20 so far...
Anyway: Here's what I'd do, if I had to do such a apalling thing 8^)
Drop a function in your code something like:
_xyzzy:
db 0x18, 0xfe ; jr $
Then, when you detect the condition where you want to waste time, then
put the address of this function on top of the user stack (along with
whatever else in the stack frame is required) so that the code just sits
there burning CPU. To clean it up, you'd simply restore the original
stack frame to the process.
It's hideous & gross, but if you need it.....
--marco