Wietse Venema:
> The code in question is
>
> double smtpd_space_multf = 1.5;
>
> #define BLOCKS(x) ((x) / fsbuf.block_size)
>
> if (BLOCKS(var_queue_minfree) >= fsbuf.block_free
> || BLOCKS(var_message_limit) >= fsbuf.block_free / smtpd_space_multf) {
> (void) smtpd_check_reject(state, MAIL_ERROR_RESOURCE,
...
> The test has two conditions, and one of them is true. In addition
> we know that fsbuf.block_free * fsbuf.block_size = 908328873984
> which is a plausible value (this number is logged in a warning
> message). So both fsbuf.block_free and fsbuf.block_size are
> likely good.
>
> - If the first condition is true, then the queue_minfree parameter
> has a small non-zero value. As this is parameter is not read from
> main.cf, perhaps its compiled-in default value has changed due
> to a bit-flip in non-ECC memory? A reboot would change that.
>
> - If the second condition is true, then the message_size_limit
> parameter has a very large value. As this is read from main.cf
> and converted to number every time a process starts, a bad
> bit-flip in the message_size_limit value is unlikely.
In addition we know that the smtpd_space_multf value is good, because
it is logged in a warning message.
My bet is that the queue_minfree variable is corrupted after a
bit-flip. This variable is compile-time initialized, so the value
is read from the smtpd executable file, and my bet is that VM system
keeps much of that file cached in memory. One bit-flip in some
"data" section can affect all smtpd processes.
Wietse
