Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp576616ybh; Wed, 22 Jul 2020 07:59:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZ7JkTq6e5dQXGNxcUERbmmNdoHOD+VU4Z1XOaxE6rpn2I2QM4Rs9xV9jYcAYb4h1xWycm X-Received: by 2002:a17:906:f298:: with SMTP id gu24mr29968723ejb.302.1595429985381; Wed, 22 Jul 2020 07:59:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595429985; cv=none; d=google.com; s=arc-20160816; b=epf0unzv5EKZVUUVFbHr2nOfcFT+4/6UgnMkh521xAu8pBqKcKLtsKD6t3csN/qq9R o5Yncrz634RcqZxf+uFFH6KN88dUCq/jwdWrnDVKzTvHVnYvyMwJOyAVPOzYayJbvIk3 24vfC+ZU2riW10pjHpCGuPgCRSZHki1mquG7E8LGk5Qqj35+/xFXooKoR070NgcXhedH mgmhj0krCvzVfNyrkGcKPYv6VRvdSKkFmYvaTOfEsFm3uDFC+1+v42zjMtlBESTMeXvd CgCdMy4VY7OvjKVfjVGVp8kcmvQSVGmAjdyjbTJmx3BqOHT2COH/bHbn/HmYb9va3x1s mybg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=++Gann+18GS8SQ3NJyyJKZOGDbUfpDfbhd4fhwHlr8E=; b=ajePRj7LxKzx6MCKrCrZoAzp+6+E8nEj42trU0SP9GCsCmrb7+DFoKBsT5AP4lNp1H mc1jgIHhm0aD3A4zHEncmMaq4thXBWa/wPKQooYd5wliTyHafHB6StJfxvt3mHegftJ0 XvM0ykhLAPZQ2tdoyO1Q2IOmQFCfjma4YUN2vKuloC8KL/ufUo8t9muxqP8h9RbOcxJN bk9xkT+rPxPJcQcSQFwBXbSUEfKAUwo9ESE3YfLSK7wkwjm1e8esCb4PgO1cV5iNt+uU BS3fh4oQzJFzi8RDoPz+6DQc/kgmrsFsPjgsBCfmEOofMVJIlDOVbDYxDBsGit2Lpx8h gvRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a3si166583eju.177.2020.07.22.07.59.22; Wed, 22 Jul 2020 07:59:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732628AbgGVO7P (ORCPT + 99 others); Wed, 22 Jul 2020 10:59:15 -0400 Received: from netrider.rowland.org ([192.131.102.5]:52271 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1730465AbgGVO7O (ORCPT ); Wed, 22 Jul 2020 10:59:14 -0400 Received: (qmail 1314062 invoked by uid 1000); 22 Jul 2020 10:59:13 -0400 Date: Wed, 22 Jul 2020 10:59:13 -0400 From: Alan Stern To: Greg KH Cc: WeitaoWangoc , mathias.nyman@linux.intel.com, ulf.hansson@linaro.org, vkoul@kernel.org, hslester96@gmail.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Carsten_Schmid@mentor.com, efremov@linux.com, tonywwang@zhaoxin.com, weitaowang@zhaoxin.com, CobeChen@zhaoxin.com, TimGuo@zhaoxin.com, wwt8723@163.com Subject: Re: [PATCH] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci Message-ID: <20200722145913.GB1310843@rowland.harvard.edu> References: <1595419068-4812-1-git-send-email-WeitaoWang-oc@zhaoxin.com> <20200722124414.GA3153105@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200722124414.GA3153105@kroah.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 22, 2020 at 02:44:14PM +0200, Greg KH wrote: > On Wed, Jul 22, 2020 at 07:57:48PM +0800, WeitaoWangoc wrote: > > This bug is found in Zhaoxin platform, but it's a commom code bug. > > Fail sequence: > > step1: Unbind UHCI controller from native driver; > > step2: Bind UHCI controller to vfio-pci, which will put UHCI controller in one vfio > > group's device list and set UHCI's dev->driver_data to struct vfio-pci(for UHCI) > > Hah, that works? How do you do that properly? What code does that? Yeah, that can't possibly work. The USB core expects that any host controller device (or at least, any PCI host controller device) has its driver_data set to point to a struct usb_hcd. It doesn't expect a host controller to be bound to anything other than a host controller driver. Things could easily go very wrong here. For example, suppose at this point the ehci-hcd driver just happens to bind to the EHCI controller. When this happens, the EHCI controller hardware takes over all the USB connections that were routed to the UHCI controller. How will vfio-pci deal with that? Pretty ungracefully, I imagine. The only way to make this work at all is to unbind both uhci-hcd and ehci-hcd first. Then after both are finished you can safely bind vfio-pci to the EHCI controller and the UHCI controllers (in that order). Alan Stern