Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp622806ybg; Mon, 1 Jun 2020 10:00:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwyHTd3WZivuQ5X6lhCSojd7TlNHGpxZthZRhKfmzGiaSIcICf0AAwFuqbl1MpKwfGHCVZN X-Received: by 2002:a05:6402:17ce:: with SMTP id s14mr5909239edy.53.1591030828963; Mon, 01 Jun 2020 10:00:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591030828; cv=none; d=google.com; s=arc-20160816; b=A223/N3qwBXBGUnjgWEsAza2R/BGCYY5CJZygHAj0t3YARKFnDZ8fnBRHm8jyhGBsf 76VzMuGXp+6rKNmyZ9yQlO+wFcavDvuQSuV6QP+nVO1XDQ0B//gMEfW34BmI60CP7jnz QBmP2mZg/3DtMBg75GD4I0lKaNUc2Aj48fY7vCZzi+vtJn/pPl1vN0n7btV4gOVjbxFk JUXvmk7Yjhp02LJSNxjgRvw4Vivq+rTh9NFD4Dq6eBnOCiCZfezTvPOXRkMQDHh4oG+3 VBs95z9OxMl659JMPOLDMVg3fW342GrxS7pkWkbmmr03ALpit43BaRYCepxusgBw7Aya Y7sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ojRZHMb5z6pRXTWdgq426Xc9b24N1yJ1UAbXlosh9+w=; b=Yz1CKvdCe8UEeAIVjhAbltqCSD0zJnrJSPVFZ1dHio3CNb9Di70AubbWIMU19zLtqL rlhCzE5s+CAff8VJKO1BHghHQ/rOdlV7cN01ejObcErfDdXJZCDXbfELMXtnpOLd7Vvt ZV5lLntW9LHK7y0By420KaXI3qcGI5SmJAeaonrZR6RbQb41ZET9s8cj3zmI1eHRYa8L GQsGe29iMVFDjPWrEGXpMuPPrPzVWy49c7BDjHRVVedDzkhnx0XBeSxbJBFHPwKey7+H 8MCwzM3PjW1B6awF4GcaWSkVvPForcZgoKhhz6po+t2LabAmUQ5sgrTKJqCG0SrUYRSz ulIA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l22si57396eji.57.2020.06.01.10.00.04; Mon, 01 Jun 2020 10:00:28 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727099AbgFAQ5H (ORCPT + 99 others); Mon, 1 Jun 2020 12:57:07 -0400 Received: from brightrain.aerifal.cx ([216.12.86.13]:37840 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726073AbgFAQ5F (ORCPT ); Mon, 1 Jun 2020 12:57:05 -0400 Date: Mon, 1 Jun 2020 12:57:00 -0400 From: Rich Felker To: John Paul Adrian Glaubitz Cc: Geert Uytterhoeven , Linux-sh list , Yoshinori Sato , Michael Karcher , Linux Kernel Mailing List Subject: Re: [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user() Message-ID: <20200601165700.GU1079@brightrain.aerifal.cx> References: <20200529174540.4189874-1-glaubitz@physik.fu-berlin.de> <20200529174540.4189874-2-glaubitz@physik.fu-berlin.de> <2ad089c1-75cf-0986-c40f-c7f3f8fd6ead@physik.fu-berlin.de> <20200601030300.GT1079@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 01, 2020 at 11:13:26AM +0200, John Paul Adrian Glaubitz wrote: > Hello! > > On 6/1/20 11:02 AM, Geert Uytterhoeven wrote: > >> Can I propose a different solution? For archs where there isn't > >> actually any 64-bit load or store instruction, does it make sense to > >> be writing asm just to do two 32-bit loads/stores, especially when > >> this code is not in a hot path? > >> > >> What about just having the 64-bit versions call the corresponding > >> 32-bit version twice? (Ideally this would even be arch-generic and > >> could replace the m68k asm.) It would return EFAULT if either of the > >> 32-bit calls did. > > > > Yes, that's an option, too. > > That's the solution that Michael Karcher suggested to me as an alternative > when I talked to him off-list. > > While I understand that it works, I don't like the inconsistency and I also > don't see why we should opt for a potentially slower solution when we can > used the fastest one. > > I'm also not sure how the exception handling would properly work when you > have two invocations of __get_user_asm(). > > My current approach is consistent with the existing code, so I think it's > the natural choice. I just need someone with more experience in SH assembler > than me that the solution is correct. > > I have already pinged Niibe-san in private, he'll hopefully get back to me > within the next days. I don't have an objection to doing it the way you've proposed, but I don't think there's any performance distinction or issue with the two invocations.