[DRBD-user] [CASE-13] Please check potential panic scenario by accessing already freed socket.

김재헌 jhkim at mantech.co.kr
Tue Feb 16 04:10:48 CET 2016

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Hi,

This CASE-13 was my old question.
Please check out solution.


--- begin old mail ---

[CASE-13] Could you please check potential panic scenario by accessing
already freed socket?

Dear Philipp,

Please check potential panic scenario.

1. Test-scenario:

 - disconnect A and B
 - crash A disk
 - connect A-B
 - verify on A, role is secondary-secondary
 - found oos by verify
 - promote A with primary
 - disconnect A
 - during disconnecting, Windows BSOD occured(panic)

2. Windows WinDbg Stack dump:

     nt!KiPageFault+0x23a
                                        drbd!dtt_update_congested+0x1c  //
struct sock *sock = tcp_transport->stream[DATA_STREAM]->sk;
                                        drbd!dtt_send_page+0x69
                                        drbd!flush_send_buffer+0xfd
                                        drbd!drbd_uncork+0x71
                                        drbd!wait_for_sender_todo+0xe5
                                        drbd!drbd_sender+0x14c
                                        drbd!drbd_thread_setup+0x107


    drbd!schedule+0x199
                                        drbd!wait_for_completion+0x28
                                        drbd!drbd_flush_workqueue+0x50
                                        drbd!drbd_disconnected+0x139
                                        drbd!conn_disconnect+0x1c6
                                        drbd!drbd_receiver+0x3f
                                        drbd!drbd_thread_setup+0x107

3. Question:

According to the above windows stack-dump,
drbd_receiver thread released DATA_STREAM socket during conn_disconnect by
sock_release.
So if drbd_sender thread access this just freed socket then system will be
panic.
Now, we cannot reproduce this situation anymore. It occured just only one
time.
Could you please check potential panic scenario by accessing already freed
socket in Linux side?

Thanks,

--- end old mail ---


Solutions:
  - Insert null socket check code at dtt_send_page.

       static int dtt_send_page(struct drbd_transport *transport, enum
drbd_stream stream,  struct page *page, int offset, size_t size, unsigned
msg_flags)
       {
             struct drbd_tcp_transport *tcp_transport =
 container_of(transport, struct drbd_tcp_transport, transport);
             struct socket *socket = tcp_transport->stream[stream];
       #if 1 // insert socket null check
             if(!socket)
             {
                   // for safely uncork operation, if socket is NULL.
                   return -EIO;
             }
       #endif


I think you omitted null socket check while separating sender thread from
worker.
Please verify our above patch code.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20160216/560cce67/attachment.htm>


More information about the drbd-user mailing list