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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7ECCBC43334 for ; Wed, 15 Jun 2022 16:42:15 +0000 (UTC) Received: from localhost ([::1]:38358 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o1W5u-00056Z-Hs for qemu-devel@archiver.kernel.org; Wed, 15 Jun 2022 12:42:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51524) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1Vn7-0006rA-UC for qemu-devel@nongnu.org; Wed, 15 Jun 2022 12:22:49 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:60152) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1Vmy-0000jv-Bo for qemu-devel@nongnu.org; Wed, 15 Jun 2022 12:22:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655310159; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0KbSr9tlgrnkFefo2XMsWhb4fkrBWFJbk9/ky+3k0c0=; b=D8IH2Vw5M93SFhBuPeEWVN9amGmaq2yOMNu4ZDsjphvMZnh5mOSzy/tOYf6KcX13Y53PKx ZQNNUa9VCj6RdKRLPxs5l4hbjds1BTwygNQc/o2MSYSLuOmK41Ovb3IfB4kdY1rkWyUbO7 uMLlB40hSUr1Z9f4zGVTXJJgye5FuTE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-206-cPGbbvbgOrev2bzgthc7Ug-1; Wed, 15 Jun 2022 12:22:36 -0400 X-MC-Unique: cPGbbvbgOrev2bzgthc7Ug-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C8E6B802804; Wed, 15 Jun 2022 16:22:35 +0000 (UTC) Received: from redhat.com (unknown [10.33.36.65]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5AF07C2810D; Wed, 15 Jun 2022 16:22:33 +0000 (UTC) Date: Wed, 15 Jun 2022 17:22:30 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: John Snow Cc: Thomas Huth , qemu-devel , Qemu-block , Beraldo Leal , Wainer dos Santos Moschetta , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Alex =?utf-8?Q?Benn=C3=A9e?= , Hanna Reitz , Kevin Wolf Subject: Re: [PATCH 2/5] tests/qemu-iotests: skip 108 when FUSE is not loaded Message-ID: References: <20220614015044.2501806-1-jsnow@redhat.com> <20220614015044.2501806-3-jsnow@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.1 (2022-02-19) X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, Jun 15, 2022 at 11:48:02AM -0400, John Snow wrote: > On Wed, Jun 15, 2022 at 11:33 AM Daniel P. Berrangé wrote: > > > > On Wed, Jun 15, 2022 at 09:41:32AM -0400, John Snow wrote: > > > On Tue, Jun 14, 2022 at 10:30 AM John Snow wrote: > > > > > > > > On Tue, Jun 14, 2022 at 4:59 AM Daniel P. Berrangé wrote: > > > > > > > > > > On Tue, Jun 14, 2022 at 06:46:35AM +0200, Thomas Huth wrote: > > > > > > On 14/06/2022 03.50, John Snow wrote: > > > > > > > In certain container environments we may not have FUSE at all, so skip > > > > > > > the test in this circumstance too. > > > > > > > > > > > > > > Signed-off-by: John Snow > > > > > > > --- > > > > > > > tests/qemu-iotests/108 | 6 ++++++ > > > > > > > 1 file changed, 6 insertions(+) > > > > > > > > > > > > > > diff --git a/tests/qemu-iotests/108 b/tests/qemu-iotests/108 > > > > > > > index 9e923d6a59f..e401c5e9933 100755 > > > > > > > --- a/tests/qemu-iotests/108 > > > > > > > +++ b/tests/qemu-iotests/108 > > > > > > > @@ -60,6 +60,12 @@ if sudo -n losetup &>/dev/null; then > > > > > > > else > > > > > > > loopdev=false > > > > > > > + # Check for fuse support in the host environment: > > > > > > > + lsmod | grep fuse &>/dev/null; > > > > > > > > > > > > That doesn't work if fuse has been linked statically into the kernel. Would > > > > > > it make sense to test for /sys/fs/fuse instead? > > > > > > > > > > > > (OTOH, we likely hardly won't run this on statically linked kernels anyway, > > > > > > so it might not matter too much) > > > > > > > > > > But more importantly 'lsmod' may not be installed in our container > > > > > images. So checking /sys/fs/fuse avoids introducing a dep on the > > > > > 'kmod' package. > > > > > > > > > > > > > > > > > > + if [[ $? -ne 0 ]]; then > > > > > > > > > > > > I'd prefer single "[" instead of "[[" ... but since we're requiring bash > > > > > > anyway, it likely doesn't matter. > > > > > > > > > > Or > > > > > > > > > > if test $? != 0 ; then > > > > > > > > > > > > > > > > > > + _notrun 'No Passwordless sudo nor FUSE kernel module' > > > > > > > + fi > > > > > > > + > > > > > > > # QSD --export fuse will either yield "Parameter 'id' is missing" > > > > > > > # or "Invalid parameter 'fuse'", depending on whether there is > > > > > > > # FUSE support or not. > > > > > > > > > > > > > > Good suggestions, thanks! > > > > > > > > > > I think I need to test against /dev/fuse instead, because /sys/fs/fuse > > > actually exists, but because of docker permissions (etc), FUSE isn't > > > actually usable from the child container. > > > > > > I wound up with this: > > > > > > # Check for usable FUSE in the host environment: > > > if test ! -c "/dev/fuse"; then > > > _notrun 'No passwordless sudo nor usable /dev/fuse' > > > fi > > > > > > Seems to work for my case here, at least, but I don't have a good > > > sense for how broadly flexible it might be. It might be nicer to > > > concoct some kind of NOP fuse mount instead, but I wasn't able to > > > figure out such a command quickly. > > > > > > The next problem I have is actually related; test-qga (for the > > > Centos.x86_64 run) is failing because the guest agent is reading > > > /proc/self/mountinfo -- which contains entries for block devices that > > > are not visible in the current container scope. I think when QGA goes > > > to read info about these devices to populate a response, it chokes. > > > This might be a genuine bug in QGA if we want it to tolerate existing > > > inside of a container. > > > > Yes, we should fix this. Even if you don't run QGA in a container, > > someone might configure the systemd service to harden it, by > > restricting what /dev it is able to see and thus trigger the > > same issue. > > Naive solution: if we try to look in /sys/dev/block/%u:%u and find > that we are unable to do so for whatever reason (ENOENT et al), just > skip that entry for the fsinfo returned to the caller. > > Does it need to be fancier than that? /sys stuff maybe unfiltered, while /dev is restricted. I've not looked at the QGA code for this, but conceptually I think I would just identify where in the code errors hit, and ignore the appropriate error conditions. The goal is to return as much info as we reasonably can offer, given our execution environment constraints. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|