Re: svn commit: r319722 - in head: sys/cam/ctl sys/dev/iscsi sys/kern sys/netgraph sys/netgraph/bluetooth/socket sys/netinet sys/ofed/drivers/infiniband/core sys/ofed/drivers/infiniband/ulp/sdp sys/rp

[Hans Petter Selasky]

On 07/04/17 09:51, Hans Petter Selasky wrote:

On 06/25/17 09:49, Gleb Smirnoff wrote:

   Conrad,

   this should be fixed by r320324. Sorry for inconvenience.



Hi Gleb,

There is a long thread here about panics on 32-bit platforms when 
INVARIANTS is enabled:


Can you have a look?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220358



Issue solved:

https://reviews.freebsd.org/D11475

--HPS

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r319722 - in head: sys/cam/ctl sys/dev/iscsi sys/kern sys/netgraph sys/netgraph/bluetooth/socket sys/netinet sys/ofed/drivers/infiniband/core sys/ofed/drivers/infiniband/ulp/sdp sys/rp

[Hans Petter Selasky]

On 06/25/17 09:49, Gleb Smirnoff wrote:

   Conrad,

   this should be fixed by r320324. Sorry for inconvenience.



Hi Gleb,

There is a long thread here about panics on 32-bit platforms when 
INVARIANTS is enabled:


Can you have a look?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220358

--HPS
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r319722 - in head: sys/cam/ctl sys/dev/iscsi sys/kern sys/netgraph sys/netgraph/bluetooth/socket sys/netinet sys/ofed/drivers/infiniband/core sys/ofed/drivers/infiniband/ulp/sdp sys/rp

[Gleb Smirnoff]

  Conrad,

  this should be fixed by r320324. Sorry for inconvenience.

