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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 45492C25B74 for ; Thu, 16 May 2024 17:17:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=auXbR2K9+bJ+MdkTKTqlxAnaIqI3ZmRd2eEJiZq4JYM=; b=jXVtkejqdGIiO0 Pdcsm1Q/CWFUrE95TVSBJI2lRi1QVJ5+2MDnTnEf6i4SUdYjAEfMQKDMLxkJSAoDH8kpha+0rjGBm +IfjdAgBiIhsXS+c4jN/Tgna7yxXrw7z4qSyGQAu/LewP+JaFX/A6s6mrTTD5IBb8V5+sUmeYe6HO 5XoHoLubdEVjVvUqi6ufn7934TDswxsC3qhhLm7e3TruE2b3UUQJ/GzQddHVwz61uQAaIWMtjjz5M lVMMWCucmJCYJ0qJyge4b6QJ9uO1DcxrgzqoErSngux+GdxduS1z89HcXV6izC9UBJxs4yq0TNgfu PXM0F8rdzyl4Erf8a1Dg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7eis-00000005czv-2R5z; Thu, 16 May 2024 17:16:54 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7eio-00000005cyo-2uKV for linux-arm-kernel@lists.infradead.org; Thu, 16 May 2024 17:16:53 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EDF62DA7; Thu, 16 May 2024 10:17:10 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 021903F641; Thu, 16 May 2024 10:16:45 -0700 (PDT) Date: Thu, 16 May 2024 18:16:40 +0100 From: Dave Martin To: Marc Zyngier Cc: Johannes Nixdorf , Ard Biesheuvel , Mark Brown , linux-arm-kernel@lists.infradead.org Subject: Re: [BUG] dm-crypt broken after 2632e2521769 ("arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD") Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240516_101651_106027_4E2E9544 X-CRM114-Status: GOOD ( 22.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, May 16, 2024 at 05:25:32PM +0100, Marc Zyngier wrote: > + Ard, Broonie > > On 2024-05-16 17:22, Johannes Nixdorf wrote: > > I noticed frequent FS corruption on my M1 MacBook running Linux after > > the Asahi Linux Kernel was updated to 6.9.x (from 6.6.x). > > > > A git bisect pointed me to 2632e2521769 ("arm64: fpsimd: Implement lazy > > restore for kernel mode FPSIMD"). It's a while since I worked on this code, and things have moved in the meantime, but there seems to be an asymmetry between where fpsimd_bind_state_to_cpu() is called here and where the analogous fpsimd_bind_task_to_cpu() is called for the regular task state. Originally, these hooks did the bookkeeping at load-time to record where the state is loaded. To record this info for the user task state at sched-in time but to defer it until sched-out time for the kernel state looks weird to me. I'd be concerned that the state is getting messed up on the back of an interrupt or similar in the meantime. I haven't fully understood what the current version of this code is doing, but that might be a place to start looking... Cheers ---Dave > > > > This was reproduced with fio's examples/basic-verify.fio (1GB of writing > > was not reliably, 10GB triggered it reliably) on vanilla kernels and > > happens on any storage backend behind dm-crypt. > > > > I was advised to report it here on IRC. > > > > This was independently described in [1]. > > > > Regards, > > Johannes Nixdorf > > > > [1]: https://github.com/tpwrules/nixos-apple-silicon/issues/200 > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > -- > Jazz is not dead. It just smells funny... > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel