Sorry if I read this thread too quickly; it seemed you were all referring to something in the LiS distribution (you're all welcome to write your code however you see fit).
Before I made those changes in November, FIFO/pipes and fattach had been broken. Pipes and fattach particularly present close-time issues, as does FD passing. Since all three can be used together, all possibilities have to work out, at least so that all STREAMS get disposed of by the time the LiS subsystem is to be unloaded.
Again, I had tested as thoroughly as I could back in November, and I did resolve some close-time problems in the process, and I've never used this hack. I hadn't seen the most recent fdetach problem, which was module-unload-time problem, in fact, until I was trying to resolve the most recent fattach issue; I discovered the causing bug during my testing.
So, I would hope that the hack is no longer necessary, and I would have to recommend against using it if it isn't. I can test code I know about; I can't test code I don't know about.
Those of you with SMP systems might want to test as thoroughly as you can, especially if you still have unresolved problems related to any of these things. I have no SMP system currently at my disposal.
-John
John A. Boyd Jr. wrote:
I didn't address this specifically, but I did make some changes for close more generally, around last November, I think. I know, though, that in the back of my mind I had concerns about both open and close, and pipe closing is a bit tricky. There had been changes that broke how pipe ends closed; but I was hoping I'd fixed them again.
I know of no specific problems I could reproduce (I had a battery of scripted tests for problems I could reproduce), and all of those were resolved, but that doesn't mean there weren't problems that I could not reproduce.
That q_ptr check is nothing I know about, though. I never write NULL tests in that style. If it's checking for a closed STREAM, I'd likely have written "if (!q || !q->q_ptr)", i.e., I'd have checked 'q' also, since by habit I check pointers before dereferencing them, since finding "embedded" NULL references can be hard to do (as Brian demonstrated recently, regarding q->q_magic).
Dave L - if you can direct me in reproducing the problem, I can take a look at it as time permits.
As I think about it; there was a previously undetected bug with fdetach that might relate to this; I fixed it very recently, and Dave put that fix in 2.16.14. So, if you still have a problem and if you are using fattach/fdetach in reproducing it, you might test with 2.16.14 to see if it makes any difference.
-John
David Grothe wrote:
Since this seems to be pipe related and since John has done some work on pipes/fifos in the mean time, could you run a test with the latest version to see if the problem still exists. If so, I will add it to my list of things to tend to.
Thanks, -- Dave
At 03:44 PM 10/9/2003 Thursday, David Lehmann wrote:
David Grothe wrote:
I don't remember that one.
I forgot about it myself. I was tracking down a NULL pointer oops on a new module. When I saw it, I knew I ran into this before. So I checked an older module and there it was... the hack to get around the problem.
Was it for drivers or pushable modules?
pushable modules
Do you have a copy of an old e-mail that I could use as a reminder.
Nope.
(Of course you sent your email at almost exactly the same time that I sent the one announcing a new version of LiS.)
:-)
--
David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
