From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 E1DE8C282CE for ; Tue, 4 Jun 2019 10:50:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B3F98242D9 for ; Tue, 4 Jun 2019 10:50:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727390AbfFDKuW (ORCPT ); Tue, 4 Jun 2019 06:50:22 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:36490 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727360AbfFDKuV (ORCPT ); Tue, 4 Jun 2019 06:50:21 -0400 Received: by mail-ed1-f66.google.com with SMTP id a8so31336428edx.3 for ; Tue, 04 Jun 2019 03:50:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GswYLqGRaCoWRXKqTcbui7vFFzTTGq9HoYdg6GrY5ng=; b=X4I3AZPQ1OWfPywRfvsWgs2yI9fS4HKezGPAWUW14N42lom89oyXsn4wax3q0TT3F/ Iqj4srDDf3o1rM2Riqtaz8LL97UHzbzkwoUqhA95Q1WR6PDwxvmnOlkN1VoYL81BKMcr 5ETxR7oBt5a85AJhhGQ11ww/TqedhseE6lhXwnp3TYgre4aBPvJDOdXxGpNSotcVa14i 0t5JkE03B3G86Bl4jTLKDuOcaCxUFwcsd0hpBTbUg6gkNdSTDsARdYkr7F5ywt36lsDb u1y15+dsY1bS1MvgebP1rCQYKwh7wgOz8DOnyK5XXdcreARQoj29v9h2Vzb7jZi7wl45 i9QA== X-Gm-Message-State: APjAAAUHFsM6zNGPYH4jmv5Im2gwgymvG8Tpx9ZSzUQjimuldJJzhssy o75jsCxnlK16mpbUwgOsqqT5P9pVp5Q= X-Google-Smtp-Source: APXvYqzoDFOet7Lo34yPYlfRGZnQ9ln8w6++jxu3zepHc1RCYOdCNSGhOVydoTfAqDRUOqQD2Zdv0g== X-Received: by 2002:a05:6402:1701:: with SMTP id y1mr33319483edu.22.1559645419648; Tue, 04 Jun 2019 03:50:19 -0700 (PDT) Received: from shalem.localdomain (84-106-84-65.cable.dynamic.v4.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id y6sm3089886eju.4.2019.06.04.03.50.18 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 03:50:19 -0700 (PDT) Subject: Re: hid-related 5.2-rc1 boot hang To: Benjamin Tissoires Cc: Jiri Kosina , Dave Hansen , "open list:HID CORE LAYER" , LKML References: <2c1684f6-9def-93dc-54ab-888142fd5e71@intel.com> <8a17e6e2-b468-28fd-5b40-0c258ca7efa9@intel.com> <4689a737-6c40-b4ae-cc38-5df60318adce@redhat.com> <5471f010-cb42-c548-37e2-2b9c9eba1184@redhat.com> From: Hans de Goede Message-ID: Date: Tue, 4 Jun 2019 12:50:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 04-06-19 12:08, Benjamin Tissoires wrote: > On Tue, Jun 4, 2019 at 9:51 AM Benjamin Tissoires > wrote: >> >> On Mon, Jun 3, 2019 at 4:17 PM Hans de Goede wrote: >>> >>> Hi, >>> >>> On 03-06-19 15:55, Benjamin Tissoires wrote: >>>> On Mon, Jun 3, 2019 at 11:51 AM Hans de Goede wrote: >>>>> >>>>> Hi Again, >>>>> >>>>> On 03-06-19 11:11, Hans de Goede wrote: >>>>> >>>>> >>>>>>> not sure about the rest of logitech issues yet) next week. >>>>>> >>>>>> The main problem seems to be the request_module patches. Although I also >>>> >>>> Can't we use request_module_nowait() instead, and set a reasonable >>>> timeout that we detect only once to check if userspace is compatible: >>>> >>>> In pseudo-code: >>>> if (!request_module_checked) { >>>> request_module_nowait(name); >>>> use_request_module = wait_event_timeout(wq, >>>> first_module_loaded, 10 seconds in jiffies); >>>> request_module_checked = true; >>>> } else if (use_request_module) { >>>> request_module(name); >>>> } >>> >>> Well looking at the just attached dmesg , the modprobe >>> when triggered by udev from userspace succeeds in about >>> 0.5 seconds, so it seems that the modprobe hangs happens >>> when called from within the kernel rather then from within >>> userspace. >>> >>> What I do not know if is the hang is inside userspace, or >>> maybe it happens when modprobe calls back into the kernel, >>> if the hang happens when modprobe calls back into the kernel, >>> then other modprobes (done from udev) likely will hang too >>> since I think only 1 modprobe can happen at a time. >>> >>> I really wish we knew what distinguished working systems >>> from non working systems :| >>> >>> I cannot find a common denominator; other then the systems >>> are not running Fedora. So far we've reports from both Ubuntu 16.04 >>> and Tumbleweed, so software version wise these 2 are wide apart. >> >> I am trying to reproduce the lock locally, and installed an opensuse >> Tumbleweed in a VM. When forwarding a Unifying receiver to the VM, I >> do not see the lock with either my vanilla compiled kernel and the rpm >> found in http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/ >> >> Next step is install Tumbleweed on bare metal, but I do not see how >> this could introduce a difference (maybe USB2 vs 3). > > Making progress here. > > The difference between Ubuntu/Tumbleweed and Fedora: usbhid is shipped > as a module while in Fedora usbhid is included in the kernel. > > If I rmmod hid_* and usbhid, then modprobe usbhid, the command hangs > for 3 minutes. > If usbhid is already loaded, inserting a receiver is immediate > regarding the loading of the external modules. > > So my assumption is that when the device gets detected at boot, usbhid > gets loaded by the kernel event, which in turns attempts to call > __request_module, but the modprobe can't be fulfilled because it's > already waiting for the initial usbhid modprobe to finish. > > Still don't know how to solve that, but I thought I should share. Hmm, we may be hitting the scenario described in the big comment around line 3500 of kernel/module.c. But I'm not sure that is what is happening here. Maybe you can put a WARN_ON(1) in request_module and look at the backtrace ? That may help to figure out what is going on; or alternatively it might help to find some way to detect this and if it happens skip the request_module... Regards, Hans