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. Thanks !
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. Thanks!
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.