From patchwork Thu Dec 13 01:29: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: 10727477 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 431BE13AF for ; Thu, 13 Dec 2018 01:26:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 348F92B801 for ; Thu, 13 Dec 2018 01:26:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 294022B840; Thu, 13 Dec 2018 01:26:50 +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 BDD272B839 for ; Thu, 13 Dec 2018 01:26:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726527AbeLMB0t (ORCPT ); Wed, 12 Dec 2018 20:26:49 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:45342 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726337AbeLMB0t (ORCPT ); Wed, 12 Dec 2018 20:26:49 -0500 Received: by mail-io1-f66.google.com with SMTP id n3so287267iog.12 for ; Wed, 12 Dec 2018 17:26:48 -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=VBUaPKV99H+CNgs1ofFnay9apGubU5lRjdR4BEkRwOc=; b=Rtc2bR9/ml+HRBp7TyzwsHSVVwWOnObx4Xbcpa8hONOGYeCO5id2dDfIqG8rW3AiZX 9jfVsctZ8liQLZMjqoC//+GnCqmGFPAgMsCFBaia8b/ewGumzG0074Lo2hgUbNxqZBym VtdWHuaVEFGy/3sTmuqqlEHSm2j1Als8zaWaudl83Pnm1wOpxY7zr+GK0BRdpVWa0VUS xeJBdt4oNZ2IrK/GbqfaJMFu+rTQMdxSfYWxceY6ClotXjMDb6JHWAcyCtOnHgDrk5hN Jx6ipdSYDk9O7FyMENTjpgBvEzt50YLyqhfIm5hFshATBOblnfgoqQ6RZhCLUfbR9GW0 vtPg== 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=VBUaPKV99H+CNgs1ofFnay9apGubU5lRjdR4BEkRwOc=; b=Bhd5sL77rmknxp8mJLR5MBqpC9ToQhNxW2xOzcD2FucNaLwa+a8WjMYfTgKxCufzAF jdK7MMGSnLlcZXoeM/jMPtWGR+SmuaCuWO20nzgMEoAQ/Pn1VRKxLQ1oPrmr5YZcTxjK omweXCjMsgrTp+LGp4m4sTpr3LwTh977FZCyQXqgsnqVq/n/amFEWT9l1EN0bKJs9el1 VlyWNMBat/W9zVj4SSvlOYkeuyM4BGOtMSrLmEVvkJ4s4LnBkRDjc0vHNE4oc+YIfEkL t968r60kPbUPIklZnjamUfievkb8ZQ7VHVlP8BMHyP/eUlka0Jyt4FeLT/owSBLuBy6U gbtA== X-Gm-Message-State: AA+aEWbnxCPr+PiHpLXYpQ2WD2NWDLbfqC9zzSmrtCZ8BJE3JUmgJgpr xo6xUBoNd/UHzSi33Z4DCn3JJt7qkHpnuuieC6E= X-Google-Smtp-Source: AFSGD/XZ2aAq8psi6JbENyZ7gZF9g5cgV1PPzhaIAenWu84EXK0iUkb2qV49JJbJNZ48RExkBHhCLg== X-Received: by 2002:a6b:8d11:: with SMTP id p17mr19180539iod.74.1544664407820; Wed, 12 Dec 2018 17:26:47 -0800 (PST) Received: from localhost (ip-24-156-181-89.user.start.ca. [24.156.181.89]) by smtp.gmail.com with ESMTPSA id 196sm416389itu.37.2018.12.12.17.26.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Dec 2018 17:26:47 -0800 (PST) From: Nick Bowler To: linux-xfs@vger.kernel.org Cc: Brian Foster , Dave Chinner , "Darrick J. Wong" Subject: [RFC PATCH 1/2] xfs: Fix bulkstat compat ioctls on x32 userspace. Date: Wed, 12 Dec 2018 20:29:59 -0500 Message-Id: <20181213013000.15716-2-nbowler@draconx.ca> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20181213013000.15716-1-nbowler@draconx.ca> References: <20181213013000.15716-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_bulkstat struct contains pointers and 32-bit integers so that fits the native 32-bit layout fine. However, one of those pointers is subsequently used to refer to one of several structs which, on x32, all follow the native 64-bit way. Fortunately the pointer chasing seems to end there, and the functions to deal with this abstract things pretty well. We just need a little tweak to pass the right formatting function if called from x32 mode. Signed-off-by: Nick Bowler --- fs/xfs/xfs_ioctl32.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/fs/xfs/xfs_ioctl32.c b/fs/xfs/xfs_ioctl32.c index fba115f4103a..6a759c0ffb54 100644 --- a/fs/xfs/xfs_ioctl32.c +++ b/fs/xfs/xfs_ioctl32.c @@ -241,6 +241,23 @@ xfs_compat_ioc_bulkstat( int done; int error; + /* + * These functions and size are used later to handle individual + * entries; x32 is annoying and needs different functions. + */ + 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()) { + /* x32 matches native amd64 bstat and inogrp layout */ + 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 +289,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 Thu Dec 13 01:30:00 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Bowler X-Patchwork-Id: 10727479 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 0CDD913AF for ; Thu, 13 Dec 2018 01:26:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F38482B840 for ; Thu, 13 Dec 2018 01:26:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F1D4F2B853; Thu, 13 Dec 2018 01:26:51 +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 94EEB2B840 for ; Thu, 13 Dec 2018 01:26:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726531AbeLMB0v (ORCPT ); Wed, 12 Dec 2018 20:26:51 -0500 Received: from mail-it1-f193.google.com ([209.85.166.193]:36511 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726337AbeLMB0v (ORCPT ); Wed, 12 Dec 2018 20:26:51 -0500 Received: by mail-it1-f193.google.com with SMTP id c9so1429657itj.1 for ; Wed, 12 Dec 2018 17:26:50 -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=yo39Byl/3vFzlBO8ks4ZVy75fRNW4FqKxXAp8em3S3Y=; b=OUxVrkIDvS0KSIXhPrrw0t7CdtgcNjpFfecPhXVzfXrmmcIGUrzgpWozyz+DI5Nuq6 TtdjJ7CIq7erLNDcHaejuoh/i9BBa5N7XX8sP/CQ7qTOCClh025LfkGY/hyKJJ9iHaGR YFifan8hLgN5AIPdBxm5B/Xy1NZsegPrSIp+AQVuhJYP+ulgmtxFjNKceDNY2WXTrQMD OivjEd+styf5oZri/WZTZ2ryPVWjMmWQg5njuFCnowWe/gy0dbyc1dIiD5IJCmQxLb+u h6ir9phwdnqc4olk+2rsEFcbjkyb+vSqd+XQHnoP5UrtFLgdWlPIhKYR49lIRBFBStXy uJeQ== 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=yo39Byl/3vFzlBO8ks4ZVy75fRNW4FqKxXAp8em3S3Y=; b=BOaEIwGtF1L6SloWnLxddHi+N63Zdka1HAVz+PmSIaLcsUn1IaAse8ocEuHfTQfjK2 O52z4dfllH9lV7a+0zRezCmC1lW+Pd+Qp8LQ5ryBhhmrbi+krb6wvw0EbyeB8LfmJT+Z Z494GbDKVSlqDTLkXll4vpdBk0WJjfN0lWFSi5gABkp5OGFBM4sMTh6u3zie8YXl9s+n kWMG1pLeT9ykKkQAlV/SBuJ9gfIqgtt9I4FAYD6Nu855fIVG+6g7bC1cjeAcjhbrPKha GoN8sNepIswOLJebZ1N66bRilo4wEZfBLscHDiEtWcjlTOjHMTEtz0XaTKBL4XyFxCJ9 D0Cw== X-Gm-Message-State: AA+aEWbwn9CBZUdr/AweM6nAJ1KrovduMHVfYTNi5d05vwjRhlPBYZtC wtahUZEOD9U6B8faenrOg0FU3X6zz7etJfXbx+E= X-Google-Smtp-Source: AFSGD/UzWzC7c848+lh3DfJtS4DAsoO9vHCCkwA+Vxjtf+8+KjKDnw0Dsh7XYQDjG7VyQhDIjP4fxw== X-Received: by 2002:a24:4f07:: with SMTP id c7mr8111758itb.107.1544664409522; Wed, 12 Dec 2018 17:26:49 -0800 (PST) Received: from localhost (ip-24-156-181-89.user.start.ca. [24.156.181.89]) by smtp.gmail.com with ESMTPSA id e22sm197894iod.47.2018.12.12.17.26.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Dec 2018 17:26:48 -0800 (PST) From: Nick Bowler To: linux-xfs@vger.kernel.org Cc: Brian Foster , Dave Chinner , "Darrick J. Wong" Subject: [RFC PATCH 2/2] xfs: Fix x32 ioctls when cmd numbers differ from ia32. Date: Wed, 12 Dec 2018 20:30:00 -0500 Message-Id: <20181213013000.15716-3-nbowler@draconx.ca> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20181213013000.15716-1-nbowler@draconx.ca> References: <20181213013000.15716-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 --- 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 6a759c0ffb54..c5b48e1f46fe 100644 --- a/fs/xfs/xfs_ioctl32.c +++ b/fs/xfs/xfs_ioctl32.c @@ -564,8 +564,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: @@ -578,8 +582,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: