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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 C7200C388F9 for ; Fri, 30 Oct 2020 21:28:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2F734221FA for ; Fri, 30 Oct 2020 21:28:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="PnRgQyol" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F734221FA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 499BA6B0036; Fri, 30 Oct 2020 17:28:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 422196B005C; Fri, 30 Oct 2020 17:28:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 29B526B005D; Fri, 30 Oct 2020 17:28:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id E90316B0036 for ; Fri, 30 Oct 2020 17:28:45 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8AD2A2466 for ; Fri, 30 Oct 2020 21:28:45 +0000 (UTC) X-FDA: 77429881410.27.hen10_4915fb327299 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 6A08D3D669 for ; Fri, 30 Oct 2020 21:28:45 +0000 (UTC) X-HE-Tag: hen10_4915fb327299 X-Filterd-Recvd-Size: 5386 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Fri, 30 Oct 2020 21:28:44 +0000 (UTC) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7D5482222F for ; Fri, 30 Oct 2020 21:28:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604093323; bh=tZSPplLftF65YenDg5MlNkzy10RGzZxkh25MXH0GVn4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=PnRgQyolUgqkCmxzG1qYuQvzFNCGWid218+CcJ56bfcRGfXuszO7y5Pa6YL7Yze08 J/7Tsj67hoX/Y1z9arApiqu3hxdDEUtyRhSVJltPMxBHhMPJleX9zExIEGYRtwALYT WM/wRk2bR5M1DT5XgRdUsyy5cegXXECSS8xLX2YE= Received: by mail-qk1-f171.google.com with SMTP id z6so6281132qkz.4 for ; Fri, 30 Oct 2020 14:28:43 -0700 (PDT) X-Gm-Message-State: AOAM5338tyPPBbw8FRrvJARS87zICX1Os96RhQYag6Ck5o+hXkqwgz1w Oe0RCUFRn5bQFEKXW+X004FQ8nKphCm7Dm+4gIQ= X-Google-Smtp-Source: ABdhPJwzRQW1k5B6zbrTfsf30S/rHG5MM3vjwuzzwTJuv1SPViYWCLHZOGFiwlUAQWhT5QXO52QrgMTVaMhXXk5+ufM= X-Received: by 2002:a05:620a:215d:: with SMTP id m29mr4296031qkm.138.1604093322540; Fri, 30 Oct 2020 14:28:42 -0700 (PDT) MIME-Version: 1.0 References: <20201030154519.1245983-1-arnd@kernel.org> <20201030154919.1246645-1-arnd@kernel.org> <20201030154919.1246645-4-arnd@kernel.org> <20201030165338.GG1551@shell.armlinux.org.uk> In-Reply-To: <20201030165338.GG1551@shell.armlinux.org.uk> From: Arnd Bergmann Date: Fri, 30 Oct 2020 22:28:26 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/9] ARM: syscall: always store thread_info->syscall To: Russell King - ARM Linux admin Cc: Christoph Hellwig , "linux-kernel@vger.kernel.org" , Linux ARM , linux-arch , Linux-MM , Al Viro , Linus Walleij , Arnd Bergmann Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Oct 30, 2020 at 5:53 PM Russell King - ARM Linux admin wrote: > > On Fri, Oct 30, 2020 at 04:49:14PM +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > The system call number is used in a a couple of places, in particular > > ptrace, seccomp and /proc//syscall. > > > > The last one apparently never worked reliably on ARM for tasks > > that are not currently getting traced. > > > > Storing the syscall number in the normal entry path makes it work, > > as well as allowing us to see if the current system call is for > > OABI compat mode, which is the next thing I want to hook into. > > I'm not sure this patch is correct. I'm not following where you still see a mismatch, I was hoping I had fixed them all after your previous review :( The thread_info->syscall entry should now consistently contain __NR_SYSCALL_BASE on an EABI kernel, and all users of that should consistently mask it out. > Tracing the existing code for OABI: > > asmlinkage int syscall_trace_enter(struct pt_regs *regs, int scno) > { > current_thread_info()->syscall = scno; This no longer stores to current_thread_info()->syscall but instead reads the number from syscall_get_nr(). > /* Legacy ABI only. */ > USER( ldr scno, [saved_pc, #-4] ) @ get SWI instruction > bic scno, scno, #0xff000000 @ mask off SWI op-code > eor scno, scno, #__NR_SYSCALL_BASE @ check OS number > tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls? > bne __sys_trace > > __sys_trace: > mov r1, scno > add r0, sp, #S_OFF > bl syscall_trace_enter > > So, thread_info->syscall does not include __NR_SYSCALL_BASE. The > reason for this is the code that makes use of that via syscall_get_nr(). > kernel/trace/trace_syscalls.c: On both CONFIG_OABI_COMPAT and on !CONFIG_AEABI kernels, I store the value before masking out __NR_SYSCALL_BASE after my change. For EABI-only kernels there is no need for the mask. > syscall_nr = trace_get_syscall_nr(current, regs); > if (syscall_nr < 0 || syscall_nr >= NR_syscalls) > return; > > and NR_syscalls is the number of syscalls, which doesn't include the > __NR_SYSCALL_BASE offset. > > So, I think this patch actually breaks OABI. The value returned from trace_get_syscall_nr() is always in the 0...NR_syscalls range without the __NR_SYSCALL_BASE for a valid syscall. because of the added static inline int syscall_get_nr(struct task_struct *task, struct pt_regs *regs) { - return task_thread_info(task)->syscall; + return task_thread_info(task)->syscall & ~__NR_OABI_SYSCALL_BASE; } (plus the corresponding logic for OABI_COMPAT. Which of the above do you think I got wrong? Arnd