Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp698553pxu; Wed, 7 Oct 2020 13:31:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJykd4RNlBUPJnUd+WTVqZY6IT9go1UjP6xXcnaMHrdnio9TW6Um2V0AL0Ez+Hvfcmk5Fs93 X-Received: by 2002:aa7:ce13:: with SMTP id d19mr3436417edv.68.1602102667410; Wed, 07 Oct 2020 13:31:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602102667; cv=none; d=google.com; s=arc-20160816; b=IpxcDqbo26MBoSXxwzKgPrjPD8GbFFaJHvqeH3Nrw9GyocAKAezrzcBBHGUfOfYIcy F24+B+rbOSbwC9qxpfjyNoDx+yY43Ds3QKQPrJJYWwTmUJfzFWGL9jGi678R/sRweZDi 0nvEUbQW18JjB5TWi4HfV+Sa5/mu6mwqdX54189qveKggpTwdGWWWEOKAIhi+n6ZPX3c hnzjt8WBGKhM4d8/anYTEoeGuAYlcQqiebwMidkRmb6N/3gfXllF4x7yXW4dn3UwDakw WBx16iDSuH97GjiOFNp7im5h92yMe5yXWlN89hrbQo6MLsrNd1u0ymBxRJzG8sxhXwb7 l4RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=pTGkoFSGDgsBo2cDBXyPbWf6aYkAt9LBpFd0aM1kX6c=; b=inv88okHAEcyh1WAYDPZkPJomfc7x5KcwefTcFcotwGeiLlUU4S3DVxoWm0QIhW32r bKQj6a5IxwoOIcfiGBwX2CcHDDiDJlfDcqpvsORHjReve3aIGijhYmgLiyFxGAFY486I 8t/7SpM2EWuA6XhSz5jKdGSvjD5XAkc70/IEsreP0pQuV4mXYuFKZruMa/01PZ2M78+B RtTrBmE+HNq3kLIEQXFSSyw/eN7mBjGztC43sWvELftEhnp/ER7OYM0ODqjfbh4Rhmud zcFgEN8KBuGM9SgHE9BeEU6dTV+r/VKTiqLYQsh0Fn3huR3ZAlnwAh2O96sK6Mm8KBOr epPA== 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 h24si2681713ejk.247.2020.10.07.13.30.42; Wed, 07 Oct 2020 13:31:07 -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 S1727261AbgJGUH4 (ORCPT + 99 others); Wed, 7 Oct 2020 16:07:56 -0400 Received: from netrider.rowland.org ([192.131.102.5]:49265 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726105AbgJGUH4 (ORCPT ); Wed, 7 Oct 2020 16:07:56 -0400 Received: (qmail 471050 invoked by uid 1000); 7 Oct 2020 16:07:55 -0400 Date: Wed, 7 Oct 2020 16:07:55 -0400 From: Alan Stern To: Andrey Konovalov Cc: Dmitry Vyukov , Andrew Morton , USB list , LKML , Greg Kroah-Hartman , Shuah Khan , Alexander Potapenko , Marco Elver , Aleksandr Nogikh , Nazime Hande Harputluoglu Subject: Re: [PATCH] kcov, usb, vhost: specify contexts for remote coverage sections Message-ID: <20201007200755.GD468921@rowland.harvard.edu> References: <8c71349c3cd9698b8edcfbfc9631c5dcc3b29a37.1602091732.git.andreyknvl@google.com> <20201007192945.GB468921@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 07, 2020 at 09:54:57PM +0200, Andrey Konovalov wrote: > On Wed, Oct 7, 2020 at 9:29 PM Alan Stern wrote: > > > > On Wed, Oct 07, 2020 at 07:30:51PM +0200, Andrey Konovalov wrote: > > > Currently there's a KCOV remote coverage collection section in > > > __usb_hcd_giveback_urb(). Initially that section was added based on the > > > assumption that usb_hcd_giveback_urb() can only be called in interrupt > > > context as indicated by a comment before it. > > > > > > As it turns out, it's actually valid to call usb_hcd_giveback_urb() in task > > > context, provided that the caller turned off the interrupts; USB/IP actually > > > does that. This can lead to a nested KCOV remote coverage collection > > > sections both trying to collect coverage in task context. This isn't > > > supported by KCOV, and leads to a WARNING. > > > > > > The approach this patch takes is to annotate every call of kcov_remote_*() > > > callbacks with the context those callbacks are supposed to be executed in. > > > If the current context doesn't match the mask provided to a callback, > > > that callback is ignored. KCOV currently only supports collecting remote > > > coverage in two contexts: task and softirq. > > > > > > As the result, the coverage from USB/IP related usb_hcd_giveback_urb() calls > > > won't be collected, but the WARNING is fixed. > > > > > > A potential future improvement would be to support nested remote coverage > > > collection sections, but this patch doesn't address that. > > > > > > Signed-off-by: Andrey Konovalov > > > --- > > > > > --- a/drivers/usb/core/hcd.c > > > +++ b/drivers/usb/core/hcd.c > > > @@ -1646,9 +1646,9 @@ static void __usb_hcd_giveback_urb(struct urb *urb) > > > > > > /* pass ownership to the completion handler */ > > > urb->status = status; > > > - kcov_remote_start_usb((u64)urb->dev->bus->busnum); > > > + kcov_remote_start_usb((u64)urb->dev->bus->busnum, KCOV_CONTEXT_SOFTIRQ); > > > urb->complete(urb); > > > - kcov_remote_stop(); > > > + kcov_remote_stop(KCOV_CONTEXT_SOFTIRQ); > > > > This isn't right. __usb_hcd_giveback_urb() can execute in pretty much > > any context; its constraint is that interrupts must be disabled. > > You're right, but here we constraint kcov to only collect coverage in > case __usb_hcd_giveback_urb() is executed in softirq context. This is > what happens when we're fuzzing USB with the dummy driver, which is > the case we currently take care of. Whenever someone has a desire to > collect coverage in other contexts, it will need to be implemented > separately. Oh, sorry. I thought the constraint meant that it would be an error if kcov observed __usb_hcd_giveback_urb() executing in anything other than softirq context. Alan Stern