Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1014505ybz; Fri, 17 Apr 2020 14:13:17 -0700 (PDT) X-Google-Smtp-Source: APiQypLKPLz9E+sO0W9VLx7Wh9D0Gz274Sj+rOeCafCDnfe+iAWTKT2bSQeIGxZU8NI40bBDKBga X-Received: by 2002:a17:906:81d7:: with SMTP id e23mr4558189ejx.309.1587157997753; Fri, 17 Apr 2020 14:13:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587157997; cv=none; d=google.com; s=arc-20160816; b=XH9Vufva2a8MthdCkO8W7r+dhuHIrk5buv4vBVY11mcNovBB1vRpUxfQ2bsDoPyoK5 SFvOfU2vYju8eMX655kxQxXarFvw15A30zsyFtc41mbkwrLaRZycXQ4IvyrQ/0WDhi1v ZZBTMddDtE+8byaH8FuYpxvtmGB0wnEmh01vXgyPgETix4hNPiZInCo5i0sXi9ydKQRC qWa+Iu71hpHm3uyqBfrgVHJ4fd7asrZytrfNu3buLAzgd2qc/NcauzxWKMqH63nlDpec ercSD/zJk8Gdf+1A6mtoeZ3gwZ0r9z5/fFcy/HwAz0cNOBWOxOfvMTyUsJguBOZvlUoq 6MbQ== 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:in-reply-to:date:references:cc:to:from; bh=Z+Q1mDOz41kc0JDYKliwKmYEUjqRjyQTnEatVPF7aMo=; b=fcwaUmXp5YlBdiRjrwIWyBSpnKLvJbJzjyWHg9NMitqhk/6TFU3bPkq01QfHwfdhaY V6ai38iECcUXXD/btkwe8GQzL8JIakZYuP1H/OqjSAQMILTtA4OwGxRhRgJ9Y6NB4oGS BsSnSY7IvAaB7Ncq9CvNq0kaHtzeuHnipN4jfqUcdiv25ddb4KkhTbtwiNvmD6jZOYqo 1RyLlxqxz+7RMtJB9YXwFzRgXaG3lss2BaHI4APL2stcKiuHyvtIkT09ABp7DI5krJUW E6ECijgZ8RaGvUN1ktyLwQmJlVlJFcL4yL3gQgmETlCIic5MW09g9Fl/mGOzNF9CAr43 oOAQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s14si421462edw.490.2020.04.17.14.12.54; Fri, 17 Apr 2020 14:13:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727897AbgDQVL3 (ORCPT + 99 others); Fri, 17 Apr 2020 17:11:29 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:46498 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726129AbgDQVL3 (ORCPT ); Fri, 17 Apr 2020 17:11:29 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jPYGk-0005yL-PC; Fri, 17 Apr 2020 15:11:26 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jPYGi-0003AY-UF; Fri, 17 Apr 2020 15:11:26 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Christoph Hellwig Cc: Andrew Morton , Alexander Viro , Jeremy Kerr , Arnd Bergmann , linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org References: <20200414070142.288696-1-hch@lst.de> <20200414070142.288696-3-hch@lst.de> Date: Fri, 17 Apr 2020 16:08:23 -0500 In-Reply-To: <20200414070142.288696-3-hch@lst.de> (Christoph Hellwig's message of "Tue, 14 Apr 2020 09:01:36 +0200") Message-ID: <87pnc5akhk.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1jPYGi-0003AY-UF;;;mid=<87pnc5akhk.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/sMSqzlC3UCo8sLeQoBbXwuy1pdf5wSzo= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa08.xmission.com X-Spam-Level: * X-Spam-Status: No, score=1.8 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01, XMGappySubj_01,XMNoVowels autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4911] * 0.5 XMGappySubj_01 Very gappy subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa08 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa08 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Christoph Hellwig X-Spam-Relay-Country: X-Spam-Timing: total 1372 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 14 (1.0%), b_tie_ro: 12 (0.9%), parse: 1.10 (0.1%), extract_message_metadata: 13 (0.9%), get_uri_detail_list: 1.38 (0.1%), tests_pri_-1000: 4.7 (0.3%), tests_pri_-950: 1.53 (0.1%), tests_pri_-900: 1.16 (0.1%), tests_pri_-90: 62 (4.5%), check_bayes: 60 (4.4%), b_tokenize: 4.7 (0.3%), b_tok_get_all: 7 (0.5%), b_comp_prob: 1.68 (0.1%), b_tok_touch_all: 42 (3.0%), b_finish: 1.22 (0.1%), tests_pri_0: 138 (10.1%), check_dkim_signature: 0.48 (0.0%), check_dkim_adsp: 2.3 (0.2%), poll_dns_idle: 1114 (81.2%), tests_pri_10: 2.0 (0.1%), tests_pri_500: 1132 (82.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 2/8] signal: clean up __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 in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Hellwig writes: > Instead of an architecture specific calling convention in common code > just pass a flags argument with architecture specific values. This bothers me because it makes all architectures pay for the sins of x32. Further it starts burying the details of the what is happening in architecture specific helpers. Hiding the fact that there is only one niche architecture that does anything weird. I am very sensitive to hiding away signal handling details right now because way to much of the signal handling code got hidden in architecture specific files and was quite buggy because as a result. My general sense is putting all of the weird details up front and center in kernel/signal.c is the only way for this code will be looked at and successfully maintained. How about these patches to solve set_fs with binfmt_elf instead: Eric W. Biederman (2): signal: Factor copy_siginfo_to_external32 from copy_siginfo_to_user32 signal: Remove the set_fs in binfmt_elf.c:fill_siginfo_note fs/binfmt_elf.c | 5 +---- fs/compat_binfmt_elf.c | 2 +- include/linux/compat.h | 1 + include/linux/signal.h | 7 +++++++ kernel/signal.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------- Eric