From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07B76C433E9 for ; Sat, 16 Jan 2021 00:08:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE95623A5E for ; Sat, 16 Jan 2021 00:08:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728673AbhAPAIm (ORCPT ); Fri, 15 Jan 2021 19:08:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:45132 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728584AbhAPAIl (ORCPT ); Fri, 15 Jan 2021 19:08:41 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id A708B23A9D for ; Sat, 16 Jan 2021 00:08:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610755681; bh=+2AMcX5I9sdDNTAf5qRgriFiAplt2ZW+PvqTt0Q1cUw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=uYH1XhjPX4cvFTvubDMmAXsVAN4E3GXzd6Kga4Ts0FRuFGosoKl4CjmCC4xQp4djp 1WWGmoTf9S89yyGe/XUfwreRjM+epyHkkxFcfBjNzkMGhRMDMT5OjFOUg8+dClXbwc wUoxAlOvWznbvdfqNMZNNzuFEIvbJA2fbh/QFJ9KEmvSAHGOA5gT6yTpuanqjfQXWk YcddFhEjVXQBNe6nCygAzCeJoyczQfz8GamYzUlKxyq5S8LBlpoWWCetFeRxdedPMl yq5GUlmIUwwyIJ/qv1Trcmvg2SOzKUgb8LEa+GI+YGMtMWX0fEvh1zCBR3xXm2RXt/ WkyDPSrqsETEg== Received: by mail-lf1-f48.google.com with SMTP id b26so15725578lff.9 for ; Fri, 15 Jan 2021 16:08:00 -0800 (PST) X-Gm-Message-State: AOAM530QIlLB7fx6WMIFRpYz4SrUfHSwL8PMVToXucvLD7YC6MhZI/HM NWTPAUJGWXZ/X9gy7/3cS3jJXb2CyuE0eQiHUNvAag== X-Google-Smtp-Source: ABdhPJwA0R2ivqxfLZj25fjGEkl6YCppBiN4+N4FJIG/Q6L6/jH79qY/NR2oZiGDsSgT9/JyW8mJ9D5qzsk1TFAAdjk= X-Received: by 2002:a05:6402:a5b:: with SMTP id bt27mr11884235edb.222.1610755677728; Fri, 15 Jan 2021 16:07:57 -0800 (PST) MIME-Version: 1.0 References: <20210106064807.253112-1-Sonicadvance1@gmail.com> In-Reply-To: From: Andy Lutomirski Date: Fri, 15 Jan 2021 16:07:46 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers To: Arnd Bergmann , Christoph Hellwig Cc: Ryan Houdek , Catalin Marinas , Will Deacon , Alexander Viro , Arnd Bergmann , Christian Brauner , Andrew Morton , Minchan Kim , Aleksa Sarai , Sargun Dhillon , Miklos Szeredi , Vincenzo Frascino , "Amanieu d'Antras" , Willem de Bruijn , YueHaibing , Xiaoming Ni , Heiko Carstens , "Eric W. Biederman" , Joe Perches , Jan Kara , David Rientjes , Arnaldo Carvalho de Melo , "David S. Miller" , Linux ARM , "linux-kernel@vger.kernel.org" , Linux FS-devel Mailing List , Linux API , linux-arch Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Jan 15, 2021 at 1:03 AM Arnd Bergmann wrote: > > On Fri, Jan 15, 2021 at 3:06 AM Ryan Houdek wrote: > > On Wed, Jan 6, 2021 at 12:49 AM Arnd Bergmann wrote: > >> On Wed, Jan 6, 2021 at 7:48 AM wrote: > >> > From: Ryan Houdek > >> ... > >> > >> For x86, this has another complication, as some ioctls also need to > >> check whether they are in an ia32 task (with packed u64 and 32-bit > >> __kernel_old_time_t) or an x32 task (with aligned u64 and 64-bit > >> __kernel_old_time_t). If the new syscall gets wired up on x86 as well, > >> you'd need to decide which of the two behaviors you want. > > > > > > I can have a follow-up patch that makes this do ni-syscall on x86_64 since > > we can go through the int 0x80 handler, or x32 handler path and choose > > whichever one there. > > I'd say for consistency > We need to make it crystal clear on x86 what this ioctl does. We have a silly selection of options: - ioctl32() via SYSCALL, x32 bit clear -- presumably does an i386 ioctl? - ioctl32() via SYSCALL, x32 bit set -- this needs to do something clearly documented. - ioctl32() via int80 -- presumably you're not wiring this up In any case, the compat alloc thing should just go away. It's a hack and serves no real purpose. Finally, I'm not convinced that this patch works correctly. We have in_compat_syscall(), and code that uses it may well be reachable from ioctl. I personally would like to see in_compat_syscall() go away, but some other people (Hi, Christoph!) disagree, and usage seems to be increasing, not decreasing.