Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5246725ybp; Mon, 14 Oct 2019 18:26:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqykVed3JUBPeh+hWNXRq4iXbyUM2LMeGSALFIFqi1MBenvB92PI07WbYKFDqDZzloZAq/fL X-Received: by 2002:a50:af22:: with SMTP id g31mr31147984edd.199.1571102782636; Mon, 14 Oct 2019 18:26:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571102782; cv=none; d=google.com; s=arc-20160816; b=i30hHo4+rPt0bK8ssK0Q1wLBWmJO1Y6tmo3OLDp/OZaEGQdwjAEgQF1OMxl8CfKGZy ZRE54mr7bfe/0zgIU0j1wbSuNUJ7o32qVypv65d7jEaFJRWqNEFlQHX0a/nhDt1Wfcdr 3Ckcqczev/O9VloI3QUAHkdo1B5c6Rw8JcmnPK8zXd18FfdedO+BmrzkLKGwDBfONdIX 9FC5lbo3oi3rRjguwSxvqCkUvzM1tgS3wFVg8lXpaMjuIPrcsO9AJSlMoP5y2NICZcpI A83ko8kPpL+g/ksb+buMI8X0/jaBgmufna0OlLaSmwtodEVzeUSJuuHXugZ3RO84uhRb +T6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :mime-version:dkim-signature; bh=iNkEDH3ViExpb/y5HnKz3o/CDE3c8oQsLUlWmGCk2mA=; b=Sa8zE4G2eLWpPi9nCfEWZr76zb+5xT74sI/nunIbdiEFa8bJZlYXbwCoVQG9Xi9A2t cu9Pc2tnB+0j+AkZyCazZged4yuhdFxxaeSyCI2zieyQlige6/d4WqXpr7mRcxwgngfR qKXQrz+7n8gMX3jiTM6IjrjLMKNfgEH8133C8AdjByvtijjKgNrjGChOvQERbH7XPhcF g4uPwzmWNawJJZZyLOKTNSwllQzT8QEzcgqdexSM+YNkdrF0IEaU+/Q2TcZ54BdNdnlK FwMkdF42H5ZeS/5VsQJ/+BrVqB5fliIxDsyMnWPbLr0nrKjO379nQCauMeARKrYhVz8i RdWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Y7lIqjnt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 4si13838639ejc.382.2019.10.14.18.25.59; Mon, 14 Oct 2019 18:26:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Y7lIqjnt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731812AbfJNWWW (ORCPT + 99 others); Mon, 14 Oct 2019 18:22:22 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:44924 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731126AbfJNWWW (ORCPT ); Mon, 14 Oct 2019 18:22:22 -0400 Received: by mail-pf1-f196.google.com with SMTP id q21so11121310pfn.11 for ; Mon, 14 Oct 2019 15:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=iNkEDH3ViExpb/y5HnKz3o/CDE3c8oQsLUlWmGCk2mA=; b=Y7lIqjntH5QlaeThyf1TiQlgL4k3YYX6zT4Rp28vGgY/nou3sE+AbBJONe/Qj9YmuU 66QHF8+NmolZkNWV5gcyXImhJrxu2FaFqgXexfaW+t9B6+j/AsTzVXb0LZOFsKU/+kH6 1m5ue/Hfh+crxXF2Wu/f+hID38C5u4poBphX0lR5tyh6kTPJwfnQEBROi53IEP7UDZVC V1i/mceVKN1jgjF8Af4KwksD3lOPBdGXg6vSB48kFS3mLEUsRitYWPA6IQHCDMBtOOez vu1OK/S8RfBJwgZAoJMQNv+hPTJtddvnWcIY/7UnrmVEEBdAeiG7UEfjyGYAePfCIkr2 auzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=iNkEDH3ViExpb/y5HnKz3o/CDE3c8oQsLUlWmGCk2mA=; b=rbPaZk/mbWKfoihTvL8jI2oL1g+hk8yGrrxuXC+KPjoApTc7x5/eBjJ+sR+N7wVzg0 ytt44yeoIsa+5mw2+llKF+c4bxsUkXGOvjUrsX3mLl39vlR+5IlLWKNem2MjPcSQCdmN UQcsGPEnI8TWW+V25yhhcAftP9nfdjB7WnPaWL64OzvqqFA+919yR9t8WjATtFFgJZol qBd8zogSbqUhaizUHjwCmTgpBWOwevBm1iWayIpPq9GH/k+MECuEbFFHINhEzuTefIoW A4CNir1XCPaMn0UpmosnXRJpxo8X9gFJjjdWYM6AputQvPZp3fwWErcloiGwkqWi9pDU lSBQ== X-Gm-Message-State: APjAAAWFNrUiRKwmC3xF2dyGJ3XZ4i+m4onAGBTll5c2/GU73xhVhimg MSdod8c3So0NPxpj9JkmolsBF3QgITTVe6fImrmCPQ== X-Received: by 2002:a63:5448:: with SMTP id e8mr7961310pgm.10.1571091740976; Mon, 14 Oct 2019 15:22:20 -0700 (PDT) MIME-Version: 1.0 From: Nick Desaulniers Date: Mon, 14 Oct 2019 15:22:09 -0700 Message-ID: Subject: AMDGPU and 16B stack alignment To: Harry Wentland , "Deucher, Alexander" Cc: yshuiv7@gmail.com, andrew.cooper3@citrix.com, Arnd Bergmann , clang-built-linux , Matthias Kaehlcke , "S, Shirish" , "Zhou, David(ChunMing)" , "Koenig, Christian" , amd-gfx list , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! The x86 kernel is compiled with an 8B stack alignment via `-mpreferred-stack-boundary=3` for GCC since 3.6-rc1 via commit d9b0cde91c60 ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if supported") or `-mstack-alignment=8` for Clang. Parts of the AMDGPU driver are compiled with 16B stack alignment. Generally, the stack alignment is part of the ABI. Linking together two different translation units with differing stack alignment is dangerous, particularly when the translation unit with the smaller stack alignment makes calls into the translation unit with the larger stack alignment. While 8B aligned stacks are sometimes also 16B aligned, they are not always. Multiple users have reported General Protection Faults (GPF) when using the AMDGPU driver compiled with Clang. Clang is placing objects in stack slots assuming the stack is 16B aligned, and selecting instructions that require 16B aligned memory operands. At runtime, syscalls handling 8B stack aligned code calls into code that assumes 16B stack alignment. When the stack is a multiple of 8B but not 16B, these instructions result in a GPF. GCC doesn't select instructions with alignment requirements, so the GPFs aren't observed, but it is still considered an ABI breakage to mix and match stack alignment. I have patches that basically remove -mpreferred-stack-boundary=4 and -mstack-alignment=16 from AMDGPU: https://github.com/ClangBuiltLinux/linux/issues/735#issuecomment-541247601 Yuxuan has tested with Clang and GCC and reported it fixes the GPF's observed. I've split the patch into 4; same commit message but different Fixes tags so that they backport to stable on finer granularity. 2 questions BEFORE I send the series: 1. Would you prefer 4 patches with unique `fixes` tags, or 1 patch? 2. Was there or is there still a good reason for the stack alignment mismatch? (Further, I think we can use -msse2 for BOTH clang+gcc after my patch, but I don't have hardware to test on. I'm happy to write/send the follow up patch, but I'd need help testing). -- Thanks, ~Nick Desaulniers