Possible bug in Solaris 8 mlink() kernel function ???

Question

Hi All,
I'm trying to I_LINK a mounted-stream pipe (created using open and fattach), with CONNLD pushed on, below a STREAMS based multiplexor.
As I experienced some kernel crash, in the linkcycle() function I looked at the way it works in strsubr.c Solaris 8 file.
What I'm understanding is that there's a global static array, named mux_nodes. This is an array of mux_node structures, indexed by the device major number, extracted from the vnode vn_rdev field. Its purpose seems to be to list all the STREAMS linked below a multiplexor.
When the crash occurs, I can see that the mux_node the kernel is trying to read is at index 0xb8, but the devcnt has a value of 0xb5, so we're out of the bounds of the array. I've instrumenting my code, in order to dump the value of the vn_rdev, of the STREAM linked below (using the q_bot->q_stream->sd_vnode), and as the I_LINK is received this value is of 0xb8...
Moreover, looking at the vfslist of the crash dump (using mdb and the $<vfslist macro), it appears that several vfs have a rdev field greater than 0xb5...
The question is : Is-it really possible to I_LINK a pipe below a multiplexor ?? What am I missing ?? Shouldn't mlink() check that the index is inbound ???
Best Regards.

Answer 1

OK. I think I see what you are saying. First I want
to make sure we are both talking about 24 hour time
and not 12 hour time. In 24 hour time I understand
the 0100 hour would occur twice; The first in DST and
the second pass not in DST. I am not sure which time
the 'date 110401592007' command I ran set the time
in. The second.
Does the OS automatically put the new date in the
second pass through of the 0100 hour?Apparently.
If so there may
not be a bug at all but if that was the case how
could the fall back time be tested?Run
perl -le 'print scalar localtime 1143504000' and
perl -le 'print scalar localtime 1175040000'
If you're in a US timezone that follows Daylight Saving time, the first will show a time on March 27 2006 (Standard time) and the second a year later on March 27 2007 (Daylight Saving Time). The two should have local times one hour apart. If they do not, then you're probably not ready.
An alternative is to simply ask zdump for information about your particular tiemzone.
zdump -v $TZ | grep 2007. You should see the correct transition dates for 2007.
Alternatively, if you really want to change the clock on the computer, don't change it by specifying a local time (which as you've seen is ambiguous). Change it by specifying a UTC time and the -u flag. That's unambiguous.
Darren