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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 80EC2C6778C for ; Tue, 3 Jul 2018 09:17:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 469B72443A for ; Tue, 3 Jul 2018 09:17:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 469B72443A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=de.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754709AbeGCJRc (ORCPT ); Tue, 3 Jul 2018 05:17:32 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:34892 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754606AbeGCJR3 (ORCPT ); Tue, 3 Jul 2018 05:17:29 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w639EBgQ113897 for ; Tue, 3 Jul 2018 05:17:29 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0a-001b2d01.pphosted.com with ESMTP id 2k02ec9mfe-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 03 Jul 2018 05:17:28 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 3 Jul 2018 10:17:26 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp04.uk.ibm.com (192.168.101.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 3 Jul 2018 10:17:21 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w639HKxB27852902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 3 Jul 2018 09:17:20 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A2321A404D; Tue, 3 Jul 2018 12:17:45 +0100 (BST) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EEA83A4040; Tue, 3 Jul 2018 12:17:44 +0100 (BST) Received: from osiris (unknown [9.152.212.90]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Tue, 3 Jul 2018 12:17:44 +0100 (BST) Date: Tue, 3 Jul 2018 11:17:17 +0200 From: Heiko Carstens To: Peter Zijlstra , Mathieu Desnoyers , Linus Torvalds , Andy Lutomirski , Thomas Gleixner , linux-kernel , linux-api , "Paul E. McKenney" , Boqun Feng , Dave Watson , Paul Turner , Andrew Morton , Russell King , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Chris Lameter , Ben Maurer , rostedt , Josh Triplett , Catalin Marinas , Will Deacon , Michael Kerrisk , Joel Fernandes , michal.simek@xilinx.com, Martin Schwidefsky , Vasily Gorbik Subject: Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs References: <1959930320.10843.1530573742647.JavaMail.zimbra@efficios.com> <8B2E4CEB-3080-4602-8B62-774E400892EB@amacapital.net> <459661281.10865.1530580742205.JavaMail.zimbra@efficios.com> <858886246.10882.1530583291379.JavaMail.zimbra@efficios.com> <1776351430.10902.1530585009519.JavaMail.zimbra@efficios.com> <20180703081449.GT2494@hirez.programming.kicks-ass.net> <20180703082955.GH3704@osiris> <20180703084312.GU2494@hirez.programming.kicks-ass.net> <20180703085546.GJ3704@osiris> MIME-Version: 1.0 In-Reply-To: <20180703085546.GJ3704@osiris> X-TM-AS-GCONF: 00 x-cbid: 18070309-0016-0000-0000-000001E2D1FA X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18070309-0017-0000-0000-000032372EB2 Message-Id: <20180703091717.GK3704@osiris> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-03_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=425 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030105 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 03, 2018 at 10:55:46AM +0200, Heiko Carstens wrote: > > > > We're piece-wise enabling rseq across architectures anyway, and when the > > > > relevant maintains do this, they can have a look at their > > > > {get,put}_user() implementations and fix them. > > > > > > > > If you rely on get_user(u64) working, that means microblaze is already > > > > broken, but I suppose it already was, since their rseq enablement patch > > > > is extremely dodgy. Michal? > > > > > > s390 uses the mvcos instruction to implement get_user(). That instruction > > > is not defined to be atomic, but may copy bytes piecemeal.. I had the > > > impression that the rseq fields are supposed to be updated within the > > > context of a single thread (user + kernel space). > > > > > > However if another user space thread is allowed to do this as well, then > > > the get_user() approach won't fly on s390. > > > > > > That leaves the question: does it even make sense for a thread to update > > > the rseq structure of a different thread? > > > > The problem is interrupts; we need interrupts on the CPU doing the store > > to observe either the old or the new value, not a mix. > > > > If mvcos does not guarantee that, we're having problems. Is there a > > reason get_user() cannot use a 'regular' load? > > Well, that's single instruction semantics. This is something we actually > can guarantee, since the mvcos instruction itself won't be interrupted and > copies all 1/2/4/8 bytes in a row. > > So we are talking about that single instructions are required and not > atomic accesses? And to answer also your question: we don't use a regular load, since we would have to use 'sacf' construct surrounding the load instruction which would be much slower. We have something like that implemented for the futex atomic ops, and we could also implement something like that for this use case (e.g. get_user_atomic()), if really needed.