On Fri, Jun 23, 2017 at 09:48:24PM -0700, Conrad Meyer wrote:
C> Hi Gleb,
C> 
C> We suspect this revision has broken setsockopt(SO_SNDBUF), etc., on
C> listen sockets, as used by e.g. nginx.
C> 
C> Example backtrace: http://imgur.com/a/fj5JQ
C> 
C> The proposed mechanism is the destroyed snd/rcv sockbufs (and
C> associated locks) as part of solisten_proto().
C> 
C> Best,
C> Conrad
C> 
C> 
C> 
C> On Thu, Jun 8, 2017 at 2:30 PM, Gleb Smirnoff  wrote:
C> > Author: glebius
C> > Date: Thu Jun  8 21:30:34 2017
C> > New Revision: 319722
C> > URL: https://svnweb.freebsd.org/changeset/base/319722
C> >
C> > Log:
C> >   Listening sockets improvements.
C> >
C> >   o Separate fields of struct socket that belong to listening from
C> > fields that belong to normal dataflow, and unionize them.  This
C> > shrinks the structure a bit.
C> > - Take out selinfo's from the socket buffers into the socket. The
C> >   first reason is to support braindamaged scenario when a socket is
C> >   added to kevent(2) and then listen(2) is cast on it. The second
C> >   reason is that there is future plan to make socket buffers pluggable,
C> >   so that for a dataflow socket a socket buffer can be changed, and
C> >   in this case we also want to keep same selinfos through the lifetime
C> >   of a socket.
C> > - Remove struct struct so_accf. Since now listening stuff no longer
C> >   affects struct socket size, just move its fields into listening part
C> >   of the union.
C> > - Provide sol_upcall field and enforce that so_upcall_set() may be 
called
C> >   only on a dataflow socket, which has buffers, and for listening 
sockets
C> >   provide solisten_upcall_set().
C> >
C> >   o Remove ACCEPT_LOCK() global.
C> > - Add a mutex to socket, to be used instead of socket buffer lock to 
lock
C> >   fields of struct socket that don't belong to a socket buffer.
C> > - Allow to acquire two socket locks, but the first one must belong to a
C> >   listening socket.
C> > - Make soref()/sorele() to use atomic(9).  This allows in some 
situations
C> >   to do soref() without owning socket lock.  There is place for 
improvement
C> >   here, it is possible to make sorele() also to lock optionally.
C> > - Most protocols aren't touched by this change, except UNIX local 
sockets.
C> >   See below for more information.
C> >
C> >   o Reduce copy-and-paste in kernel modules that accept connections from
C> > listening sockets: provide function solisten_dequeue(), and use it in
C> > the following modules: ctl(4), iscsi(4), ng_btsocket(4), ng_ksocket(4),
C> > infiniband, rpc.
C> >
C> >   o UNIX local sockets.
C> > - Removal of ACCEPT_LOCK() global uncovered several races in the UNIX
C> >   local sockets.  Most races exist around spawning a new socket, when 
we
C> >   are connecting to a local listening socket.  To cover them, we need 
to
C> >   hold locks on both PCBs when spawning a third one.  This means 
holding
C> >   them across sonewconn().  This creates a LOR between pcb locks and
C> >   unp_list_lock.
C> > - To fix the new LOR, abandon the global unp_list_lock in favor of 
global
C> >   unp_link_lock.  Indeed, separating these two locks didn't provide us 
any
C> >   extra parralelism in the UNIX sockets.
C> > - Now call into uipc_attach() may happen with unp_link_lock hold if, we
C> >   are accepting, or without unp_link_lock in case if we are just 
creating
C> >   a socket.
C> > - Another problem in UNIX sockets is that uipc_close() basicly did 
nothing
C> >   for a listening socket.  The vnode remained opened for connections.  
This
C> >   is fixed by removing vnode in uipc_close().  Maybe the right way 
would be
C> >   to do it for all sockets (not only listening), simply move the vnode
C> >   teardown from uipc_detach() to uipc_close()?
C> >
C> >   Sponsored by: Netflix
C> >   Differential Revision:https://reviews.freebsd.org/D9770
C> >
C> > Modified:
C> >   head/sys/cam/ctl/ctl_ha.c
C> >   head/sys/dev/iscsi/icl_soft_proxy.c
C> >   head/sys/kern/sys_socket.c
C> >   head/sys/kern/uipc_accf.c
C> >   head/sys/kern/uipc_debug.c
C> >   head/sys/kern/uipc_sockbuf.c
C> >   head/sys/kern/uipc_socket.c
C> >   head/sys/kern/uipc_syscalls.c
C> >   head/sys/kern/uipc_usrreq.c
C> >   head/sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
C> >   head/sys/netgraph/bluetooth/socket/ng_btsocket_rfcomm.c
C> >   head/sys/netgraph/bluetooth/socket/ng_btsocket_sco.c
C> >   head/sys/netgraph/ng_ksocket.c
C> >   head/sys/netinet/sctp_input.c
C> >   head/sys/netinet/sctp_syscalls.c
C> >   head/sys/netinet/sctp_sysctl.c
C> >   head/sys/netinet/sctp_usrreq.c
C> >   head/sys/netinet/tcp_subr.c
C> >   head/sys/netinet/tcp_syncache.c
C> >   head/sys/netinet/tcp_timewait.c
C> >   

Re: svn commit: r319722 - in head: sys/cam/ctl sys/dev/iscsi sys/kern sys/netgraph sys/netgraph/bluetooth/socket sys/netinet sys/ofed/drivers/infiniband/core sys/ofed/drivers/infiniband/ulp/sdp sys/rp

[Conrad Meyer]

Hi Gleb,

We suspect this revision has broken setsockopt(SO_SNDBUF), etc., on
listen sockets, as used by e.g. nginx.

Example backtrace: http://imgur.com/a/fj5JQ

The proposed mechanism is the destroyed snd/rcv sockbufs (and
associated locks) as part of solisten_proto().

Best,
Conrad



On Thu, Jun 8, 2017 at 2:30 PM, Gleb Smirnoff  wrote:
> Author: glebius
> Date: Thu Jun  8 21:30:34 2017
> New Revision: 319722
> URL: https://svnweb.freebsd.org/changeset/base/319722
>
> Log:
>   Listening sockets improvements.
>
>   o Separate fields of struct socket that belong to listening from
> fields that belong to normal dataflow, and unionize them.  This
> shrinks the structure a bit.
> - Take out selinfo's from the socket buffers into the socket. The
>   first reason is to support braindamaged scenario when a socket is
>   added to kevent(2) and then listen(2) is cast on it. The second
>   reason is that there is future plan to make socket buffers pluggable,
>   so that for a dataflow socket a socket buffer can be changed, and
>   in this case we also want to keep same selinfos through the lifetime
>   of a socket.
> - Remove struct struct so_accf. Since now listening stuff no longer
>   affects struct socket size, just move its fields into listening part
>   of the union.
> - Provide sol_upcall field and enforce that so_upcall_set() may be called
>   only on a dataflow socket, which has buffers, and for listening sockets
>   provide solisten_upcall_set().
>
>   o Remove ACCEPT_LOCK() global.
> - Add a mutex to socket, to be used instead of socket buffer lock to lock
>   fields of struct socket that don't belong to a socket buffer.
> - Allow to acquire two socket locks, but the first one must belong to a
>   listening socket.
> - Make soref()/sorele() to use atomic(9).  This allows in some situations
>   to do soref() without owning socket lock.  There is place for 
> improvement
>   here, it is possible to make sorele() also to lock optionally.
> - Most protocols aren't touched by this change, except UNIX local sockets.
>   See below for more information.
>
>   o Reduce copy-and-paste in kernel modules that accept connections from
> listening sockets: provide function solisten_dequeue(), and use it in
> the following modules: ctl(4), iscsi(4), ng_btsocket(4), ng_ksocket(4),
> infiniband, rpc.
>
>   o UNIX local sockets.
> - Removal of ACCEPT_LOCK() global uncovered several races in the UNIX
>   local sockets.  Most races exist around spawning a new socket, when we
>   are connecting to a local listening socket.  To cover them, we need to
>   hold locks on both PCBs when spawning a third one.  This means holding
>   them across sonewconn().  This creates a LOR between pcb locks and
>   unp_list_lock.
> - To fix the new LOR, abandon the global unp_list_lock in favor of global
>   unp_link_lock.  Indeed, separating these two locks didn't provide us any
>   extra parralelism in the UNIX sockets.
> - Now call into uipc_attach() may happen with unp_link_lock hold if, we
>   are accepting, or without unp_link_lock in case if we are just creating
>   a socket.
> - Another problem in UNIX sockets is that uipc_close() basicly did nothing
>   for a listening socket.  The vnode remained opened for connections.  
> This
>   is fixed by removing vnode in uipc_close().  Maybe the right way would 
> be
>   to do it for all sockets (not only listening), simply move the vnode
>   teardown from uipc_detach() to uipc_close()?
>
>   Sponsored by: Netflix
>   Differential Revision:https://reviews.freebsd.org/D9770
>
> Modified:
>   head/sys/cam/ctl/ctl_ha.c
>   head/sys/dev/iscsi/icl_soft_proxy.c
>   head/sys/kern/sys_socket.c
>   head/sys/kern/uipc_accf.c
>   head/sys/kern/uipc_debug.c
>   head/sys/kern/uipc_sockbuf.c
>   head/sys/kern/uipc_socket.c
>   head/sys/kern/uipc_syscalls.c
>   head/sys/kern/uipc_usrreq.c
>   head/sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
>   head/sys/netgraph/bluetooth/socket/ng_btsocket_rfcomm.c
>   head/sys/netgraph/bluetooth/socket/ng_btsocket_sco.c
>   head/sys/netgraph/ng_ksocket.c
>   head/sys/netinet/sctp_input.c
>   head/sys/netinet/sctp_syscalls.c
>   head/sys/netinet/sctp_sysctl.c
>   head/sys/netinet/sctp_usrreq.c
>   head/sys/netinet/tcp_subr.c
>   head/sys/netinet/tcp_syncache.c
>   head/sys/netinet/tcp_timewait.c
>   head/sys/ofed/drivers/infiniband/core/iwcm.c
>   head/sys/ofed/drivers/infiniband/ulp/sdp/sdp_main.c
>   head/sys/rpc/svc_vc.c
>   head/sys/sys/sockbuf.h
>   head/sys/sys/socket.h
>   head/sys/sys/socketvar.h
>   head/usr.bin/netstat/inet.c
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r319722 - in head: sys/cam/ctl sys/dev/iscsi sys/kern sys/netgraph sys/netgraph/bluetooth/socket sys/netinet sys/ofed/drivers/infiniband/core sys/ofed/drivers/infiniband/ulp/sdp sys/rp

