Hi folks,

While investigating one of our memory buildup issues, we have found that loadparm
structures count getting increased on every time smbd receives SIGHUP.

Actually there was an issue with one of our internal modules. We were sending SIGHUP to all smbd processes every 5 mins even though there are no config changes.This has exposed the real problem in Samba. On every reload, samba removes all unused services including IPC$ and re-add them. But service ptrs are never freed(only marked as free), If we have hundreds of shares, this is going to cause huge buildup if there is a real need to send SIGHUPs to smbds.

Here are I have captured the growth of loadparm structures at various times while SIGHUPs being sent to smbds in between.

$ sudo smbcontrol 5317 pool-usage | grep "struct loadparm"
    struct loadparm_service *      contains   6852 bytes in 140 blocks (ref 0)
        struct loadparm_service        contains    907 bytes in  38 blocks (ref 0)
        struct loadparm_service        contains   1281 bytes in  49 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains   1240 bytes in  47 blocks (ref 0)
                            struct loadparm_context        contains     96 bytes in   1 blocks (ref 0)
$ sudo smbcontrol 5317 pool-usage | grep "struct loadparm"
    struct loadparm_service *      contains   8212 bytes in 142 blocks (ref 0)
        struct loadparm_service        contains    907 bytes in  38 blocks (ref 0)
        struct loadparm_service        contains   1281 bytes in  49 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains   1240 bytes in  47 blocks (ref 0)
                            struct loadparm_context        contains     96 bytes in   1 blocks (ref 0)
$ sudo smbcontrol 5317 pool-usage | grep "struct loadparm"
    struct loadparm_service *      contains   8892 bytes in 143 blocks (ref 0)
        struct loadparm_service        contains   1281 bytes in  49 blocks (ref 0)
        struct loadparm_service        contains    907 bytes in  38 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains    672 bytes in   1 blocks (ref 0)
        struct loadparm_service        contains   1240 bytes in  47 blocks (ref 0)
                            struct loadparm_context        contains     96 bytes in   1 blocks (ref 0)

To see this problem, you can send SIGHUP to any smbds(sudo kill -SIGHUP <smbd-pid>) and count the number of loadparm instances in pool-usage.

I have made some changes to resolve this issue. I will be posting that soon.