Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3221846ybc; Mon, 25 Nov 2019 10:54:03 -0800 (PST) X-Google-Smtp-Source: APXvYqxhwyvCfByBS7b00/NCsPiVMKQEVjEb2bPnOGNciEhmcPLQnc4iGNNx3JsoM1xJa78P2QV2 X-Received: by 2002:a17:906:6093:: with SMTP id t19mr38425774ejj.50.1574708043464; Mon, 25 Nov 2019 10:54:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574708043; cv=none; d=google.com; s=arc-20160816; b=YzGfxB4a0Ie+OrhXCqpE+TdKmqqYyRyMjzpF/bXpFib1+txsJw0VyFjWSC1VnJgKXx TdNbTqqhfL6YQtfavp896u17OURBpMRMs/BvTIGN+GZUPUwLyrhmlfJyplCcZmnlOgOk XWQyUsvdg+uEPgYmPo3eTIyDITuUg/onH26k0ddcEv5qSHd5ZWCzMPxN/T2R9P4c/p8N JZds3hxeeuPiHM29hNtmzW1JkzXjxO+wXa2SIY6NmLmOSGYPB967rD88rMTsiEuan3bA /602Csozmt53SYlfpEZUWCNAiLS8lJCjUImF0SPG6lp/3GB6Lw+pIfeBPP5Hba8fRgdg l8tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=2ziB2ILEHtB0VF8KrM5HLP18HZJGbVhN9aAvZZ9wf6o=; b=gDiP7C0b2nqBsI6jZinZa5s7XIPx/gu1OuaICgG56aXVp/Ac6rg89+qtWZcQK6c2Oq 6S8B868CRNTJKKoHxSpTH6VSS3QfOWXN0+EVy9CU1gpUt1jYi8oDi0GLJ92QwMBkOU8H rX9loZunC2/cfuZTKETX2YiTRLSEKxLisV1hvHSOp2UHige6EsXId0YMAJtg9mtozTZ4 1VJMUdoU2op0FXfRsJcerX63tKIpvHO5p4JEwZswuBbt6501IBpvY669QlArtIOCtAzS AtW7w4kup05VBlaxM6+xGRfge4MviK1oRsmxEpZkxrKICv/u56TyFqfamA91PtsfWlrY lIsQ== 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 x28si7145832edl.21.2019.11.25.10.53.40; Mon, 25 Nov 2019 10:54:03 -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 S1729086AbfKYRaO (ORCPT + 99 others); Mon, 25 Nov 2019 12:30:14 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:58016 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1725868AbfKYRaN (ORCPT ); Mon, 25 Nov 2019 12:30:13 -0500 Received: (qmail 4379 invoked by uid 2102); 25 Nov 2019 12:30:12 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Nov 2019 12:30:12 -0500 Date: Mon, 25 Nov 2019 12:30:12 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Jiri Kosina , Andrey Konovalov cc: syzbot , Benjamin Tissoires , , LKML , USB list , syzkaller-bugs Subject: Re: INFO: rcu detected stall in hub_event In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jiri: On Sat, 23 Nov 2019, Andrey Konovalov wrote: > I'm not sure, but the stack trace reminds me of this issue, so this > report might be related: > > https://groups.google.com/d/msg/syzkaller-bugs/X0zVbh8aFEM/NsPcshjxBgAJ No, the issue is quite different, although it is also a bug in the HID parser. The big problem is that the parser assumes all usages will belong to a collection. There's also a second, smaller bug: hid_apply_multipler() assumes every Resolution Multiplier control is associated with a Logical Collection (i.e., there's no way the routine can ever set multiplier_collection to NULL) even though there's a big quotation from the HID Usage Table manual at the start of the function saying that they don't have to be. This bug can be fixed easily, though. The first bug is more troublesome. hid_add_usage() explicitly sets the parser->local.collection_index[] entry to 0 if the current collection stack is empty. But there's no way to distinguish this 0 from a genuine index value that happens to point to the first collection! So what should happen when a usage appears outside of all collections? Is it a bug in the report descriptor (the current code suggests that it is not)? Or should we use a different sentinel value for the collection_index[] entry, one that cannot be confused with a genuine value, such as UINT_MAX? Awaiting your suggestion... Alan Stern