Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/_NTO_TCTL_IO/List of Posts
Forum Topic - _NTO_TCTL_IO: (12 Items)
   
Update
Marc Roessler
08/25/2009 12:22 PM
post36649
_NTO_TCTL_IO   
Hi...

We're using a small custom made shell tool to access a device via PCI and read some rather large amounts of data.

For this to work, obviuosly I need to do call ThreadCtl() to gain IO priviledges (using  _NTO_TCTL_IO).

However, when I start our tool, everything else on this CPU (PPC) hangs. I suppose 
IO Privs is not only a special mode to designate special access rights (as I initially thought) but also is in fact 
quite a high priority scheduling-wise...?

How can this be fixed? Can I drop I/O priviledges somehow after attaching to the PCI device? Do I need them for reading 
from the mmapped memory after it has successfully been mapped? In case there is some way to drop IO priviledges, can I 
later regain them? In case this isn't possible - wouldn't this be a good idea for a new feature (for following the "
least priviledge" secure programming rule)?

Greetings,
 Marc
Colin Burgess(deleted)
08/25/2009 12:26 PM
post36650
Re: _NTO_TCTL_IO   
_NTO_TCTL_IO doesn't give you any special scheduling privileges - so
something else must be going wrong when you run your util.

Marc Roessler wrote:
> Hi...
> 
> We're using a small custom made shell tool to access a device via PCI and read some rather large amounts of data.
> 
> For this to work, obviuosly I need to do call ThreadCtl() to gain IO priviledges (using  _NTO_TCTL_IO).
> 
> However, when I start our tool, everything else on this CPU (PPC) hangs. I suppose 
> IO Privs is not only a special mode to designate special access rights (as I initially thought) but also is in fact 
quite a high priority scheduling-wise...?
> 
> How can this be fixed? Can I drop I/O priviledges somehow after attaching to the PCI device? Do I need them for 
reading from the mmapped memory after it has successfully been mapped? In case there is some way to drop IO priviledges,
 can I later regain them? In case this isn't possible - wouldn't this be a good idea for a new feature (for following 
the "least priviledge" secure programming rule)?
> 
> Greetings,
>  Marc
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post36649
> 

-- 
cburgess@qnx.com
Marc Roessler
08/26/2009 5:12 AM
post36681
Re: _NTO_TCTL_IO   
Ok I did some further analysis...

It seems this only happens after I set up an interrupt handler using InterruptAttach() and enable interrupts in our 
hardware. The funny thing is, the CPU continues to be hogged even after I deatch the handler again using 
InterruptDetach(). Any ideas?

Concerning _NTO_TCTL_IO, just out of interest:
1. is is possible to drop I/O priviledges again after obtaining them?
2. the docu mentions I/O priviledges enable access to kernel memory on PPC. For this, someone would need to do a "
malicious" mmap of the kernel memory, correct? So under "normal" circumstances, accidential kernel access (e.g. by not 
checking buffer bounds) is still not possible...?
Marc Roessler
09/30/2009 10:14 AM
post39073
Re: _NTO_TCTL_IO   
*bump*

any suggestions on how to hunt this down?
Colin Burgess(deleted)
09/30/2009 10:43 AM
post39078
Re: _NTO_TCTL_IO   

Marc Roessler wrote:
> Ok I did some further analysis...
> 
> It seems this only happens after I set up an interrupt handler using InterruptAttach() and enable interrupts in our 
hardware. The funny thing is, the CPU continues to be hogged even after I deatch the handler again using 
InterruptDetach(). Any ideas?


Hmmm, is this a shared interrupt line?  It sounds like your interrupt is constantly asserting, and no user code will 
ever run.

> Concerning _NTO_TCTL_IO, just out of interest:
> 1. is is possible to drop I/O priviledges again after obtaining them?

No

> 2. the docu mentions I/O priviledges enable access to kernel memory on PPC. For this, someone would need to do a "
malicious" mmap of the kernel memory, correct? So under "normal" circumstances, accidential kernel access (e.g. by not 
checking buffer bounds) is still not possible...?

