Project

General

Profile

Bug #10968

Kernel panic in smb_session_delete

Added by Gordon Ross 8 days ago. Updated 4 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2019-05-14
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

While copying data to the system, panic:

> $C
fffff001eadffa80 vpanic()
fffff001eadffab0 0xfffffffffba89478()
fffff001eadffae0 smb_slist_destructor+0x32(fffff046f9ca3b90)
fffff001eadffb10 smb_session_delete+0x5e(fffff046f9ca3780)
fffff001eadffb40 smb_server_destroy_session+0x47(fffff0438544ec48, fffff046f9ca3780)
fffff001eadffb70 smb_server_receiver+0x33(fffff0449893e340)
fffff001eadffc20 taskq_d_thread+0xe6(fffff0476b170e68)
fffff001eadffc30 thread_start+8()

History

#1

Updated by Gordon Ross 5 days ago

  • Description updated (diff)
  • Status changed from New to In Progress
#2

Updated by Gordon Ross 5 days ago

The panic happens because this call:

 760         smb_slist_destructor(&session->s_req_list);

found a non-empty list:
> fffff046f9ca3b90::print -atx smb_slist_t sl_count
fffff046f9ca3bc0 uint32_t sl_count = 0x2

The requests on that list were allocated by smb_oplock_sched_async_break after session tear-down began.
We need to be more careful in the code that puts those requests on the session so that can no longer happen once we start to tear down the session.

#3

Updated by Gordon Ross 5 days ago

Testing:
We were able to reproduce this by forcing the order of things relative to disconnect and oplock break.
The fix has been in production since mid 2016.

#4

Updated by Electric Monk 4 days ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit 9c856e866360bf6877f0e47fdfef22bd8e33cf14

commit  9c856e866360bf6877f0e47fdfef22bd8e33cf14
Author: Matt Barden <matt.barden@nexenta.com>
Date:   2019-05-19T23:20:47.000Z

    10968 Kernel panic in smb_session_delete
    Reviewed by: Kevin Crowe <kevin.crowe@nexenta.com>
    Reviewed by: Matt Barden <matt.barden@nexenta.com>
    Reviewed by: Gordon Ross <gwr@nexenta.com>
    Approved by: Joshua M. Clulow <josh@sysmgr.org>

Also available in: Atom PDF