kern/76207: [xl] [patch] Null pointer dereference in xl_detach()

[Gleb Smirnoff]

The following reply was made to PR kern/76207; it has been noted by GNATS.

From: Gleb Smirnoff <glebius at freebsd.org>
To: Gene Stark <gene at starkhome.cs.sunysb.edu>
Cc: bug-followup at freebsd.org
Subject: Re: kern/76207: [xl] [patch] Null pointer dereference in xl_detach()
Date: Tue, 27 Dec 2005 15:22:34 +0300

   Gene,
 
 On Tue, Dec 27, 2005 at 07:13:25AM -0500, Gene Stark wrote:
 G>  > On Tue, Dec 27, 2005 at 05:46:47AM -0500, Gene Stark wrote:
 G>  > G> I'm not prepared at this time to replace the existing system on
 G>  > G> my laptop with 6.0-RELEASE, so I'm afraid I won't be able to provide the
 G>  > G> requested feedback.
 G>  > 
 G>  > Is this a temporary or not? If it is, then the PR will remain in its
 G>  > current state, waiting for you to reply in future. If you don't have
 G>  > the hardware or can't check this for any other reason, then the PR
 G>  > should be closed. So, what should I do with the PR?
 G> 
 G> Was any modification ever made to *any* branch as a result of this PR?
 G> 
 G> Look, I spent time on debugging this particular problem because it
 G> was important to me (it was crashing my laptop at extremely
 G> inopportune times, like when I was about to give a presentation or
 G> something).  I sent in the PR which contained workarounds, which I
 G> have been using since then, at least on the referenced FreeBSD version
 G> and maybe through a system update.
 G> 
 G> My hopes in sending in these PRs was to get somebody authoritative
 G> (like the author or maintainer of the driver) to look at the problem
 G> and hopefully make a suitable change.  My personal assessment after
 G> working on this particular problem was that the attach/detach
 G> sequence for this driver was very crufty in terms of keeping track
 G> of what had been initialized and what hadn't, and what needed to be
 G> freed and then reallocated.  Anybody knowledgeable who reads my PR
 G> and studies the driver code a little can see what I am talking about.
 G> I didn't have time to rewrite the driver and even if I did, I don't have
 G> the energy to argue with the maintainers about what would be the "proper"
 G> fix, coding conventions, etc., etc.  That's one reason why I didn't commit
 G> much when I was a committer.
 G> 
 G> Basically what I'm saying is:  I sent the PR because the code needed
 G> to be looked at and rewritten.  If somebody has done that on or before
 G> 6.0-RELEASE, well OK, I'll face up to it when and if I update my
 G> laptop to that version.  Hopefully it will "just work" at that point.
 G> If the same problem is still there, then I'll just be upset that
 G> nobody bothered to look at it and I'll be less likely to send in
 G> future PRs.
 
 As far as I know no commits were made, that reference your PR. However, the
 we had some general problems with detaching interfaces, and many of them
 were addressed before 6.0-RELEASE. This touched quite a lot of drivers,
 including xl(4).
 
 I'm now working on another xl(4) related PRs and I have acquired a 3Com
 PC card to work on them. Meanwhile, I decided to go thru other xl(4) PRs.
 And found yours. I see that on my notebook, on FreeBSD 7.0-CURRENT
 the card I have now, detaches and attaches without panic:
 
 cardbus1: Resource not specified in CIS: id=18, size=80
 xl0: <3Com 3c575C Fast Etherlink XL> port 0x1080-0x10ff mem 0x88000000-0x8800007f,0x88001000-0x8800107f irq 11 at device 0.0 on cardbus1
 miibus1: <MII bus> on xl0
 tdkphy0: <TDK 78Q2120 media interface> on miibus1
 tdkphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 xl0: Ethernet address: 00:00:86:3d:b2:d9
 Trying to mount root from ufs:/dev/ad0s1a
 arp: 81.19.64.118 moved from 00:04:76:3b:6d:df to 00:90:27:85:b8:b9 on fxp0
 xl0: reset didn't complete
 xl0: command never completed!
 xl0: command never completed!
 xl0: command never completed!
 tdkphy0: detached
 miibus1: detached
 xl0: detached
 cardbus1: Resource not specified in CIS: id=14, size=80
 cardbus1: Resource not specified in CIS: id=18, size=80
 xl0: <3Com 3c575C Fast Etherlink XL> port 0x1080-0x10ff mem 0x88000000-0x8800007f,0x88001000-0x8800107f irq 11 at device 0.0 on cardbus1
 miibus1: <MII bus> on xl0
 tdkphy0: <TDK 78Q2120 media interface> on miibus1
 tdkphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 xl0: Ethernet address: 00:00:86:3d:b2:d9
 xl0: link state changed to DOWN
 
 Here I have just ejected it and pushed back.
 
 I'm interested whether your particular card with your particular notebook
 still has problem or not. I do not urge you to do this right now, you can
 do it whenever you want and can. But the correct state for this PR is
 "feedback" since there is a high probability that the problem is not
 existent in modern FreeBSD, and we need confirmation or refuse of this
 fact to decide what to do with this PR.
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE