From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=VDyq=BF=vger.kernel.org=linux-usb-owner@kernel.org>
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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS 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 BA3C7C433E0
	for <linux-usb@archiver.kernel.org>; Sun, 26 Jul 2020 15:01:05 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 8ADE5206E3
	for <linux-usb@archiver.kernel.org>; Sun, 26 Jul 2020 15:01:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=default; t=1595775665;
	bh=T/S/ZMZmWeAVbtk2QRDxUTcXE1qpgmglLL+eWwGJDHc=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From;
	b=QPXfXKm0kd37oKqoxF5s0a2CV8en1y1ZhMS0GRuqpnDbpaoyJpgj/wmONz5HUzbu6
	 cOJXgo1iHJTiJn6bbH1Uu+35FE4kn4I/16uqeECzyoxhIGX4rfrxEGH2W60D4AqByq
	 3tJcKmsSXUNJtck8Q27sppaejO9KDKkLiBxOvLmg=
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726668AbgGZPBE (ORCPT <rfc822;linux-usb@archiver.kernel.org>);
        Sun, 26 Jul 2020 11:01:04 -0400
Received: from mail.kernel.org ([198.145.29.99]:43360 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1726042AbgGZPBD (ORCPT <rfc822;linux-usb@vger.kernel.org>);
        Sun, 26 Jul 2020 11:01:03 -0400
Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by mail.kernel.org (Postfix) with ESMTPSA id B8E072065F;
        Sun, 26 Jul 2020 15:01:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=default; t=1595775663;
        bh=T/S/ZMZmWeAVbtk2QRDxUTcXE1qpgmglLL+eWwGJDHc=;
        h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
        b=GAsgm5eC5hYxCsZAKh4kzsYmCsi74Jn7vwhHbN6n5y1oS27ucfQmoL14jOdltWSbp
         dtJa1lCK1ke+/1idJWniJNl0EwymV17sopxti8CZOUD/M+E2ej2wveEk7W3JHp8i9b
         ZQhDzUFYwF0U9zKDvjJNOlJhM5EwITvp6PFlhTt8=
Date:   Sun, 26 Jul 2020 17:01:00 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Alan Stern <stern@rowland.harvard.edu>
Cc:     Bastien Nocera <hadess@hadess.net>, linux-usb@vger.kernel.org
Subject: Re: [PATCH 3/3 v5] USB: Fix device driver race
Message-ID: <20200726150100.GC452766@kroah.com>
References: <ab1fcd9c7e8f4aecd1f709a74a763bcc239fe6c4.camel@hadess.net>
 <20200725145922.GC1421097@rowland.harvard.edu>
 <fa8f94ff5d62b42569b559a10638f952b2037145.camel@hadess.net>
 <20200725195707.GB1426415@rowland.harvard.edu>
 <20200726083655.GA448215@kroah.com>
 <20200726141708.GB1442605@rowland.harvard.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200726141708.GB1442605@rowland.harvard.edu>
Sender: linux-usb-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-usb.vger.kernel.org>
X-Mailing-List: linux-usb@vger.kernel.org

On Sun, Jul 26, 2020 at 10:17:08AM -0400, Alan Stern wrote:
> On Sun, Jul 26, 2020 at 10:36:55AM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Jul 25, 2020 at 03:57:07PM -0400, Alan Stern wrote:
> > > On Sat, Jul 25, 2020 at 05:24:20PM +0200, Bastien Nocera wrote:
> > > > On Sat, 2020-07-25 at 10:59 -0400, Alan Stern wrote:
> > > > <snip>
> > > > > > +	udev = to_usb_device(dev);
> > > > > > +	if (usb_device_match_id(udev, new_udriver->id_table) == NULL &&
> > > > > > +	    (!new_udriver->match || new_udriver->match(udev) != 0))
> > > > > > +		return 0;
> > > > > > +
> > > > > > +	(void)!device_reprobe(dev);
> > > > > 
> > > > > What's that '!' doing hiding in there?  It doesn't affect the final 
> > > > > outcome, but it sure looks weird -- if people notice it at all.
> > > > 
> > > > It's how we stop gcc from complaining about the warn_unused_result
> > > > attribute on device_reprobe()... (void) is enough with clang, but not
> > > > with gcc.
> > > 
> > > Hmmm.  Maybe this is an indication that device_reprobe() doesn't really 
> > > need to be __must_check.
> > > 
> > > Greg, do you know why it's annotated this way?
> > 
> > Because you really should pass up the return value if an error happens
> > here.  Why do we think it is safe to ignore?
> > 
> > And that "(void)!" is not ok, if the annotation is safe to ignore, then
> > we need to remove the annotation, don't work around stuff like this
> > without at the very least, a comment saying why it is ok.
> 
> I suppose Bastien could log an error message at that point.  There isn't 
> much else to do.

It looks like no one does anything with the return value of that
function, so we should just change it to void and stop checking it
entirely :(

greg k-h