Received: by 10.223.185.116 with SMTP id b49csp2625111wrg; Mon, 5 Mar 2018 06:13:01 -0800 (PST) X-Google-Smtp-Source: AG47ELvIIlVGW0DEj0j423oghyvUo5G7H4SCg0iKuHDqn42YaR+q81lixVbTObAKrkv1nFDorCxw X-Received: by 2002:a17:902:14cb:: with SMTP id y11-v6mr13489112plg.209.1520259181104; Mon, 05 Mar 2018 06:13:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520259181; cv=none; d=google.com; s=arc-20160816; b=dssy3TraLhhCH/AgNVBKXkreAPWjLUdr7w06VwOtyNBkfwrrp9Iti9+ItgjZIFlgQv 7ebIWourVG/zh4ueGExR8kxvry/0BhFjXuUbjIT3lyWr0/iWpYv+UaGfiG66+6qGPE0w k4EulK3l94s1LuriwBnpkxl9qYFPUyZrmN7Vmnvn1fmI93JNfCwm/kOJ6484PFi69dK/ hx3M43p/CPfGq2qTs99ynTz9aoTh7pLIzM8BnCErFQt+O2BlW0Ubd0x5QJ6108cJY0YA MHeoMQ/OeOogGdhrNk6QW4+1O2oAchUsoNwlQt6X/nU5Fi6nBGODv0TCDih6jKmdsW9l Tgfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=NcBl0yIt4cIEliv5bLaghkpaRBohF/DNJ4LUvqzmSfY=; b=zbeBghBtGnnTwCWK6sZo5Gf0w7RDxjwwFBqZlC5kw8SyHGyDXOYu0ROdSKG0XGqRzv vv8uxl1GottnelSuxtrnBP3Bv11fkbrvmnwls3VAjP0fZ+4R0VP85EaZGq6P5ubdV65T BrUyhbaagajwZ4wIvRBQ0Bt0UgW0rfJcZfQjVvTfp4yfuAamfcSn4Or5tWzJdAABcQcz iOiZlWgRssMyfiQ+uzHcZKcdh/i0P2ek4Fze6w8Gda7MoQUe9vcDRC6iSWWt8re6OJ2w ayqSfT3ZEAGfngexH9ae8dmphSnMIr49dNPk64ddn6NxwzpQ6LINUGJD0R+n8mwad5xw UyGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b9-v6si9249382pls.108.2018.03.05.06.12.47; Mon, 05 Mar 2018 06:13:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934833AbeCELvt (ORCPT + 99 others); Mon, 5 Mar 2018 06:51:49 -0500 Received: from mx2.suse.de ([195.135.220.15]:57738 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933027AbeCELvn (ORCPT ); Mon, 5 Mar 2018 06:51:43 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 16BB4AEA6; Mon, 5 Mar 2018 11:51:42 +0000 (UTC) Message-ID: <1520250367.3990.9.camel@suse.com> Subject: Re: inconsistent lock state with usbnet/asix usb ethernet and xhci From: Oliver Neukum To: Marek Szyprowski Cc: Eric Dumazet , LKML , 'Linux Samsung SOC' , Linux USB Mailing List , netdev@vger.kernel.org, Dean Jenkins Date: Mon, 05 Mar 2018 12:46:07 +0100 In-Reply-To: <02679502-cf6e-8714-e879-50a922c5d976@samsung.com> References: <1519740421.7296.6.camel@gmail.com> <1519744167.7296.8.camel@gmail.com> <1519744400.7296.10.camel@gmail.com> <1519747675.2649.3.camel@suse.com> <02679502-cf6e-8714-e879-50a922c5d976@samsung.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-03-05 at 08:45 +0100, Marek Szyprowski wrote: > Hi Oliver, > > On 2018-02-27 17:07, Oliver Neukum wrote: > > Am Dienstag, den 27.02.2018, 07:13 -0800 schrieb Eric Dumazet: > >> On Tue, 2018-02-27 at 07:09 -0800, Eric Dumazet wrote: > >>> > >>> Note that for this one, it seems we also could perform stats updates in > >>> BH context, since skb is queued via defer_bh() > >>> > >>> But simplicity wins I guess. > >> Thinking more about this, I am not sure we have any guarantee that TX > >> and RX can not run on multiple cpus. > >> > >> Using an unique syncp is not going to be safe, even if we make lockdep > >> happy enough with the local_irq save/restore. > > Unfortunately you are right. It is not guaranteed for some hardware. > > Does it mean that the fix proposed by Eric is not the proper solution? For asix it should work, but asix is unlikely to be the only driver with that issue. 32 bit recieves less testing nowadays. Regards Oliver