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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,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 91C95C48BDF for ; Fri, 18 Jun 2021 15:25:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7C3E2613D1 for ; Fri, 18 Jun 2021 15:25:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231452AbhFRP1z (ORCPT ); Fri, 18 Jun 2021 11:27:55 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:56732 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235071AbhFRPXM (ORCPT ); Fri, 18 Jun 2021 11:23:12 -0400 Message-Id: <20210618143451.217774510@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1624029632; h=from:from: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: references:references; bh=88dRg3kAphcDYCyKUbz0ku2MO/LIcKQhueya46CMhW4=; b=clgM5JyKfgBE/0NZxkVDHoFNK67yEpc9Qo0A/y8Gbyk7HmsaT1K0Y/fom+A2eD7x+TcbTS 4IUq7sv0DxEkk1w5AC5ZzR8B7kxXFJxKkLe8NHWL3g1cCVnB2/I/nCE2Ee0JFct8wrIX7v EvEVpzoUupNQiK/msQ9mjycpd3Tsh+iLx3M4mp1HJSI6l4ifzlyPpBpgdhFJHLI035KqFI t1Qe/93tPixwFxYTaXYeh5ScGUojEiGFTziDOwbqLbBqcTHiWfXGDyK0LJEjKUdFb6Hamt 2BhnbEgdrTa8WzBbrEb62SMGR16Mpgs4holvshbq96z0QD6FbljEwrWZURJTCA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1624029632; h=from:from: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: references:references; bh=88dRg3kAphcDYCyKUbz0ku2MO/LIcKQhueya46CMhW4=; b=M4PvOM5ZfPkdrrbz80zW5L0qXm25vf0ANB5ylTgPBBM1A5/YZBhCgxUMgtUlDkGhCXFuEm CxMzZQnhBrd4L3Cg== Date: Fri, 18 Jun 2021 16:19:23 +0200 From: Thomas Gleixner To: LKML Cc: Andy Lutomirski , Dave Hansen , Fenghua Yu , Tony Luck , Yu-cheng Yu , Sebastian Andrzej Siewior , Borislav Petkov , Peter Zijlstra , Kan Liang Subject: [patch V3 60/66] x86/fpu/signal: Remove the legacy alignment check References: <20210618141823.161158090@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Checking for the XSTATE buffer being 64 byte aligned and if not deciding just to restore the FXSR state is daft. If user space provides an unaligned math frame and has the extended state magic set in the FX software reserved bytes, then it really can keep the pieces. If the frame is unaligned and the FX software magic is not set, then fx_only is already set and the restore will use fxrstor. Remove it. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/fpu/signal.c | 3 --- 1 file changed, 3 deletions(-) --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -306,9 +306,6 @@ static int __fpu_restore_sig(void __user } } - if ((unsigned long)buf_fx % 64) - fx_only = 1; - if (!ia32_fxstate) { /* * Attempt to restore the FPU registers directly from user