From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 188E0C47061 for ; Mon, 12 Apr 2021 16:48:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0CFB661289 for ; Mon, 12 Apr 2021 16:48:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244214AbhDLQsZ (ORCPT ); Mon, 12 Apr 2021 12:48:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344433AbhDLQjy (ORCPT ); Mon, 12 Apr 2021 12:39:54 -0400 Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67A47C061232 for ; Mon, 12 Apr 2021 09:31:37 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id 7so14724194qka.7 for ; Mon, 12 Apr 2021 09:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V39vJ8+XVZOqX4DC+GK6mHC3DoQ8P1rhNExHTLfMMDQ=; b=uiYtZ1u5gdlXqwa4kFIKxKi1xzGWk5yJe1/Qd7SHyDkWQq7UOP0ZwHhsSF7Jkhvb5S KbazOecqj+jVITras+qBfh9rnLwJhx48YzLmRVqLILlz0KIwNSau9tre/w2Q6dq5IQVr MBKlXG7ZRn171tNrCiM2vi2phMyqKWuLJseGEozK2h63hx3w4KGOHS9KtA+yaqwfS3u7 PZGd7ScQwI6tZC5gDbH9QEt9Px1Gxk32WvDKpK9AfpUib/MprbthIOBULf7ahcNWmEQa KnVTxkWI43E6XK3F7nzB7vTOWB8pXM8upSJkpFToLvM7JMjbs66szOkweu24a/3OWcnI AjLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V39vJ8+XVZOqX4DC+GK6mHC3DoQ8P1rhNExHTLfMMDQ=; b=FqIKunuRNLnlXN46GQ3y5Ulcq0YSKaVcGu8GarYCI4ljc4qIdjmfSNK3PreqLvO0NC FvERUGo23QaiZ7GiCdS3bB67WbdCSljP+a5iXgcnXDQLDes/jKfORVl0l7BcU1fd8vjU HmRF5er6fJRLTiAXYPUxql4vUDwxcYuCPSVVjfc+L0o8jX+dAeMo9G6YgmGEGl114COY KeXlhvcgW1XUQJ+ZiKSs+/ZDUcyLgADq3A/Jwe4k+b0vC7K+VmDS0P1JbLPW0lc1g7gK zUI8lkITOSRAwac+DWQfYoaYqRD1Nc3njKCyqauV5ivRdxBp9cV98F5KwXwIth3C8nEy QJwQ== X-Gm-Message-State: AOAM531zGZKFJFKR31SAr09BQr3zmRkcWDU51klB4FfUjAzK53baIq6U m9VfObg5s6Wr04VH2n56QwzWOSePivX1vORUAfBcxfVf54njqg== X-Google-Smtp-Source: ABdhPJzodwso6LxIhV15Rw93CnWB+kC+2pa/49ZcK4vho4iGkN5DQnTRTjwWMTzkTlPfisGvmYCs3LGlXD7MxAIZngc= X-Received: by 2002:a25:4244:: with SMTP id p65mr10068345yba.452.1618245096298; Mon, 12 Apr 2021 09:31:36 -0700 (PDT) MIME-Version: 1.0 References: <20210412051445.GA47322@roeck-us.net> In-Reply-To: From: Eric Dumazet Date: Mon, 12 Apr 2021 18:31:25 +0200 Message-ID: Subject: Re: Linux 5.12-rc7 To: Linus Torvalds Cc: Guenter Roeck , Xuan Zhuo , "Michael S. Tsirkin" , Linux Kernel Mailing List , Netdev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 12, 2021 at 6:28 PM Linus Torvalds wrote: > > On Sun, Apr 11, 2021 at 10:14 PM Guenter Roeck wrote: > > > > Qemu test results: > > total: 460 pass: 459 fail: 1 > > Failed tests: > > sh:rts7751r2dplus_defconfig:ata:net,virtio-net:rootfs > > > > The failure bisects to commit 0f6925b3e8da ("virtio_net: Do not pull payload in > > skb->head"). It is a spurious problem - the test passes roughly every other > > time. When the failure is seen, udhcpc fails to get an IP address and aborts > > with SIGTERM. So far I have only seen this with the "sh" architecture. > > Hmm. Let's add in some more of the people involved in that commit, and > also netdev. > > Nothing in there looks like it should have any interaction with > architecture, so that "it happens on sh" sounds odd, but maybe it's > some particular interaction with the qemu environment. Yes, maybe. I spent few hours on this, and suspect a buggy memcpy() implementation on SH, but this was not conclusive. By pulling one extra byte, the problem goes away. Strange thing is that the udhcpc process does not go past sendto().