On 31/01/2025 9:29, Christoph Hellwig wrote:
On Thu, Jan 30, 2025 at 04:25:35PM +0100, Daniel Wagner wrote:
On Wed, Jan 29, 2025 at 07:05:34AM +0100, Christoph Hellwig wrote:
On Tue, Jan 28, 2025 at 05:34:46PM +0100, Daniel Wagner wrote:
If a lot of request are in the queue, this message is spamming the logs,
thus rate limit it.
Are in the queue when what happens? Not that I'm against this,
but if we have a known condition where this error is printed a lot
we should probably skip it entirely for that?
The condition is that all the elements in the queue->send_list could fail as a
batch. I had a bug in my patches which re-queued all the failed command
immediately and semd them out again, thus spamming the log.
This behavior doesn't exist in upstream. I just thought it might make
sense to rate limit as precaution. I don't know if it is worth the code
churn.
I'm fine with the rate limiting. I was just wondering if there is
a case where we'd easily hit it and could do even better.
I agree with the change. The reason why I think its useful to keep is
because its
has been really useful indication when debugging UAF panics.
