Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 May 2013 18:45:53 +0100
From:      "Robert N. M. Watson" <rwatson@freebsd.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Ian FREISLICH <ianf@clue.co.za>, Glen Barber <gjb@freebsd.org>, freebsd-current@freebsd.org
Subject:   Re: panic: in_pcblookup_local (?)
Message-ID:  <F33F9F1A-1905-480B-A22B-8995B9772B51@freebsd.org>
In-Reply-To: <201305011156.03974.jhb@freebsd.org>
References:  <E1UW0K5-000P7H-36@clue.co.za> <201304301653.13845.jhb@freebsd.org> <20130430211908.GB1621@glenbarber.us> <201305011156.03974.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 1 May 2013, at 16:56, John Baldwin wrote:

> 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 =
anything 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_phd=20
> without holding the hash lock. I think that probably don't actaully =
break
> anything, but this feels like a locking issue of some sort.

I'll need to catch up on this thread later, but a few questions:

Do we know if the application in question is multithreaded, and if so, =
might it be attempting concurrent operations on this socket?

The corrupted pointer is worrying ... but interesting, and suggests =
something else is going on here -- stack corruption earlier in the =
system call, perhaps?

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.

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?

Robert=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F33F9F1A-1905-480B-A22B-8995B9772B51>