Bug 1324089

Summary:	SAMBA : smbd crash while dealing with files in windows
Product:	Red Hat Gluster Storage	Reporter:	Vivek Das <vdas>
Component:	samba	Assignee:	rhs-smb <rhs-smb>
Status:	CLOSED NOTABUG	QA Contact:	storage-qa-internal <storage-qa-internal>
Severity:	high	Docs Contact:
Priority:	high
Version:	rhgs-3.1	CC:	madam, nlevinki, rhinduja, vdas
Target Milestone:	---	Keywords:	Triaged, ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-04-05 10:33:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Vivek Das 2016-04-05 13:41:48 UTC

Description of problem:

Over windows mount , created around 1000 files in a folder over the share.
Then after the files are created, ran the delete command from the command prompt.
While the delete command was in progress i tried to kill that process from the command prompt in windows client and witnessed the un-mounting of samba server.

Version-Release number of selected component (if applicable):

samba-client-4.2.4-15.el6rhs.x86_64


How reproducible:
Always

Steps to Reproduce:
1.Mount samba share on windows client
2.Create a directory inside the share
3.Create around 1000 files in that directory
4.Run command rd /S /Q in command prompt over that directory.
5.Ctr + C over command prompt while deletion in progress.


Actual results:
Mount got disconnected. SMB crashes

Expected results:
Deletion of the file should be successful without any disconnect.

Additional info:
BT from the crash

BACKTRACE: 27 stack frames:
   #0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1a) [0x7fbfa6bffc0a]
   #1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x23) [0x7fbfa6bffcd3]
   #2 /usr/lib64/libsamba-util.so.0(smb_panic+0x3a) [0x7fbfa8a4bbba]
   #3 /usr/lib64/libsamba-util.so.0(+0x1add2) [0x7fbfa8a4bdd2]
   #4 /lib64/libpthread.so.0(+0xf790) [0x7fbfa8c73790]
   #5 /usr/lib64/libsmbconf.so.0(messaging_send_iov+0x240) [0x7fbfa6c09b20]
   #6 /usr/lib64/libsmbconf.so.0(messaging_send+0x47) [0x7fbfa6c09c47]
   #7 /usr/lib64/samba/libsmbd-base-samba4.so(set_delete_on_close_lck+0x195) [0x7fbfa86a2a65]
   #8 /usr/lib64/samba/libsmbd-base-samba4.so(+0x11c307) [0x7fbfa8613307]
   #9 /usr/lib64/samba/libsmbd-base-samba4.so(close_file+0x505) [0x7fbfa8613e95]
   #10 /usr/lib64/samba/libsmbd-base-samba4.so(+0x153452) [0x7fbfa864a452]
   #11 /usr/lib64/samba/libsmbd-base-samba4.so(smbd_smb2_request_process_close+0x189) [0x7fbfa864a7d9]
   #12 /usr/lib64/samba/libsmbd-base-samba4.so(smbd_smb2_request_dispatch+0xfc7) [0x7fbfa86401c7]
   #13 /usr/lib64/samba/libsmbd-base-samba4.so(+0x14b0c3) [0x7fbfa86420c3]
   #14 /usr/lib64/libsmbconf.so.0(run_events_poll+0x2b7) [0x7fbfa6c16157]
   #15 /usr/lib64/libsmbconf.so.0(+0x385a6) [0x7fbfa6c165a6]
   #16 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7fbfa563f9cd]
   #17 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7fbfa563fa4b]
   #18 /usr/lib64/samba/libsmbd-base-samba4.so(smbd_process+0x74e) [0x7fbfa862baee]
   #19 smbd(+0x939c) [0x7fbfa90ac39c]
   #20 /usr/lib64/libsmbconf.so.0(run_events_poll+0x2b7) [0x7fbfa6c16157]
   #21 /usr/lib64/libsmbconf.so.0(+0x385a6) [0x7fbfa6c165a6]
   #22 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7fbfa563f9cd]
   #23 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7fbfa563fa4b]
   #24 smbd(main+0x1640) [0x7fbfa90ae000]
   #25 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fbfa52c6d5d]
   #26 smbd(+0x5df9) [0x7fbfa90a8df9]

Comment 3 Michael Adam 2016-04-20 15:55:17 UTC

According to vdas, the problem is not reliably reproducible.
Also it should be attempted to reproduce it with the new samba build (Samba 4.4). 

Vivek, could you repro with 4.4?

Comment 4 Vivek Das 2016-04-21 10:49:53 UTC

I tried with the new build 4.4.2 but was not able to reproduce it again.

Comment 8 Michael Adam 2018-04-05 10:33:41 UTC

has not been reproducible