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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2D78C433FE for ; Tue, 2 Nov 2021 23:33:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B641E60FC2 for ; Tue, 2 Nov 2021 23:33:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230471AbhKBXgF (ORCPT ); Tue, 2 Nov 2021 19:36:05 -0400 Received: from todd.t-8ch.de ([159.69.126.157]:45095 "EHLO todd.t-8ch.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230054AbhKBXgD (ORCPT ); Tue, 2 Nov 2021 19:36:03 -0400 Date: Tue, 2 Nov 2021 23:33:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=t-8ch.de; s=mail; t=1635896007; bh=EoDfytdV+LSXDNnXqYAA0Tk6wiOd883CujH+OC5GBas=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=IquYBEBhTXBPDy7frCaGYIJqGtKLZuQ+tsWQKdUr1a2M98cA6+yiEWUhGjTILhtwG fOP8s56lQBrnbyH18VNfzjGTElO3YRWvBxaminNvTFmAo70QuiUpRz2o3Egeuexx16 zX+WtIhN85oWC/FhoLy5BsJ9tIliaBHOrTtT6D7U= From: =?UTF-8?Q?Thomas_Wei=C3=9Fschuh_?= To: Dominique Martinet Cc: =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , Eric Van Hensbergen , Latchesar Ionkov , "David S. Miller" , Jakub Kicinski , v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: <778dfd93-ace5-4cab-9a08-21d279f18c1f@t-8ch.de> In-Reply-To: References: <20211017134611.4330-1-linux@weissschuh.net> <922a4843-c7b0-4cdc-b2a6-33bf089766e4@t-8ch.de> <3e8fcaff-6a2e-4546-87c9-a58146e02e88@t-8ch.de> Subject: Re: [PATCH] net/9p: autoload transport modules MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: <778dfd93-ace5-4cab-9a08-21d279f18c1f@t-8ch.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Nov 3, 2021 00:18:13 Dominique Martinet : > Thomas Wei=C3=9Fschuh wrote on Tue, Nov 02, 2021 at 04:32:21PM +0100: >>> with 9p/9pnet loaded, >>> running "mount -t 9p -o trans=3Dvirtio tmp /mnt" >>> request_module("9p-%s", "virtio") returns -2 (ENOENT) >> >> Can you retry without 9p/9pnet loaded and see if they are loaded by the = mount >> process? >> The same autoloading functionality exists for filesystems using >> request_module("fs-%s") in fs/filesystems.c >> If that also doesn't work it would indicate an issue with the kernel set= up in general. > > Right, that also didn't work, which matches modprobe not being called > correctly > > >>> Looking at the code it should be running "modprobe -q -- 9p-virtio" >>> which finds the module just fine, hence my supposition usermodhelper is >>> not setup correctly >>> >>> Do you happen to know what I need to do for it? >> >> What is the value of CONFIG_MODPROBE_PATH? >> And the contents of /proc/sys/kernel/modprobe? > > aha, these two were indeed different from where my modprobe is so it is > a setup problem -- I might have been a little rash with this initrd > setup and modprobe ended up in /bin with path here in /sbin... > > Thanks for the pointer, I saw the code setup an environment with a > full-blown PATH so didn't think of checking if this kind of setting > existed! > All looks in order then :) Does it also work for the split out FD transports? If so, I'll resend that patch in a proper form tomorrow. Thomas