From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by sourceware.org (Postfix) with ESMTPS id 1D5C03857C44 for ; Fri, 26 Mar 2021 18:17:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1D5C03857C44 Received: by mail.kernel.org (Postfix) with ESMTPSA id D9FA9619C2 for ; Fri, 26 Mar 2021 18:17:28 +0000 (UTC) Received: by mail-ej1-f49.google.com with SMTP id ce10so9785786ejb.6 for ; Fri, 26 Mar 2021 11:17:28 -0700 (PDT) X-Gm-Message-State: AOAM530reA9MGw8U0SWtxW+VSH2kLozikKi/fePClkz1NfAxvrIa1pkY 3zyb2OiRRLdbfKKcFzrU2vOqy3a+ldfa2Vm4maNiZg== X-Google-Smtp-Source: ABdhPJxIkLPbuf3JJAmI47hYHJS2omVg8Jnqf4pc/oPneLwMb4Yz+TGSGStiqEwdtx+z94tQvlNvLsELuZucC/3MppA= X-Received: by 2002:a17:907:2809:: with SMTP id eb9mr16352179ejc.204.1616782647423; Fri, 26 Mar 2021 11:17:27 -0700 (PDT) MIME-Version: 1.0 References: <20210326100620.GA25229@zn.tnic> In-Reply-To: <20210326100620.GA25229@zn.tnic> From: Andy Lutomirski Date: Fri, 26 Mar 2021 11:17:16 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Why does glibc use AVX-512? To: Borislav Petkov Cc: Andy Lutomirski , libc-alpha , "H. J. Lu" , X86 ML , LKML , "Bae, Chang Seok" , Florian Weimer , "Carlos O'Donell" , Rich Felker Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 18:17:32 -0000 On Fri, Mar 26, 2021 at 3:08 AM Borislav Petkov wrote: > > On Thu, Mar 25, 2021 at 09:38:24PM -0700, Andy Lutomirski wrote: > > I think we should seriously consider solutions in which, for new > > tasks, XCR0 has new giant features (e.g. AMX) and possibly even > > AVX-512 cleared, and programs need to explicitly request enablement. > > I totally agree with making this depend on an explicit user request, > but... > > > This would allow programs to opt into not saving/restoring across > > signals or to save/restore in buffers supplied when the feature is > > enabled. This has all kinds of pros and cons, and I'm not sure it's a > > great idea. But, in the absence of some change to the ABI, the > > default outcome is that, on AMX-enabled kernels on AMX-enabled > > hardware, the signal frame will be more than 8kB, and this will affect > > *every* signal regardless of whether AMX is in use. > > ... what's stopping the library from issuing that new ABI call before it > starts the app and get automatically enabled > for everything by default? > > And then we'll get the lazy FPU thing all over again. At the end of the day, it's not the kernel's job to make userspace be sane or to make users or programmers make the right decisions. But it is our job to make sure that it's even possible to make the system work well, and we are responsible for making sure that old binaries continue to work, preferably well, on new kernels and new hardware.