From patchwork Sat Dec 15 01:22:57 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Bowler X-Patchwork-Id: 10731943 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E957B924 for ; Sat, 15 Dec 2018 01:22:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7F3BD2D034 for ; Sat, 15 Dec 2018 01:22:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6F77E2D03A; Sat, 15 Dec 2018 01:22:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 165F12D034 for ; Sat, 15 Dec 2018 01:22:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727668AbeLOBWU (ORCPT ); Fri, 14 Dec 2018 20:22:20 -0500 Received: from mail-it1-f196.google.com ([209.85.166.196]:37239 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726609AbeLOBWU (ORCPT ); Fri, 14 Dec 2018 20:22:20 -0500 Received: by mail-it1-f196.google.com with SMTP id b5so12326808iti.2 for ; Fri, 14 Dec 2018 17:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=draconx-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=VHINAhFB7z0Vy1n273XYP4asAbL7/TpWtTk7u8gnJQA=; b=Beb8lShFBm6x0f7VMcQo0w1IBx6NB7TF1cwYomnSRMFQrEtXgMlpKQLj4uu9BZQp/o V7J+VHf96SfUI9TOmUyKNOM5CWAyb8DmYG78tuXo+Fo/6DV7GpLycok2x048OnWROcgv VNPqKcU9Zbw7egEGHuc+PPp+P18zX6sSX1HmK5KbDLzKs3PdYMIiTvkkbSukjB/QsyMJ 7kV5s5H9MHuDEAXOTc4ydVl8tlUc9dFkUH1TqLjVY4ppALiZE8Ru0mKlOgpqiqsSiMhj tH9tyH/K7gTbh4G1Fyyxe5KRJXUq2Rseu9/MFrnUpTr3DoUfu0dtJLwWnJKsaH5AQtdE NCMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=VHINAhFB7z0Vy1n273XYP4asAbL7/TpWtTk7u8gnJQA=; b=OhMVuZB9qpJxYdAF6cIvwmYyt6L+I3h7x3ny2Opi/KuFuOngZRWF2zDs0L0fekRFnA 7+a2IzPAVjHuE99F6CKoXaPW4EkhEWmRcE2shb4kXimCOG1sA/3G0wAwLl8kdszK6J6S 3ZI8osVmadobs6K8dWsQ3xDmsn7VjcSSiAnv/bDIIagXTB1gumvxYGmTTqa74FoP/V8J Md97BUBrbEA2ah86eF3afPiAktyuWROAE9HCM8H2mWrcOuaFan3LAKVvJit9l1IynwLd RH44aRwk/P4A4dCMm6IgG7tUyW3vgC6pGKILNlt+iQzDYxlBBSKcMZXK2fOD6gCxr6tC Pg6A== X-Gm-Message-State: AA+aEWZZXAku/1/jexRnE816pmJObkqrfLm3RU0xUksh/28iMty27XxQ HiweiOlDSqn2Vn9ZqS72VVvSeCIyq+UgMWiB X-Google-Smtp-Source: AFSGD/V6CPYkbNu+mQZyQlnUVaXtRDk1zzdKbWGNQb5t1bxEeXX9usPkTIMb1HCbWOJSlW/T+hKQ5g== X-Received: by 2002:a24:7e8c:: with SMTP id h134mr4998323itc.130.1544836938648; Fri, 14 Dec 2018 17:22:18 -0800 (PST) Received: from localhost (ip-24-156-181-89.user.start.ca. [24.156.181.89]) by smtp.gmail.com with ESMTPSA id 197sm3529856itx.21.2018.12.14.17.22.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 14 Dec 2018 17:22:17 -0800 (PST) From: Nick Bowler To: linux-xfs@vger.kernel.org Cc: Brian Foster , Dave Chinner , "Darrick J. Wong" Subject: [RFC PATCH v2 1/3] xfs: Align compat attrlist_by_handle with native implementation. Date: Fri, 14 Dec 2018 20:22:57 -0500 Message-Id: <20181215012259.28358-2-nbowler@draconx.ca> X-Mailer: git-send-email 2.18.1 In-Reply-To: <20181215012259.28358-1-nbowler@draconx.ca> References: <20181215012259.28358-1-nbowler@draconx.ca> Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP While inspecting the ioctl implementations, I noticed that the compat implementation of XFS_IOC_ATTRLIST_BY_HANDLE does not do exactly the same thing as the native implementation. Specifically, the "cursor" does not appear to be written out to userspace on the compat path, like it is on the native path. This adjusts the compat implementation to copy out the cursor just like the native implementation does. The attrlist cursor does not require any special compat handling. This fixes xfstests xfs/269 on both IA-32 and x32 userspace, when running on an amd64 kernel. Signed-off-by: Nick Bowler Reviewed-by: Darrick J. Wong --- fs/xfs/xfs_ioctl32.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/xfs/xfs_ioctl32.c b/fs/xfs/xfs_ioctl32.c index fba115f4103a..4c34efcbf7e8 100644 --- a/fs/xfs/xfs_ioctl32.c +++ b/fs/xfs/xfs_ioctl32.c @@ -336,6 +336,7 @@ xfs_compat_attrlist_by_handle( { int error; attrlist_cursor_kern_t *cursor; + compat_xfs_fsop_attrlist_handlereq_t __user *p = arg; compat_xfs_fsop_attrlist_handlereq_t al_hreq; struct dentry *dentry; char *kbuf; @@ -370,6 +371,11 @@ xfs_compat_attrlist_by_handle( if (error) goto out_kfree; + if (copy_to_user(&p->pos, cursor, sizeof(attrlist_cursor_kern_t))) { + error = -EFAULT; + goto out_kfree; + } + if (copy_to_user(compat_ptr(al_hreq.buffer), kbuf, al_hreq.buflen)) error = -EFAULT; From patchwork Sat Dec 15 01:22:58 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Bowler X-Patchwork-Id: 10731947 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8C5C31399 for ; Sat, 15 Dec 2018 01:22:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 392172D02C for ; Sat, 15 Dec 2018 01:22:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2CB3A2D035; Sat, 15 Dec 2018 01:22:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B9A5F2D02C for ; Sat, 15 Dec 2018 01:22:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726609AbeLOBWW (ORCPT ); Fri, 14 Dec 2018 20:22:22 -0500 Received: from mail-io1-f68.google.com ([209.85.166.68]:45307 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726448AbeLOBWW (ORCPT ); Fri, 14 Dec 2018 20:22:22 -0500 Received: by mail-io1-f68.google.com with SMTP id n3so5882251iog.12 for ; Fri, 14 Dec 2018 17:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=draconx-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=O0jbTnsJVXq/zO/dVO60c7FrR3Hsxcm1aEUIw7I1iT4=; b=mFhenyq1JDRlYXBTHRblFYp+ropV1zg/kUXBH97b0xsWw+esHRFjLkEFVZZve6nLgx MUpaqzztETpDGGWdTiqu1anL9ZlHD5Uc2kxjHcWTJP0iaFqiptZ3SfrYLVDflc21lOLo YM4N3m6yfWaWeeTg4IfWBSrfb5TmGD5ZpRrNF7F7huNkzm/bzk5k3/15pXTvqDyYFymM bwJs0v5geRFtowr3AAfQ/ZjRym/yiJT4O7XeBqWkcPY5V0hYL/Ri55RqZrO0du3lT7x4 5ENK8Ar2t7reo+UoQClczkarAl6j2cTc9RltJWi8rxdcWx/bCDVhrc1yFdxthGqGh9op WXXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=O0jbTnsJVXq/zO/dVO60c7FrR3Hsxcm1aEUIw7I1iT4=; b=REOu8vgUJX93s3dTd/46oWwYIDzS3keFGm4Cumswnr17NFeTiDmKaQaX2PbbN/TMlv Th+IAKkbNtgE1sAnGesOopbKVASEcUh/oLkd9zXsJJkUH1TnvEC0s7bY+frUJK/19uF4 02VjQIlcAwECZikr9iFPgoZJoAhrfRk6jrnlEDNKvv0ZF6un1nPgX7O5pslumlB0ARKM 2EBbrJs1go42B3pcu8dUFxL/MmpJIu9ZoM+V9LRxrR1iLNKPn0DXlkiskyDAgjzLWU9W +xSCw/eD6zDPlxNCI2Z3mfKbQSW8hV8DICps8EZgUMsEvwHH/wZpQeNbKCDzYqnyq0/H Cwfw== X-Gm-Message-State: AA+aEWag72rnvUUprpJfY84UzWwgv5zU84W+EsKtDIe3XZ0g5GihiNQc GVASdMt53fFqziL/WhJpqk1h2+me264+pxaR X-Google-Smtp-Source: AFSGD/WwzmVgYVnuCRk99ymd1rxhXZQMV7kr1+w3rSRfAz/MrA5oXqLrb6K88VqqI4GU3T5guTPc7g== X-Received: by 2002:a5d:93d0:: with SMTP id j16mr4455053ioo.215.1544836940534; Fri, 14 Dec 2018 17:22:20 -0800 (PST) Received: from localhost (ip-24-156-181-89.user.start.ca. [24.156.181.89]) by smtp.gmail.com with ESMTPSA id i15sm2629786ioj.54.2018.12.14.17.22.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 14 Dec 2018 17:22:19 -0800 (PST) From: Nick Bowler To: linux-xfs@vger.kernel.org Cc: Brian Foster , Dave Chinner , "Darrick J. Wong" Subject: [RFC PATCH v2 2/3] xfs: Fix bulkstat compat ioctls on x32 userspace. Date: Fri, 14 Dec 2018 20:22:58 -0500 Message-Id: <20181215012259.28358-3-nbowler@draconx.ca> X-Mailer: git-send-email 2.18.1 In-Reply-To: <20181215012259.28358-1-nbowler@draconx.ca> References: <20181215012259.28358-1-nbowler@draconx.ca> Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The bulkstat family of ioctls are problematic on x32, because there is a mixup of native 32-bit and 64-bit conventions. The xfs_fsop_bulkreq struct contains pointers and 32-bit integers so that matches the native 32-bit layout, and that means the ioctl implementation goes into the regular compat path on x32. However, the 'ubuffer' member of that struct in turn refers to either struct xfs_inogrp or xfs_bstat (or an array of these). On x32, those structures match the native 64-bit layout. The compat implementation writes out the 32-bit version of these structures. This is not the expected format for x32 userspace, causing problems. Fortunately the functions which actually output these xfs_inogrp and xfs_bstat structures have an easy way to select which output format is required, so we just need a little tweak to select the right format on x32. Signed-off-by: Nick Bowler Reviewed-by: Darrick J. Wong --- fs/xfs/xfs_ioctl32.c | 34 ++++++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/fs/xfs/xfs_ioctl32.c b/fs/xfs/xfs_ioctl32.c index 4c34efcbf7e8..1cdc75dca779 100644 --- a/fs/xfs/xfs_ioctl32.c +++ b/fs/xfs/xfs_ioctl32.c @@ -241,6 +241,32 @@ xfs_compat_ioc_bulkstat( int done; int error; + /* + * Output structure handling functions. Depending on the command, + * either the xfs_bstat and xfs_inogrp structures are written out + * to userpace memory via bulkreq.ubuffer. Normally the compat + * functions and structure size are the correct ones to use ... + */ + inumbers_fmt_pf inumbers_func = xfs_inumbers_fmt_compat; + bulkstat_one_pf bs_one_func = xfs_bulkstat_one_compat; + size_t bs_one_size = sizeof(compat_xfs_bstat_t); + +#ifdef CONFIG_X86_X32 + if (in_x32_syscall()) { + /* + * ... but on x32 the input xfs_fsop_bulkreq has pointers + * which must be handled in the "compat" (32-bit) way, while + * the xfs_bstat and xfs_inogrp structures follow native 64- + * bit layout convention. So adjust accordingly, otherwise + * the data written out in compat layout will not match what + * x32 userspace expects. + */ + inumbers_func = xfs_inumbers_fmt; + bs_one_func = xfs_bulkstat_one; + bs_one_size = sizeof(xfs_bstat_t); + } +#endif + /* done = 1 if there are more stats to get and if bulkstat */ /* should be called again (unused here, but used in dmapi) */ @@ -272,15 +298,15 @@ xfs_compat_ioc_bulkstat( if (cmd == XFS_IOC_FSINUMBERS_32) { error = xfs_inumbers(mp, &inlast, &count, - bulkreq.ubuffer, xfs_inumbers_fmt_compat); + bulkreq.ubuffer, inumbers_func); } else if (cmd == XFS_IOC_FSBULKSTAT_SINGLE_32) { int res; - error = xfs_bulkstat_one_compat(mp, inlast, bulkreq.ubuffer, - sizeof(compat_xfs_bstat_t), NULL, &res); + error = bs_one_func(mp, inlast, bulkreq.ubuffer, + bs_one_size, NULL, &res); } else if (cmd == XFS_IOC_FSBULKSTAT_32) { error = xfs_bulkstat(mp, &inlast, &count, - xfs_bulkstat_one_compat, sizeof(compat_xfs_bstat_t), + bs_one_func, bs_one_size, bulkreq.ubuffer, &done); } else error = -EINVAL; From patchwork Sat Dec 15 01:22:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Bowler X-Patchwork-Id: 10731949 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5D745924 for ; Sat, 15 Dec 2018 01:22:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0A7CB2D02C for ; Sat, 15 Dec 2018 01:22:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F2F422D035; Sat, 15 Dec 2018 01:22:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 96E382D02C for ; Sat, 15 Dec 2018 01:22:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728620AbeLOBWY (ORCPT ); Fri, 14 Dec 2018 20:22:24 -0500 Received: from mail-it1-f194.google.com ([209.85.166.194]:35070 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726448AbeLOBWX (ORCPT ); Fri, 14 Dec 2018 20:22:23 -0500 Received: by mail-it1-f194.google.com with SMTP id p197so12345377itp.0 for ; Fri, 14 Dec 2018 17:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=draconx-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=tB1VVJP4XTq+ZYiN+8w06NFJBP0UDRkbcNZBjv374kQ=; b=Gw3jmdGPC4sUClJeVBSH+NvPyUFl9Fe61dozufWzXLKHwTM3oFL10YUmLVTTC3STm3 aFtcCjGD/VbTHiwoArpvwYFKjG3JPZyZLGVZn8JX8PiidDFwjo1SyesmjG9PC6wqhUUc 1mA3bPEeBEfiNUkNIX02vM572c+Y0/OiVhB/r6mGP0O69Lrn0rvdzvMGwPjfgGqhWE00 AdFSR6hIXYkCHcN7Evpcg6c4oAck53cFs9a4X6qEP7eDSdZFBeHii+JtpDtd7nT2HJwi OTkMQke1qKxOTIpG1mbKfRZluylGTkjQichJtl9UoXpU7CSoA60IU5tujWXhV1MF6+QA zxOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=tB1VVJP4XTq+ZYiN+8w06NFJBP0UDRkbcNZBjv374kQ=; b=Pr1MGRfBIPvON98X399EgG6QIN+Qxcyetp9gniQ9uXC3v38YsuoW3M/E3moKJoruec IudP3LMhVHHZVck/xxaKWoQws3+6b9odeaaLBNMn4JgiRDbVT6uVtLFiRLDHlAXG02tX poayx6Duo5UiGw2rnKJAct8kpWd//4gVdj6eoa24fZwvteLkVWEGYEB9i/NyB/TO9eJ5 MmzT9MZYtwfzseoX7O8tAwVUfzlho6bBBoLJet6pcDMUrMwAHCyAqQn379auErqPA1PU 31BbUK2A+8U2wuG9UrZiAZ8QLEzzR+CAqyzeolEjng/ipgr1eDh0LBaaKmarmIfjr3uQ 7IhA== X-Gm-Message-State: AA+aEWbgGsx3J6SqjsQFa3rjhZUVWSee8ePPjUIixqU8fas/ZM27P0qD wLts9xJwIgJUjSuMdV/n28Bvi1E98ZRj7spS X-Google-Smtp-Source: AFSGD/Xer7ucpkGYglS+4LfHm+pK6sEJFBB9fS8jTaeQTNEXkwZKetpJr/UD4NJivwJoeBtLrJ8jAw== X-Received: by 2002:a24:3752:: with SMTP id r79mr4477232itr.121.1544836942311; Fri, 14 Dec 2018 17:22:22 -0800 (PST) Received: from localhost (ip-24-156-181-89.user.start.ca. [24.156.181.89]) by smtp.gmail.com with ESMTPSA id w8sm1127993iom.26.2018.12.14.17.22.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 14 Dec 2018 17:22:21 -0800 (PST) From: Nick Bowler To: linux-xfs@vger.kernel.org Cc: Brian Foster , Dave Chinner , "Darrick J. Wong" Subject: [RFC PATCH v2 3/3] xfs: Fix x32 ioctls when cmd numbers differ from ia32. Date: Fri, 14 Dec 2018 20:22:59 -0500 Message-Id: <20181215012259.28358-4-nbowler@draconx.ca> X-Mailer: git-send-email 2.18.1 In-Reply-To: <20181215012259.28358-1-nbowler@draconx.ca> References: <20181215012259.28358-1-nbowler@draconx.ca> Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Several ioctl structs change size between native 32-bit (ia32) and x32 applications, because x32 follows the native 64-bit (amd64) integer alignment rules and uses 64-bit time_t. In these instances, the ioctl number changes so userspace simply gets -ENOTTY. This scenario can be handled by simply adding more cases. Looking at the different ioctls implemented here: - All the ones marked 'No size or alignment issue on any arch' should presumably all be fine. - All the ones under BROKEN_X86_ALIGNMENT are different under integer alignment rules. Since x32 matches amd64 here, we just need both sets of cases handled. - XFS_IOC_SWAPEXT has both integer alignment differences and time_t differences. Since x32 matches amd64 here, we need to add a case which calls the native implementation. - The remaining ioctls have neither 64-bit integers nor time_t, so x32 matches ia32 here and no change is required at this level. The bulkstat ioctl implementations have some pointer chasing which is handled separately. Signed-off-by: Nick Bowler Reviewed-by: Darrick J. Wong --- fs/xfs/xfs_ioctl32.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_ioctl32.c b/fs/xfs/xfs_ioctl32.c index 1cdc75dca779..bd9ffad0f65e 100644 --- a/fs/xfs/xfs_ioctl32.c +++ b/fs/xfs/xfs_ioctl32.c @@ -579,8 +579,12 @@ xfs_file_compat_ioctl( case FS_IOC_GETFSMAP: case XFS_IOC_SCRUB_METADATA: return xfs_file_ioctl(filp, cmd, p); -#ifndef BROKEN_X86_ALIGNMENT - /* These are handled fine if no alignment issues */ +#if !defined(BROKEN_X86_ALIGNMENT) || defined(CONFIG_X86_X32) + /* + * These are handled fine if no alignment issues. To support x32 + * which uses native 64-bit alignment we must emit these cases in + * addition to the ia-32 compat set below. + */ case XFS_IOC_ALLOCSP: case XFS_IOC_FREESP: case XFS_IOC_RESVSP: @@ -593,8 +597,16 @@ xfs_file_compat_ioctl( case XFS_IOC_FSGROWFSDATA: case XFS_IOC_FSGROWFSRT: case XFS_IOC_ZERO_RANGE: +#ifdef CONFIG_X86_X32 + /* + * x32 special: this gets a different cmd number from the ia-32 compat + * case below; the associated data will match native 64-bit alignment. + */ + case XFS_IOC_SWAPEXT: +#endif return xfs_file_ioctl(filp, cmd, p); -#else +#endif +#if defined(BROKEN_X86_ALIGNMENT) case XFS_IOC_ALLOCSP_32: case XFS_IOC_FREESP_32: case XFS_IOC_ALLOCSP64_32: