From owner-freebsd-net@FreeBSD.ORG Tue Sep 13 22:29:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6031106566C for ; Tue, 13 Sep 2011 22:29:07 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by mx1.freebsd.org (Postfix) with ESMTP id 319458FC13 for ; Tue, 13 Sep 2011 22:29:06 +0000 (UTC) Received: by ewy19 with SMTP id 19so719355ewy.17 for ; Tue, 13 Sep 2011 15:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3NHWaLgMxoeNVDIvyW+E3wT/s5Tlp4YnQqcLfWhLupU=; b=AObyVkpgctDmBuaFIaFnBleWrJw500epMqOQi5dMECsT5lOHj4C3WL2UWloIz9eSDs TrmNhLMH77ycQSC+hKq8+ao5JRFgVfVMNzMzt6rn+d0Cj7YhLkEz1mHTGFSX5nmzw+Xt X5/zhVx5Kmwf99XHygL2LkAt06QLZ+kHYTDVc= MIME-Version: 1.0 Received: by 10.213.20.211 with SMTP id g19mr488683ebb.35.1315952945995; Tue, 13 Sep 2011 15:29:05 -0700 (PDT) Received: by 10.213.112.212 with HTTP; Tue, 13 Sep 2011 15:29:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Sep 2011 18:29:05 -0400 Message-ID: From: Ryan Stone To: Arnaud Lacombe Content-Type: multipart/mixed; boundary=0015174be814e31ea404acda2b4a Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: FreeBSD 7-STABLE mbuf corruption X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 22:29:07 -0000 --0015174be814e31ea404acda2b4a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 13, 2011 at 2:36 PM, Arnaud Lacombe wrote: > It did not crash, yet. The only downside is that after 3h30 and ~4h, > igb(4) queues' handler started spinning infinitely, breaking network > connectivity. I saw a similar issue on HEAD last week. The attached patch fix the problem for me. The problem was that if a struct task's ta_pending field overflows, the task will be inserted into a list when it is already in that list, causing a cycle in the list of tasks to be run. This causes the taskqueue thread to spin indefinitely as it looks over the cycle again and again. In case the list eats the patch, it was: Index: sys/kern/subr_taskqueue.c =================================================================== --- sys/kern/subr_taskqueue.c (revision 225537) +++ sys/kern/subr_taskqueue.c (working copy) @@ -173,7 +173,8 @@ * Count multiple enqueues. */ if (task->ta_pending) { - task->ta_pending++; + if (task->ta_pending < UINT16_MAX) + task->ta_pending++; return (0); } --0015174be814e31ea404acda2b4a Content-Type: application/octet-stream; name="taskqueue.patch" Content-Disposition: attachment; filename="taskqueue.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gsjgcqyn2 SW5kZXg6IHN5cy9rZXJuL3N1YnJfdGFza3F1ZXVlLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2tlcm4v c3Vicl90YXNrcXVldWUuYwkocmV2aXNpb24gMjI1NTM3KQorKysgc3lzL2tlcm4vc3Vicl90YXNr cXVldWUuYwkod29ya2luZyBjb3B5KQpAQCAtMTczLDcgKzE3Myw4IEBACiAJICogQ291bnQgbXVs dGlwbGUgZW5xdWV1ZXMuCiAJICovCiAJaWYgKHRhc2stPnRhX3BlbmRpbmcpIHsKLQkJdGFzay0+ dGFfcGVuZGluZysrOworCQlpZiAodGFzay0+dGFfcGVuZGluZyA8IFVJTlQxNl9NQVgpCisJCQl0 YXNrLT50YV9wZW5kaW5nKys7CiAJCXJldHVybiAoMCk7CiAJfQogCg== --0015174be814e31ea404acda2b4a--