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=-2.2 required=3.0 tests=FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 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 70E38C3A5A1 for ; Wed, 28 Aug 2019 14:53:08 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EFAFF22CED for ; Wed, 28 Aug 2019 14:53:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFAFF22CED Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46JTJ03KwszDq9s for ; Thu, 29 Aug 2019 00:53:04 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=suse.de (client-ip=195.135.220.15; helo=mx1.suse.de; envelope-from=msuchanek@suse.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=suse.de Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46JT273Wm1zDrC9 for ; Thu, 29 Aug 2019 00:41:03 +1000 (AEST) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D959CADFE; Wed, 28 Aug 2019 14:40:59 +0000 (UTC) Date: Wed, 28 Aug 2019 16:40:58 +0200 From: Michal =?UTF-8?B?U3VjaMOhbmVr?= To: Nicholas Piggin Subject: Re: [PATCH v2 0/4] Disable compat cruft on ppc64le v2 Message-ID: <20190828164058.76a395b8@naga> In-Reply-To: <1566988993.aiyajovdx0.astroid@bobo.none> References: <1566988993.aiyajovdx0.astroid@bobo.none> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michael Neuling , "Eric W. Biederman" , David Hildenbrand , Greg Kroah-Hartman , linux-fsdevel@vger.kernel.org, Hari Bathini , linux-kernel@vger.kernel.org, Steven Rostedt , "Dmitry V. Levin" , Max Filippov , Paul Mackerras , Joel Stanley , Andrew Donnellan , Breno Leitao , Firoz Khan , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org, Andrew Morton , Allison Randal , Alexander Viro Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, 28 Aug 2019 20:57:48 +1000 Nicholas Piggin wrote: > Michal Suchanek's on August 28, 2019 8:30 pm: > > With endian switch disabled by default the ppc64le compat supports > > ppc32le only which is something next to nobody has binaries for. > > > > Less code means less bugs so drop the compat stuff. > > Interesting patches, thanks for looking into it. I don't know much > about compat and wrong endian userspaces. I think sys_switch_endian > is enabled though, it's just a strange fast endian swap thing that > has been disabled by default. > > The first patches look pretty good. Maybe for the last one it could > become a selectable option? That sounds good. > > > > I am not particularly sure about the best way to resolve the llseek > > situation. I don't see anything in the syscal tables making it > > 32bit-only so I suppose it should be available on 64bit as well. > > It's for 32-bit userspace only. Can we just get rid of it, or is > there some old broken 64-bit BE userspace that tries to call it? That sounds like a bug in creating these unified syscall tables then. On architectures that have split tables the 64bit ones do not have llseek. On architectures with one table the syscall is marked as common. Thanks Michal