Date: Wed, 1 May 2013 14:03:21 -0400 From: Glen Barber <gjb@FreeBSD.org> To: "Robert N. M. Watson" <rwatson@freebsd.org> Cc: Ian FREISLICH <ianf@clue.co.za>, freebsd-current@freebsd.org Subject: Re: panic: in_pcblookup_local (?) Message-ID: <20130501180321.GA44525@glenbarber.us> In-Reply-To: <F33F9F1A-1905-480B-A22B-8995B9772B51@freebsd.org> References: <E1UW0K5-000P7H-36@clue.co.za> <201304301653.13845.jhb@freebsd.org> <20130430211908.GB1621@glenbarber.us> <201305011156.03974.jhb@freebsd.org> <F33F9F1A-1905-480B-A22B-8995B9772B51@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 01, 2013 at 06:45:53PM +0100, Robert N. M. Watson wrote: >=20 > On 1 May 2013, at 16:56, John Baldwin wrote: >=20 > > It looks like the ipi_hash_lock is locked (and udp_connect() locks it),= so I=20 > > think the offending code is somewhere else. Also, I can't find anythin= g that > > removes an inp without hold the correct pcbinfo lock. Only thing I can= think > > of is if the pcbinfo pointer for an inp could change, so we could maybe > > lock the wrong one while removing it? > >=20 > > Hmmmmmm, you know. In in_pcbremlists() and in_pcbdrop(), we read inp_p= hd=20 > > without holding the hash lock. I think that probably don't actaully bre= ak > > anything, but this feels like a locking issue of some sort. >=20 > I'll need to catch up on this thread later, but a few questions: >=20 > Do we know if the application in question is multithreaded, and > if so, might it be attempting concurrent operations on this socket? I do not know if zabbix-agent is multithreaded, but cf-agent is. > The corrupted pointer is worrying ... but interesting, and suggests > something else is going on here -- stack corruption earlier in the > system call, perhaps? >=20 > In general, to modify our various hash lists you must lock both > the inpcb and the list. It's therefore sufficient to hold either > lock to read, so reading inp_phd should be OK with the inpcb lock > held, even without the hash lock held. >=20 > Do we have a dump of *inp, and if so, can we confirm that the > inpcb is still properly referenced, if there is an associated socket, > likewise a dump of *inp->inp_socket to check things are properly > referenced there? >=20 I will follow up with this information as soon as possible. Glen --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRgVjpAAoJEFJPDDeguUajIhAIAJ8zBs7CWHqPshgASEoRNLct gNl+GsLa5jXLkkkdAJy+UW+cadeBWDHg5cnNYpTPNTL0BIIZ65Lm2iGfYaLqLPHs 8sDC9TsMiG7SDZfpLVWLBWuZGuwr0q/2wLgdWWnV8OEzH6SkeQAop0z1hvaJrGEb 4aklPpwGFT3lXD7DaQrb0Q4Iu68P3cy3XGDBTczJj3nEaGdywEmYZtTUQv9uflC2 FH+9BZtO5kdGYEwfvXuYO3AM4th+zGmvnce/7Wt5mw8cIZXDkYYeAioblaIpQlP4 Ldi0R87FhiWpBSDVtFta5EVxQvWsVAXcdxscoEDibHw4zsXycZR/oQNeQWuSPTc= =8TRT -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130501180321.GA44525>