Created attachment 16109 [details]
patch file based on Samba 4.11.9
If a Windows client sends change notification requests n times for the same folder, smbd-notifyd triggers at least n*n messages to the requesting smbd process when something happens to the folder.
We noticed this issue multiple times when the memory usage of smbd-notifyd process was huge, in one case it was 250GiB. Eventually the issue was reproduced by working with the end user who experienced the issue.
I understand it is unusual for a client to send change notification requests for the same folder again and again, but a node.js component named "webpack-dev-server" actually does it.
I have come up with a potential fix to the issue and verified that it fixes our problem. Please see the attached diff file.
Can you clarify exactly what the client is doing to trigger this ?
My understanding is that the client, on the same connection, is repeatedly issuing identical change-notify requests on an open handle ?
Is that correct ? It would be good to see a wireshark trace of this so we can create a regression test to reproduce this.
Created attachment 16115 [details]
pcap file showing many change notification requests on the same folder
(In reply to Jeremy Allison from comment #1)
A pcap file was attached to show how a Windows client sends 3000+ change notification requests on the same folder. No change was triggered on that folder as I didn't want to receive 9,000,000 responses.
This issue has been reproduced on both Linux and illumos system.
I also have a Windows C program which can be used to reproduce the issue reliably, please let me know if it is needed.
The Windows C program would be really helpful also - thanks !
Created attachment 16116 [details]
Patch to open many notifies on a single connection and directory
Attached find a work-in-progress patch that implements important bits of the problematic network trace.
smbtorture3 //127.0.0.1/tmp -Uuser%pass notify-bench4 -o 2000
opens 2000 handles and notifies and goes to sleep after that. It is just an initial step towards further analysis, which I don't have time for at this moment. So this is just a snapshot that might help others to take a closer look before I can return to this case.
Created attachment 16117 [details]
Fixed torture patch
Ooops, wrong patch posted. I had uncommitted changes in my working tree that did not make it to patch 16166. Sorry for the hickup.
Created attachment 16118 [details]
Windows C program for reproducing the issue
The requested C program was attached. Thanks.