Received: by 10.192.165.156 with SMTP id m28csp150527imm; Tue, 10 Apr 2018 18:35:15 -0700 (PDT) X-Google-Smtp-Source: AIpwx494fCPnRlnEmAabxiX/NfTtTxBes/LL84OAwo/YLUF9MueU7OIDp3HMJ8qVGPLJyr8qCTmL X-Received: by 10.99.119.15 with SMTP id s15mr1919062pgc.211.1523410515015; Tue, 10 Apr 2018 18:35:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523410514; cv=none; d=google.com; s=arc-20160816; b=vES8uSMBMconwLY3cfxuA6qSSkuYTN/uNllil9cJDGHooz/t0RvK7W/lpZ1lYsIPeu tiva8lLs0tr9HFYzursTT/LnfJLQy9dSrFDX4hLng7qp9VUBRZMmSdkfluxhA/2oCxh9 5JK5SZoECLkZ3b/DIjsH+dBEvIdB8Fb3EyxSS9TB3p+A2tySUdnc1wMwfx6ASGFgwzxp T//wr20yyQDEj2XsOYC7+B22ulXQLRAnDBys4j0zwwge/YSuim6BtiN6XWBZ+Wv8r8zl 9QAfhxLJpksYwKGv/TMD+8lgYig006unfYsA37PmYM+egCmWqqwTqlSsOg2mxkkiJ8Da sFwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:date:cc:to:from:arc-authentication-results; bh=sFj6FRXbzCv5IqT2zCND6TaWfoKiMO9hUpyl++fp2G0=; b=GCX0p5NBBaDcd0k12R+2VV/pnaJWaOe901IjqEnzxhnyinTWWzXAuWwCaUwoIdKvWp E/bXeSE4Q30LrtzReyMtkHCukbG/q9RzwXqkS/ZeKAGlWbBvLRaK8CfsDFBv+yrXIJEB iLGVMoWxLcV7XGPE/Wxn6gCAsSs9lBNp3S5ZLr3CC9iEqKNb+j0+rnIXfU0n0evZbkAX 25IXk/u8whfA9GKHrryyOULMkIraN7IqGp+hgzWWsPfjydM9LIExfha7xTcDYGdU092v rdirtbRSMkJsHS4ouidnvuh51UgnjidRTWkrvBCOnW0Azjsh9ZjTkLWryNywKkr43TI/ yNxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b18si1444pgu.116.2018.04.10.18.34.38; Tue, 10 Apr 2018 18:35:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752366AbeDKB1i (ORCPT + 99 others); Tue, 10 Apr 2018 21:27:38 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:46698 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751624AbeDKB1h (ORCPT ); Tue, 10 Apr 2018 21:27:37 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1f64Xw-0000t5-6e; Tue, 10 Apr 2018 19:27:36 -0600 Received: from [97.119.140.30] (helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1f64Xv-0007w0-7I; Tue, 10 Apr 2018 19:27:35 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: X86 ML , LKML Date: Tue, 10 Apr 2018 20:26:21 -0500 Message-ID: <87d0z6ttxe.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1f64Xv-0007w0-7I;;;mid=<87d0z6ttxe.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.119.140.30;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX185UVL1FyLwIesn2KX7xu4snBNssnS2/Uw= X-SA-Exim-Connect-IP: 97.119.140.30 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa04.xmission.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=8.0 tests=ALL_TRUSTED,BAYES_20, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_XMDrugObfuBody_08,XMGappySubj_01, XMSolicitRefs_0 autolearn=disabled version=3.4.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.5 XMGappySubj_01 Very gappy subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% * [score: 0.1910] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 0.1 XMSolicitRefs_0 Weightloss drug * 1.0 T_XMDrugObfuBody_08 obfuscated drug references X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Andy Lutomirski X-Spam-Relay-Country: X-Spam-Timing: total 175 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.6 (1.5%), b_tie_ro: 1.88 (1.1%), parse: 0.75 (0.4%), extract_message_metadata: 2.8 (1.6%), get_uri_detail_list: 1.28 (0.7%), tests_pri_-1000: 3.6 (2.0%), tests_pri_-950: 1.14 (0.7%), tests_pri_-900: 0.89 (0.5%), tests_pri_-400: 16 (9.1%), check_bayes: 15 (8.6%), b_tokenize: 5 (2.9%), b_tok_get_all: 4.9 (2.8%), b_comp_prob: 1.60 (0.9%), b_tok_touch_all: 1.82 (1.0%), b_finish: 0.58 (0.3%), tests_pri_0: 130 (74.6%), check_dkim_signature: 0.53 (0.3%), check_dkim_adsp: 3.3 (1.9%), tests_pri_500: 9 (5.1%), rewrite_mail: 0.00 (0.0%) Subject: Q: Can we get rid of __copy_siginfo_to_user32? X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy, I am looking at copy_siginfo_to_user32 and find it very unfortunate that x86 with _sigchld_x32 needs to be the odd man out. I am looking at ways to simplify the special case. The core of the special case comes from: exit_to_usermode_loop do_signal handle_signal setup_rt_frame In setup_rt_frame the code looks at ksig to see which kind of signal frame should be written for the signal. This leads to the one case in the kernel where copy_siginfo_to_user32 does not use is_ia32_syscall() or is_x32_syscall() to see which kind of signal frame it needs to create. Andy, since you have been all over the entry point code in recent years do you know if we allow tasks that can do both ia32 and x86_64 system calls? That seems to be what we the testing of ksig to see which kind of signal frame to setup is all about. If we don't allow mixed abi's on x86_64 then can I see if I have a ia32 task in setup_rt_frame by just calling is_ia32_syscall()? If we do allow mixed abi's do you know if it would be safe to temporarily play with orig_ax or current_thread_info()->status? My goal is to write two wrappers: copy_siginfo_to_user32_ia32, and copy_siginfo_to_user32_x32 around the ordinary copy_siginfo_to_user32. With only a runtime test to see which ABI we need to implement. Aka change: > case SIL_CHLD: > to->si_pid = from->si_pid; > to->si_uid = from->si_uid; > to->si_status = from->si_status; > #ifdef CONFIG_X86_X32_ABI > if (x32_ABI) { > to->_sifields._sigchld_x32._utime = from->si_utime; > to->_sifields._sigchld_x32._stime = from->si_stime; > } else > #endif > { > to->si_utime = from->si_utime; > to->si_stime = from->si_stime; > } > break; to something like: > case SIL_CHLD: > to->si_pid = from->si_pid; > to->si_uid = from->si_uid; > to->si_status = from->si_status; > #ifdef CONFIG_X86_X32_ABI > if (!is_ia32_syscall()) { > to->_sifields._sigchld_x32._utime = from->si_utime; > to->_sifields._sigchld_x32._stime = from->si_stime; > } else > #endif > { > to->si_utime = from->si_utime; > to->si_stime = from->si_stime; > } > break; I just don't understand the introdcacies of the ia32 and x32 emulation to really guess which test I need to substitute in there. So any help or ideas would really be appreciated. Eric