[Linux-streams] LiS-2.14
Dave Grothe
Thu, 18 Jul 2002 11:33:01 -0700

I think the LiS-2.13 betas have become stable enough to make a new 
"evenly numbered" release of LiS-2.14.

The archive for LiS-2.14 has been placed on the ftp site and is now 
identified as the latest stable version.

-- Dave


_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

[Linux-streams] LiS-2.14
David Grothe
Fri, 25 Oct 2002 15:24:01 -0700

This version of LiS has the following features: 
It claims to fix the SMP dupmsg/freemsg races 
It extends the size of message allocation to over 100K bytes 
It incorporates a scheme for kmem_cache allocation of mblks, queues, 
and stream head structures. 
It builds, but does not run, on 2.5 kernels 
It does not fix the sleep-while-holding-a-spinlock problem.  That comes 
next.

I have only tested this on 2.4.16 so others may want to test it on other 
kernels.

I am going to have to fix the sleep/spinlock problem before I can get a 
meaningful test on 2.5 for the getmsg/putmsg system call registration patch.

NOTE:  In order to get LiS to build on 2.5 I had to slightly change the 
way in which dev_t structures are handled.  If you get warnings (or syntax 
errors) in your driver code that is connected with handling these structures, 
look at the sample drivers loop.c or sad.c for how to do it safely.  You may 
not have any problems if you are not including any kernel headers in your 
drivers; but LiS includes kernel headers implicitly.  You may not see any 
problems when compiling against 2.4 kernel headers but see errors when compiling 
in a 2.5 kernel context.  Be on the lookout for this.

-- Dave

[Linux-streams] LiS-2.15
David Grothe
Tue, 31 Dec 2002 07:43:49 -0800

I realize that this is asking for a bolt from the blue, but LiS-2.15 is now 
officially released.
-- Dave

_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

Re: [Linux-streams] LiS-2.15
Ragnar Paulson
Fri, 10 Jan 2003 09:09:29 -0800

David et al,

We've just discovered that in LiS-2.15 (I haven't checked other versions but we've not 
seen this symptom before) the STREAM head put routine queues all messages 
(lis_strrput) including M_FLUSH.   This causes the service routine to flush the stream 
head read queue of all messages that came before AND AFTER the M_FLUSH message was 
sent upstream.

Is this correct or desired behaviour?  Shouldn't the lis_strrput process the M_FLUSH 
message immediately rather than defer it to the service routine?

Regards,
Ragnar Paulson

Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

Re: [Linux-streams] LiS-2.15
Ragnar Paulson
Mon, 13 Jan 2003 12:30:47 -0800

Hi all,

We've looked at the sudden change of behaviour with regards to M_FLUSH messages 
further but aren't much further ahead.  As near as I can tell from looking at LiS-2.13 
and comparing it to LiS-2.15 the logic in the STREAM head has not changed at all. 
Meanwhile our STREAMS are source code identical.  They definitely haven't changed.  

The drivers upper write put procedure processes many messages immediately.  One 
message in particular causes the driver to
generate a M_FLUSH and an M_PCPROTO response.  These are both queued to the driver 
upper read queue.  The driver
upper read service routine does a putnext() to send the messages to the STREAM head.  
We do not do flush processing in 
our service routine (to avoid flushing messages queued after the M_FLUSH).  

In LiS-2.15 the STREAM head acts exactly as I would expect it to from reading the code 
... it queues the messages in the lis_strrput() routine, and lis_strrsrv() flushes the 
read side queue, losing the M_PCPROTO.  From code inspection I expect the same 
behaviour in LiS-2.13 (and LiS-2.14) but it doesn't happen.  

Note I haven't attempted to debug the STREAM head in any case, our driver debug shows 
the messages being sent upstream via putnext, our application debug indicates the 
M_PCPROTO did not arrive.  Naturally we don't think this is proper flsuh handling but 
I could listen to counter arguments.  For now we're rearranging our drivers to try to 
avoid sending the M_FLUSH in this case and we're stymied as to why its worked up until 
now.

Regards,
Ragnar

We've just discovered that in LiS-2.15 (I haven't checked other versions but we've not 
seen this symptom before) the STREAM head put routine queues all messages 
(lis_strrput) including M_FLUSH.   This causes the service routine to flush the stream 
head read queue of all messages that came before AND AFTER the M_FLUSH message was 
sent upstream.

Is this correct or desired behaviour?  Shouldn't the lis_strrput process the M_FLUSH 
message immediately rather than defer it to the service routine?

_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

Re: [Linux-streams] LiS-2.15
David Grothe
Mon, 13 Jan 2003 13:48:25 -0800

I looked in the SVR4 docs and could not find anything definitive on this. 
There is something highly indicative, however, which is that AT&T examples 
show flush handling being handled by the "put" procedure with other 
processing deferred to the "service" procedure. I think that the stream head 
should be semantically equivalent to this.

As the changes required to fix this will have implications for read and 
getmsg handling, I am deferring the fix until I have decent amount of time 
to work on it. That will be at least two weeks from now due to workload.

Thanks for the info,
Dave

Re: [Linux-streams] LiS-2.15
Ragnar Paulson
Mon, 13 Jan 2003 14:21:12 -0800

----- Original Message ----- 
From: "David Grothe" <[EMAIL PROTECTED]>
To: "Ragnar Paulson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, January 13, 2003 4:47 PM
Subject: Re: [Linux-streams] LiS-2.15


> I looked in the SVR4 docs and could not find anything definitive on 
> this.  There is something highly indicative, however, which is that AT&T 
> examples show flush handling being handled by the "put" procedure with 
> other processing deferred to the "service" procedure.  I think that the 
> stream head should be semantically equivalent to this.
> 
> As the changes required to fix this will have implications for read and 
> getmsg handling, I am deferring the fix until I have decent amount of time 
> to work on it.  That will be at least two weeks from now due to workload.
> 

Fair enough.  My gut instinct is to cut and paste the M_FLUSH code from 
lis_process_rput() into lis_strrput() but there could be ramifications with the locks 
and sempahores that I'm not aware of.  We're under a bit of workload right now as well 
but if we try this I'll post the code diffs and results back to the list.  

I don't think there is anything definitive in the specs on when M_FLUSH is processed 
but another way to look at it is to ask how long must a driver/module wait before 
sending messages after M_FLUSH to ensure they are not flushed as well?  

Ragnar


_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

Re: [Linux-streams] LiS-2.15
David Grothe
Mon, 13 Jan 2003 15:02:41 -0800

At 04:16 PM 1/13/2003 Monday, Ragnar Paulson wrote:

	----- Original Message -----

	Fair enough. My gut instinct is to cut and paste the M_FLUSH code from 
	lis_process_rput() into lis_strrput() but there could be ramifications 
	with the locks and sempahores that I'm not aware of. We're under a bit 
	of workload right now as well but if we try this I'll post the code 
	diffs and results back to the list.

The problem is that getpmsg (and maybe read) "peeks" at the message at the 
head of the queue and then later decides whether or not to remove it. The 
queue could be flushed in the interim.

strrput must be considered as entered (potentially) at interrupt time, so it 
can't get non-irq spinlocks.

All this adds up to something that it will take some thought to fix.

-- Dave


_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams