From patchwork Thu Aug 31 00:49:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Fainelli X-Patchwork-Id: 807993 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="WR2qxNYh"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3xjP7N4NZBz9s83 for ; Thu, 31 Aug 2017 10:55:44 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751242AbdHaAzk (ORCPT ); Wed, 30 Aug 2017 20:55:40 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:37408 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751086AbdHaAzj (ORCPT ); Wed, 30 Aug 2017 20:55:39 -0400 Received: by mail-wm0-f66.google.com with SMTP id x189so3384514wmg.4 for ; Wed, 30 Aug 2017 17:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=15aCI61oz+Kp3Ek8xPpKG8T3XHNrrrZNlB3L+Ex6PPA=; b=WR2qxNYhI8VHIIrN/Kj6HTuFH4XGULRs+MdO47X5FCwye/u82eylKvLaSfxfGXqUP+ iUrb+ubrdhpvLyAScIk4SsDxrjdCuJQUJyv3NbnpsXGU/TGyl7lHUElzPAQ19dXx0B1g fh7Gcln6x8GBzPmfX825C7ZtVLlV0cwS2GEYcru+gaKs3RQ2W7duqZGgPWChfUpY1VLc +TV/TgnK9AZECJWo1+TT3KQYeVAxe/j34irC+gr8NJvW1R+K7rXzl6OOvoN2C5GimrZz wqj3ayJpEIH9D4CpoKqf3PBDVx1GPJuB7mI2pa+ZNsBLdD1iFv8eCeVYz0Tmb6/AY6cq 4X6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=15aCI61oz+Kp3Ek8xPpKG8T3XHNrrrZNlB3L+Ex6PPA=; b=b1O8s/XtjMcqHhFX7sgXeNygXnTO/wXImHuLWsSOP7ndI7cn9q8bEDbBtTPUSatlVO nIVXu+MKPStlJOc+BBGJb1LeuBdl1K6Wj8ssacZZQqErjVUTg6CVFG6PUkTAbToppwHU YqbzGHWgS2Uz3JlRY105GTSX6ldj6M1Ihi0WbhHqQEYR6+KHm0owhjgVHZPyiHrKh1TQ 2tjvY2TL/CWCeTaj7xixjHOxyLiiIhMcwlMNkIDlYQkKLgp/+TwfHF2WnXVD/L2piCDv cGcjqC7zrgWijjOgD7CBB2/LadrRu9VX9MKSEarlfXVIACONTGvvXi0rgilH6tAq3wcQ wxXA== X-Gm-Message-State: AHYfb5gEOdMyhs6ZUs7rA5IM9KG94Lj4qq2MJunbBNMlHzlxqTd2LiCy 4fchyI6ii8QuHReG5Og= X-Received: by 10.28.45.20 with SMTP id t20mr2709730wmt.5.1504140937510; Wed, 30 Aug 2017 17:55:37 -0700 (PDT) Received: from stb-bld-04.irv.broadcom.com ([192.19.255.250]) by smtp.gmail.com with ESMTPSA id 7sm4549847wrn.87.2017.08.30.17.55.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Aug 2017 17:55:36 -0700 (PDT) From: Florian Fainelli To: netdev@vger.kernel.org Cc: Geert Uytterhoeven , David Daney , slash.tmp@free.fr, marc_gonzales@sigmadesigns.com, davem@davemloft.net, andrew@lunn.ch, Florian Fainelli Subject: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()" Date: Wed, 30 Aug 2017 17:49:29 -0700 Message-Id: <1504140569-2063-1-git-send-email-f.fainelli@gmail.com> X-Mailer: git-send-email 1.9.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org This reverts commit 7ad813f208533cebfcc32d3d7474dc1677d1b09a ("net: phy: Correctly process PHY_HALTED in phy_stop_machine()") because it is creating the possibility for a NULL pointer dereference. David Daney provide the following call trace and diagram of events: When ndo_stop() is called we call: phy_disconnect() +---> phy_stop_interrupts() implies: phydev->irq = PHY_POLL; +---> phy_stop_machine() | +---> phy_state_machine() | +----> queue_delayed_work(): Work queued. +--->phy_detach() implies: phydev->attached_dev = NULL; Now at a later time the queued work does: phy_state_machine() +---->netif_carrier_off(phydev->attached_dev): Oh no! It is NULL: CPU 12 Unable to handle kernel paging request at virtual address 0000000000000048, epc == ffffffff80de37ec, ra == ffffffff80c7c Oops[#1]: CPU: 12 PID: 1502 Comm: kworker/12:1 Not tainted 4.9.43-Cavium-Octeon+ #1 Workqueue: events_power_efficient phy_state_machine task: 80000004021ed100 task.stack: 8000000409d70000 $ 0 : 0000000000000000 ffffffff84720060 0000000000000048 0000000000000004 $ 4 : 0000000000000000 0000000000000001 0000000000000004 0000000000000000 $ 8 : 0000000000000000 0000000000000000 00000000ffff98f3 0000000000000000 $12 : 8000000409d73fe0 0000000000009c00 ffffffff846547c8 000000000000af3b $16 : 80000004096bab68 80000004096babd0 0000000000000000 80000004096ba800 $20 : 0000000000000000 0000000000000000 ffffffff81090000 0000000000000008 $24 : 0000000000000061 ffffffff808637b0 $28 : 8000000409d70000 8000000409d73cf0 80000000271bd300 ffffffff80c7804c Hi : 000000000000002a Lo : 000000000000003f epc : ffffffff80de37ec netif_carrier_off+0xc/0x58 ra : ffffffff80c7804c phy_state_machine+0x48c/0x4f8 Status: 14009ce3 KX SX UX KERNEL EXL IE Cause : 00800008 (ExcCode 02) BadVA : 0000000000000048 PrId : 000d9501 (Cavium Octeon III) Modules linked in: Process kworker/12:1 (pid: 1502, threadinfo=8000000409d70000, task=80000004021ed100, tls=0000000000000000) Stack : 8000000409a54000 80000004096bab68 80000000271bd300 80000000271c1e00 0000000000000000 ffffffff808a1708 8000000409a54000 80000000271bd300 80000000271bd320 8000000409a54030 ffffffff80ff0f00 0000000000000001 ffffffff81090000 ffffffff808a1ac0 8000000402182080 ffffffff84650000 8000000402182080 ffffffff84650000 ffffffff80ff0000 8000000409a54000 ffffffff808a1970 0000000000000000 80000004099e8000 8000000402099240 0000000000000000 ffffffff808a8598 0000000000000000 8000000408eeeb00 8000000409a54000 00000000810a1d00 0000000000000000 8000000409d73de8 8000000409d73de8 0000000000000088 000000000c009c00 8000000409d73e08 8000000409d73e08 8000000402182080 ffffffff808a84d0 8000000402182080 ... Call Trace: [] netif_carrier_off+0xc/0x58 [] phy_state_machine+0x48c/0x4f8 [] process_one_work+0x158/0x368 [] worker_thread+0x150/0x4c0 [] kthread+0xc8/0xe0 [] ret_from_kernel_thread+0x14/0x1c The original motivation for this change originated from Marc Gonzales indicating that his network driver did not have its adjust_link callback executing with phydev->link = 0 while he was expecting it. PHYLIB has never made any such guarantees ever because phy_stop() merely just tells the workqueue to move into PHY_HALTED state which will happen asynchronously. Reported-by: Geert Uytterhoeven Reported-by: David Daney Fixes: 7ad813f20853 ("net: phy: Correctly process PHY_HALTED in phy_stop_machine()") Signed-off-by: Florian Fainelli --- drivers/net/phy/phy.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 5068c582d502..d0626bf5c540 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -749,9 +749,6 @@ void phy_stop_machine(struct phy_device *phydev) if (phydev->state > PHY_UP && phydev->state != PHY_HALTED) phydev->state = PHY_UP; mutex_unlock(&phydev->lock); - - /* Now we can run the state machine synchronously */ - phy_state_machine(&phydev->state_queue.work); } /**