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;