[Andreas Tobler]

On 15.06.17 07:00, Gleb Smirnoff wrote:

   Hi,

On Wed, Jun 14, 2017 at 09:59:50AM +0200, Andreas Tobler wrote:
A> with this revision I get either a kernel panic or a hang. This happens
A> on powerpc (32-bit). The powerpc64 looks stable.
A>
A> Here you can see the backtrace in case of the panic:
A> https://people.freebsd.org/~andreast/r319722_ppc32_1.jpg
A>
A> In the source code I see a comment with XXXGL...
A> Is this powerpc specific or do you think that there are some issues in
A> the uipc_socket.c code?

The comment has nothing to do with arch or 32-bit. Is
it possible to understand what is the actual instruction
at soisconnected()+0x21c ?



(gdb) p /x 0x5a5808 + 0x21c
$2 = 0x5a5a24

005a5808 :
  5a5808:   94 21 ff c0 stwur1,-64(r1)
  5a580c:   7c 08 02 a6 mflrr0
  5a5810:   93 01 00 20 stw r24,32(r1)



  5a5a0c:   39 40 00 00 li  r10,0
  5a5a10:   2f 8a 00 00 cmpwi   cr7,r10,0
  5a5a14:   40 9e 00 0c bne cr7,5a5a20 
  5a5a18:   38 7c 00 10 addir3,r28,16
  5a5a1c:   4b f1 c4 61 bl  4c1e7c <__mtx_unlock_sleep>
  5a5a20:   7f 63 db 78 mr  r3,r27
->5a5a24:   4b ff f5 9d bl  5a4fc0 
  5a5a28:   48 00 04 80 b   5a5ea8 
  5a5a2c:   7c 45 13 78 mr  r5,r2
  5a5a30:   39 20 00 04 li  r9,4


I'm going to stress test before 319722 to see if I can confirm Mark's 
comment.


Thanks!
Andreas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r319722 - in head: sys/cam/ctl sys/dev/iscsi sys/kern sys/netgraph sys/netgraph/bluetooth/socket sys/netinet sys/ofed/drivers/infiniband/core sys/ofed/drivers/infiniband/ulp/sdp sys/rp

[Gleb Smirnoff]

  Hi,

On Wed, Jun 14, 2017 at 09:59:50AM +0200, Andreas Tobler wrote:
A> with this revision I get either a kernel panic or a hang. This happens 
A> on powerpc (32-bit). The powerpc64 looks stable.
A> 
A> Here you can see the backtrace in case of the panic:
A> https://people.freebsd.org/~andreast/r319722_ppc32_1.jpg
A> 
A> In the source code I see a comment with XXXGL...
A> Is this powerpc specific or do you think that there are some issues in 
A> the uipc_socket.c code?

The comment has nothing to do with arch or 32-bit. Is
it possible to understand what is the actual instruction
at soisconnected()+0x21c ?

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r319722 - in head: sys/cam/ctl sys/dev/iscsi sys/kern sys/netgraph sys/netgraph/bluetooth/socket sys/netinet sys/ofed/drivers/infiniband/core sys/ofed/drivers/infiniband/ulp/sdp sys/rp

[Andreas Tobler]

Hi Gleb,

with this revision I get either a kernel panic or a hang. This happens 
on powerpc (32-bit). The powerpc64 looks stable.


Here you can see the backtrace in case of the panic:
https://people.freebsd.org/~andreast/r319722_ppc32_1.jpg

In the source code I see a comment with XXXGL...
Is this powerpc specific or do you think that there are some issues in 
the uipc_socket.c code?


Thanks,
Andreas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"