Milter-greylist

Hello,

I got a lot of messages like that:

Jun 25 12:01:47 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:47 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:49 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:49 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:49 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:50 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:50 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:52 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:52 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:54 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:56 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:01:58 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:02:00 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:02:00 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:02:02 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"
Jun 25 12:02:02 mail7 milter-greylist: reloading "/etc/mail/greylist.conf"

Is it possible to protect the full conf_update() function?
Many threads from mlfi_envfrom() came into conf_update() and found
the condition st.st_mtime < conffile_modified.tv_sec
to be false, so they all want to reread the conf file.
They are blocked too late inside conf_update().

My greylist.conf file has near 5000 line, so it isn't really a trivial job
to read.

I attach the patches which I did not test extensively.
I do not know what is the exact lock hierarchy but this new lock should be
somewhere at the top.

Bests,
Attila