[Info-vax] Volatile, was: Re: yet another sys$qiow question

[Stephen Hoffman]

On 2015-08-21 02:05:13 +0000, John Reagan said:

> On Thursday, August 20, 2015 at 5:43:42 PM UTC-4, JF Mezei wrote:
> 
>> Obviously, while in kernel mode, you can't be interrupted by an IO that 
>> completes, right ?

Kernel-mode code can perform asynchronous I/O.

Device drivers are kernel-mode code, are usually asynchronous 
(pseudo-devices can be exceptions here — no pun intended), and are the 
basis of all I/O in all modes.

Large tracts of the OpenVMS kernel are pageable, too.   Q.E.D.

Mistakes here often crash.  Or can occasionally be exploited.

>> Or could an IO completing on another processor modify memory areas that 
>> your kernel code is playing with ?

Can kernel-mode code contain coding bugs?    Sure.

>> But what about multiprocessor systems, can user mode code in one thread 
>> modify a variable that is being used by your kernel code running on 
>> another processor ?

Only if the kernel code is sharing and trusting user-writeable memory.  
 That happens if you're erroneously directly or indirectly using 
certain LIBRTL routines from inner-mode code — something which is 
presently allowed, but — for various reasons, not the least of which is 
security — should better produce a run-time error and be blocked.  
There are other ways to share user-writeable memory such as during the 
kernel-mode, device-specific portions of the processing of $qio and 
$io_perform in various drivers, albeit those cases of shared access are 
usually obvious and recognized.

> Things like the IPL mechanism and spinlocks are used to guard against 
> such things to serialize certain operations.

Unfortunately, IPLs and spinlocks can't guard against the problems 
secondary to a simple C while-spin on an IOSB field, or a cache-unaware 
while-spin on shared memory.  That just never ends well.

>  And there are MB instructions in various places of the OS to provide 
> well-defined behavior.  That's why the instruction exists.

This is also why higher-level APIs and abstractions can exist; dealing 
with arcane and error-prone instruction- and architectural-level 
details can be problematic, and any latent errors here can be difficult 
to reproduce.   This stuff is also architecture and sometimes even 
platform-specific.   Shared memory is a common OpenVMS example of 
potentially problematic coding.  Then there are other and similarly 
problematic areas, such as mixing threads and ASTs, and implementing 
threading as a library and not as part of the language — there's a nice 
paper from HP Labs stating that'll never work right, but I digress.    
Threading particularly tends to expose synchronization bugs.  Most any 
modern operating system is heavily threaded — with OpenVMS, that's not 
the same specific sort of threading that's presented to C programmers 
or via KP threads, but kernel ASTs and special-kernel ASTs and 
interrupts and fork processes and the rest all have to be reviewed for 
and quite possibly interlocked when accessing shared data.

The lower you go in the proverbial programming stack, the more you have 
to know about the underlying server and its architecture, and where 
there are correspondingly fewer abstractions.



-- 
Pure Personal Opinion | HoffmanLabs LLC