Re: NET_LOCK() ordering issue

2017-01-23 Thread Martin Pieuchot
On 23/01/17(Mon) 18:45, Philip Guenther wrote: > On Mon, Jan 23, 2017 at 4:01 PM, Martin Pieuchot wrote: > [...] > > @@ -277,19 +277,35 @@ doaccept(struct proc *p, int sock, struc > > return (error); > > > > headfp = fp; > > + head = headfp->f_data;

Re: NET_LOCK() ordering issue

2017-01-23 Thread Philip Guenther
On Mon, Jan 23, 2017 at 4:01 PM, Martin Pieuchot wrote: > On 24/01/17(Tue) 00:51, Alexander Bluhm wrote: >> On Sat, Jan 21, 2017 at 10:46:42AM +1000, Martin Pieuchot wrote: ... > Updated diff, thanks for your review. Very close... > --- kern/uipc_syscalls.c29 Dec 2016

Re: NET_LOCK() ordering issue

2017-01-23 Thread Alexander Bluhm
On Tue, Jan 24, 2017 at 01:48:49AM +0100, Alexander Bluhm wrote: > On Tue, Jan 24, 2017 at 10:01:02AM +1000, Martin Pieuchot wrote: > > Updated diff, thanks for your review. > > > @@ -360,24 +358,20 @@ redo: > > error = soaccept(so, nam); > > if (!error && name != NULL) > >

Re: NET_LOCK() ordering issue

2017-01-23 Thread Alexander Bluhm
On Tue, Jan 24, 2017 at 10:01:02AM +1000, Martin Pieuchot wrote: > Updated diff, thanks for your review. > @@ -360,24 +358,20 @@ redo: > error = soaccept(so, nam); > if (!error && name != NULL) > error = copyaddrout(p, nam, name, namelen, anamelen); > - > + if

Re: NET_LOCK() ordering issue

2017-01-23 Thread Martin Pieuchot
On 24/01/17(Tue) 00:51, Alexander Bluhm wrote: > On Sat, Jan 21, 2017 at 10:46:42AM +1000, Martin Pieuchot wrote: > > Here's another way to fix the problem, call falloc() before grabbing the > > NET_LOCK(). > > > > Comments? > > There a two bugs in the "goto redo" block that is not part of the >

Re: NET_LOCK() ordering issue

2017-01-23 Thread Alexander Bluhm
On Sat, Jan 21, 2017 at 10:46:42AM +1000, Martin Pieuchot wrote: > Here's another way to fix the problem, call falloc() before grabbing the > NET_LOCK(). > > Comments? There a two bugs in the "goto redo" block that is not part of the diff. You could do a m_freem(nam), then goto redo, get an

Re: NET_LOCK() ordering issue

2017-01-20 Thread Martin Pieuchot
On 20/01/17(Fri) 22:25, Alexander Bluhm wrote: > On Thu, Jan 19, 2017 at 07:14:59PM +1000, Martin Pieuchot wrote: > > Index: kern/uipc_syscalls.c > > === > > RCS file: /cvs/src/sys/kern/uipc_syscalls.c,v > > retrieving revision 1.144

Re: NET_LOCK() ordering issue

2017-01-20 Thread Alexander Bluhm
On Thu, Jan 19, 2017 at 07:14:59PM +1000, Martin Pieuchot wrote: > Index: kern/uipc_syscalls.c > === > RCS file: /cvs/src/sys/kern/uipc_syscalls.c,v > retrieving revision 1.144 > diff -u -p -r1.144 uipc_syscalls.c > ---

Re: NET_LOCK() ordering issue

2017-01-20 Thread Alexander Bluhm
On Thu, Jan 19, 2017 at 07:14:59PM +1000, Martin Pieuchot wrote: > Turns out that the NET_LOCK() related hang reported by many is a > deadlock. One way to prevent it is to ensure that fdplock() is > always taken before the NET_LOCK() when both have to been hold. > > This generates the diff

NET_LOCK() ordering issue

2017-01-19 Thread Martin Pieuchot
Turns out that the NET_LOCK() related hang reported by many is a deadlock. One way to prevent it is to ensure that fdplock() is always taken before the NET_LOCK() when both have to been hold. This generates the diff below. Comments, ok? Index: kern/uipc_socket.c