[Cluster-devel] Kernel crash at DLM: kernel BUG at /usr/src/packages/BUILD/dlm-1.6.fio/obj/default/lowcomms.c:715!

[David Teigland <teigland@redhat.com>]

On Thu, Jan 29, 2015 at 03:50:58AM +0000, Pralay Dakua wrote:
> 645 static int receive_from_sock(struct connection *con)
> 646 {
> ....
> ....
> 704
> 705         /* Process SCTP notifications */
> 706         if (msg.msg_flags & MSG_NOTIFICATION) {
> 707                 msg.msg_control = incmsg;
> 708                 msg.msg_controllen = sizeof(incmsg);
> 709
> 710                 process_sctp_notification(con, &msg,
> 711                                 page_address(con->rx_page) + con->cb.base);
> 712                 mutex_unlock(&con->sock_mutex);
> 713                 return 0;
> 714         }
> 715         BUG_ON(con->nodeid == 0);
> 
> 
> I am fairly new when it comes to understanding DLM code. We are using
> SCTP protocol. If I understood correctly, nodeid = 0 points to the base
> connection (associated with the listener socket). The function
> receive_from_sock() has an assumption that if MSG_NOTIFICATION flag is
> not set, it got to be a peeled socket (which has associated nodeid > 0).
> And vice versa - if MSG_NOTIFICATION flag is set, it is listener socket
> with nodeid = 0.

> But when process_sctp_notification() rejects a SCTP event message due
> addr to nodeid mismatch (ie. dlm_addr-to_nodeid function returns
> non-zero), the function returns without peeling off a new socket.  The
> code is shown below, where the function is returning from line number
> 579. And the socket is peeled off at line number 588.  As the socket
> peeling off is not done, it is possible for listener socket receiving
> ordinary data (which was meant for peeled socket) from the connection
> where client already send some data (I am assuming client already sent
> this data before the socket is shutdown at server end). And if listener
> socket receives ordinary data,  DLM is going to hit the "BUG_ON()" at
> lowcomms.c:715.
> 
> Please let me know if my analysis is correct.

I think you probably understand this code as well as anyone else at this
point, and I suspect you're correct.

As Chrissie suggested, removing the BUG_ON and ignoring the data is
probably the best option, but I'm not sure exactly how it should be
ignored.  Could it just return, or does it need to set some length to
zero first?

Dave