On the 800 series you can directly access kernel memory without a mapping - on the other powerpc families you are still 
protected unless you setup an explicit mapping.

-- 
cburgess@qnx.com
Marc Roessler
09/30/2009 10:59 AM
post39082
Re: _NTO_TCTL_IO   
Ok I digged a bit deeper into this now...

I found the following:

1. reading from the device's memory is no problem. Doing this will _not_ consume all CPU.

2. attaching an interrupt (and getting it) also is no problem. CPU is not hogged.
I'm using InterruptAttach() and MsgReceivePulse() (together with TimerTimeout) for waiting fot the interrupt.
Interrupt handler only runs once - I checked by incrementing a variable in the interrupt handler registered with 
InterruptAttach(): value is 1 at program exit. Yes, unclean... but we got only one thread here and we don't modify the 
variable from anywhere else. The interrupt is correctly reset from within the int handler.

3. only when you attach an interrupt, wait for that interrupt (wait for a pulse event with timeout, as indicated above) 
and then start reading from the device via PCI, the CPU is hogged while the program runs/reads. Still, the interrupt 
only occurs exactly once, so there is no flood of interrupts.

4. when starting the tool with "nice -3 ./tool", it does not change anything: cpu is hogged.

5. when you start the tool, let it sleep() for a few seconds after receiving the interrupt (before it starts to read via
 PCI) and deliver a "slay -P 7 tool" while it is still sleeping, after the sleep it continues _without_ hogging the CPU.
..!

Any suggestions? Why does this hog the CPU when reading after an interrupt has occured? Why doesn't it hog when reading 
without getting an interrupt first? Why does slay with the new prio work, but nice doesn't work? This is a single 
threaded application, so there shouldn't be any magic going on here... I'm not creating new threads or processes 
anywhere within this application.

Thanks,
 Marc
Marc Roessler
09/30/2009 11:03 AM
post39084
Re: _NTO_TCTL_IO   
for clarification: this is what happens when starting the tool:

- setup/attach interrupts
- trigger pci device
- wait (with timeout) for interrupt
- if we got the interrupt (no timeout), read data from pci device
Colin Burgess(deleted)
09/30/2009 11:15 AM
post39088
Re: _NTO_TCTL_IO   
> 5. when you start the tool, let it sleep() for a few seconds after receiving the interrupt (before it starts to read 
via PCI) and deliver a "slay -P 7 tool" while it is still sleeping, after the sleep it continues _without_ hogging the 
CPU...!

But is it still running ready, at the lower priority?

-- 
cburgess@qnx.com
Marc Roessler
09/30/2009 11:29 AM
post39092
Re: _NTO_TCTL_IO   
Colin, yes, it still is running READY most of the time (according to pidin).
There's not much else happening on the system at the moment, so exection time is the same, regardless of whether I send 
the slay-P or not.

I'm just wondering why
a) slay-P works but nice doesn't
b) this hogs the CPU at all.. it should run at the same prio as the other processes, right?
c) this only happens when receiving an Interrupt, then reading via PCI - but not if only one of these conditions is met.
..

Thanks,
 Marc
Marc Roessler
09/30/2009 11:35 AM
post39093
Re: _NTO_TCTL_IO   
forgot:

setprio(0, 7) also seems to do the trick, called just before I start to read via PCI.

But I consider this an ugly kludge to a problem that isn't fully understood yet... (dangerous)
Colin Burgess(deleted)
09/30/2009 11:40 AM
post39094
Re: _NTO_TCTL_IO   
And does it even complete?

Marc Roessler wrote:
> forgot:
> 
> setprio(0, 7) also seems to do the trick, called just before I start to read via PCI.
> 
> But I consider this an ugly kludge to a problem that isn't fully understood yet... (dangerous)
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post39093
> 

-- 
cburgess@qnx.com
Marc Roessler
09/30/2009 12:03 PM
post39101
Re: _NTO_TCTL_IO   
yes, it does complete - both with lowered prio and with higher prio.

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems