Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp1059479rda; Mon, 23 Oct 2023 00:36:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFq3q+lLohs20gR+zSEu6a4yoEqBlXNVNzj6fcQqBtpT6CTzPXFfxELvRbAr6umsZaoiAq7 X-Received: by 2002:a05:6870:15c6:b0:1e9:960f:894b with SMTP id k6-20020a05687015c600b001e9960f894bmr11178287oad.46.1698046560429; Mon, 23 Oct 2023 00:36:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698046560; cv=none; d=google.com; s=arc-20160816; b=ZsO0ufrgQ8ZZlpz9YlYV8mQeSGRNYEgHcNWIoVPvaNyocz0Ntg6jnZUpghwJKTcfKD kWgSR6Y/dQ+pdXVfGNMLPbVr6gaooezcDIbzO6emJanv4qoT7gAYSlrIuqSB+FOXUXWg kS+FfChoX6Ki/vgYNPCVsVFOGw5jIQi6iAJgT/BrHfP6cZmYRUjBp6+gXj/xUXuOWSdy yhbEkSdVQNH7rypgc0YkxNS7TQS0/WRPE2lRv4iMSJ8kvDGafApGF5ktjlcAVv20k16V vcSQEnmUBHZ131VPgBTVSjTd1V0tejlK20vnPERFMC7xlh6E24OpcVLf5ABwGtntL4WK hb9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :content-language:references:cc:to:from:user-agent:mime-version:date :message-id:feedback-id:dkim-signature:dkim-signature; bh=d9amFDYz1sl2Iw6yhNUKRAnYTQtpJelLSp1Dm00CDPs=; fh=jz6IBWw+NgTfsGN9dyOlcHHw/4bbRPjG+rUh2WIT7BQ=; b=LPD2grSmQFuWGCJytkIbt/Xc1oji6iAfwXlO/Ik2M5g95q9eNcfWTpKN5pxMkgoGo2 BZbz53GuWGl41qYu51dPIPtTjY4a5v3WrhLwYTZ/1aq5pw9N9q+lKiBAoukq2roi1eSf RAPN5CxsqWIHnSMtCdnRdYIfsDUpLaDaRIaInFIWotJFIdUEe1/WUizyXn8wGqu6STnB gL+Rq95ILD0bg0gkga19HiuRdPgCDLm+l6o+ERoVJg0S1mXsBBq6LLypCZaKrSR+Oz7w O3KQFbv8sY5EB76FlmG9n/BT+gXipn9hhhXISGgWxlRUoA7vjA7yS/P4oap1PTHTONUP 1tfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@themaw.net header.s=fm2 header.b=TVTYvBMl; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=cvj+733t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id ck25-20020a056a02091900b0055c8d58cee9si5967910pgb.714.2023.10.23.00.36.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Oct 2023 00:36:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@themaw.net header.s=fm2 header.b=TVTYvBMl; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=cvj+733t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id B608C8087B64; Mon, 23 Oct 2023 00:35:57 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233491AbjJWHfj (ORCPT + 99 others); Mon, 23 Oct 2023 03:35:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233443AbjJWHfg (ORCPT ); Mon, 23 Oct 2023 03:35:36 -0400 Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33AD3C5; Mon, 23 Oct 2023 00:35:34 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id D14D83200973; Mon, 23 Oct 2023 03:35:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 23 Oct 2023 03:35:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1698046532; x=1698132932; bh=d9amFDYz1sl2Iw6yhNUKRAnYTQtpJelLSp1 Dm00CDPs=; b=TVTYvBMlNM4+fgbnJ7BWdOJA4mRcfzAVuAe7ZNzCMUtj18rXjno EaawTlGh8yP95b0hOO6u7J/XkcuFnG7xdlu/EbXRbzsoj1myTl5qdoXCztmuiNuz eSW1dr+3kS9PaMsTrGqHh4C9QDSBssXLx+4josIghBoXMlQH2rXaaO5P6Y18QGyN SbZO5Ya0rvzuA/zq/PF1QC2m1HHGgIYU+3z9BWC4jwfI4m2ou+a0y09BTRlG7EDt +FhvKXT9w+wpGaDNCwcpcb1Jhz661AKDsXnOvjOlzjsv1MovuWQGktw23Ghfgytu X4QWvmBaPa/pkOSdm4m9hdvdqfkE8VlWotw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1698046532; x=1698132932; bh=d9amFDYz1sl2Iw6yhNUKRAnYTQtpJelLSp1 Dm00CDPs=; b=cvj+733ts4j523wzds2wIrWGXz43l1yy21zW3D6XXrDFFhWaI5h ckZ6SZkPetQuDQvs9ip/0zeM6McvjKL2entMt4RK4A/g611DxKeFINWrLJ8JVwLM k91ZrYCEQtNErofVqnDUG4Psydm8ekc+HmUNIfn5xvy08EuBW13NaK9V4ZSonsI5 sBi1MrDD/ulxRY9uN+y9t9mKDxWNTClfPRyiKDspAdDFEw/7V4DLnTwBtLqa0Axz arzG9mtvAh45RKDHdLe/P86oKXkwE2KCpR9t5xboJVujCmHbA12GciRWkyKIdrEb Wb1I0ZewIibf8MI24mU54KpbwYzoq+vgG3Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrkeehgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfhffvvehfufgjtgfgsehtkeertddtfeejnecuhfhrohhmpefkrghn ucfmvghnthcuoehrrghvvghnsehthhgvmhgrfidrnhgvtheqnecuggftrfgrthhtvghrnh epkeeuffekhfffteejieekvedthfeghfegteefvdegveevjeegffelleffkeevjedtnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhgrvhgvnh esthhhvghmrgifrdhnvght X-ME-Proxy: Feedback-ID: i31e841b0:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 23 Oct 2023 03:35:28 -0400 (EDT) Message-ID: Date: Mon, 23 Oct 2023 15:35:24 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 From: Ian Kent To: Arnd Bergmann , Dan Carpenter , Anders Roxell Cc: Naresh Kamboju , open list , lkft-triage@lists.linaro.org, linux-fsdevel@vger.kernel.org, autofs@vger.kernel.org, Bill O'Donnell , Christian Brauner References: <71adfca4-4e80-4a93-b480-3031e26db409@app.fastmail.com> <432f1c1c-2f77-4b1b-b3f8-28330fd6bac3@kadam.mountain> <11ba98f2-2e59-d64b-1a1a-fd32fd8ba358@themaw.net> <9217caeb-0d7e-b101-33f0-859da175a6ef@themaw.net> Content-Language: en-US Subject: Re: autofs: add autofs_parse_fd() In-Reply-To: <9217caeb-0d7e-b101-33f0-859da175a6ef@themaw.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 23 Oct 2023 00:35:57 -0700 (PDT) On 23/10/23 08:48, Ian Kent wrote: > On 20/10/23 21:09, Ian Kent wrote: >> On 20/10/23 19:23, Arnd Bergmann wrote: >>> On Fri, Oct 20, 2023, at 12:45, Dan Carpenter wrote: >>>> On Fri, Oct 20, 2023 at 11:55:57AM +0200, Anders Roxell wrote: >>>>> On Fri, 20 Oct 2023 at 08:37, Arnd Bergmann wrote: >>>>>> On Thu, Oct 19, 2023, at 17:27, Naresh Kamboju wrote: >>>>>>> The qemu-x86_64 and x86_64 booting with 64bit kernel and 32bit >>>>>>> rootfs we call >>>>>>> it as compat mode boot testing. Recently it started to failed to >>>>>>> get login >>>>>>> prompt. >>>>>>> >>>>>>> We have not seen any kernel crash logs. >>>>>>> >>>>>>> Anders, bisection is pointing to first bad commit, >>>>>>> 546694b8f658 autofs: add autofs_parse_fd() >>>>>>> >>>>>>> Reported-by: Linux Kernel Functional Testing >>>>>>> Reported-by: Anders Roxell >>>>>> I tried to find something in that commit that would be different >>>>>> in compat mode, but don't see anything at all -- this appears >>>>>> to be just a simple refactoring of the code, unlike the commits >>>>>> that immediately follow it and that do change the mount >>>>>> interface. >>>>>> >>>>>> Unfortunately this makes it impossible to just revert the commit >>>>>> on top of linux-next. Can you double-check your bisection by >>>>>> testing 546694b8f658 and the commit before it again? >>>>> I tried these two patches again: >>>>> 546694b8f658 ("autofs: add autofs_parse_fd()") - doesn't boot >>>>> bc69fdde0ae1 ("autofs: refactor autofs_prepare_pipe()") - boots >>>>> >>>> One difference that I notice between those two patches is that we no >>>> long call autofs_prepare_pipe().  We just call autofs_check_pipe(). >>> Indeed, so some of the f_flags end up being different. I assumed >>> this was done intentionally, but it might be worth checking if >>> the patch below makes any difference when the flags get put >>> back the way they were. This is probably not the correct fix, but >>> may help figure out what is going on. It should apply to anything >>> from 546694b8f658 ("autofs: add autofs_parse_fd()") to the current >>> linux-next: >>> >>> --- a/fs/autofs/inode.c >>> +++ b/fs/autofs/inode.c >>> @@ -358,6 +358,11 @@ static int autofs_fill_super(struct super_block >>> *s, struct fs_context *fc) >>>          pr_debug("pipe fd = %d, pgrp = %u\n", >>>                   sbi->pipefd, pid_nr(sbi->oz_pgrp)); >>>   +        /* We want a packet pipe */ >>> +        sbi->pipe->f_flags |= O_DIRECT; >>> +        /* We don't expect -EAGAIN */ >>> +        sbi->pipe->f_flags &= ~O_NONBLOCK; >>> + >> >> >> That makes sense, we do want a packet pipe and that does also mean >> >> we don't want a non-blocking pipe, it will be interesting to see >> >> if that makes a difference. It's been a long time since Linus >> >> implemented that packet pipe and I can't remember now what the >> >> case was that lead to it. > > After thinking about this over the weekend I'm pretty sure my mistake > > is dropping the call to autofs_prepare_pipe() without adding the tail > > end of it into autofs_parse_fd(). > > > To explain a bit of history which I'll include in the fix description. > > During autofs v5 development I decided to stay with the existing usage > > instead of changing to a packed structure for autofs <=> user space > > communications which turned out to be a mistake on my part. > > > Problems arose and they were fixed by allowing for the 64 bit to 32 bit > > size difference in the automount(8) code. > > > Along the way systemd started to use autofs and eventually encountered > > this problem too. systemd refused to compensate for the length difference > > insisting it be fixed in the kernel. Fortunately Linus implemented the > > packetized pipe which resolved the problem in a straight forward and > > simple way. > > > So I pretty sure that the cause of the problem is the inadvertent > dropping > > of the flags setting in autofs_fill_super() that Arnd spotted although I > > don't think putting it in autofs_fill_super() is the right thing to do. > > > I'll produce a patch today which includes most of this explanation for > > future travelers ... So I have a patch. I'm of two minds whether to try and use the instructions to reproduce this or not because of experiences I have had with other similar testing automation systems that claim to provide a reproducer and end up a huge waste of time and are significantly frustrating. Can someone please perform a test for me once I provide the patch? Ian > > >> >> >> Ian >> >>>          sbi->flags &= ~AUTOFS_SBI_CATATONIC; >>>            /*