[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