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=-23.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 31D98C5519F for ; Tue, 17 Nov 2020 18:59:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C1E2024199 for ; Tue, 17 Nov 2020 18:59:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="F3gE97FM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726958AbgKQS7D (ORCPT ); Tue, 17 Nov 2020 13:59:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726644AbgKQS7D (ORCPT ); Tue, 17 Nov 2020 13:59:03 -0500 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA276C0613CF for ; Tue, 17 Nov 2020 10:59:02 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id s30so31612205lfc.4 for ; Tue, 17 Nov 2020 10:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ODbhvfMwQphzH4jjj2dKI3GxI6ydVmCWEWjM7c37R5I=; b=F3gE97FM15B9CJ7RG37/kfNooKntH/4DE1JPl+OQeAzflt0o2dyByO+LFfp46yAfHv HDiAX38UbHVZCxAzG3z+gbrpemQ7mdvGXTc/KQZPBNDIY+h9EckM4WlJPhLe+BeRHm2O 4qpoG+ZdMxsorS1m9Z9YheQBXDqjy4lY/uMPoeFaFQQlfvU7ZHytJWgARUjTNezfXroR /Dkz50buc3rAuv97SUIAyNhA052zZ6VypKm9pmj+maDrYHqIPLe4d4QV/MKO+4mUQCX4 OaIDWwXfqS93WfXrgOB9fsWgR1LIIztTK12BzAHBQgk9PGzEBJ8BHia4it7gl97WvIdY CxTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ODbhvfMwQphzH4jjj2dKI3GxI6ydVmCWEWjM7c37R5I=; b=h/xCOOgEO7C4rXUhkOtmGppqyvxUuVZfJxlfh+MQGKm7k29Da/pi4oXz+XakgCAOGl 5lBky4c9k2Z5R/xb6S2z+zrCRmdpljvGh7JJj/nnknc9EPu/wCyQC5EAjhbGGJXm/oNG uqxlYjJq3d6KbV25xrwlaUJ5WGGQiPvNOVf9KDlBO6ZHVO/fkvTOBEv1WE8nJVzSn/a8 9aw0KESWXE2K98a7Gr/Sqr0zPEHsRf2KoMUDGBnCJ39nOTnk/Xl7pyuzresGb94+rFY+ y/Ltpmwxy55DXMVIQjhszkqsHQJY6eUNtnMjDXAHgG2oGODOgbx5Bdj5GvzJJFUy2mMp Mreg== X-Gm-Message-State: AOAM5326ZAgU1KQ0fGo0aBiZtYVIZwtSjoGCVUMdgcMp6WvUr3uG90cp HBWq9zRKYPDOmG8mOaGjgAPB9zpm2iJlpi//htaV3Q== X-Google-Smtp-Source: ABdhPJx/woAqkF74q9rSzKmewZ8VP9sPLzo+GDh6O7Yof7Ml/NiaABiCkUJdo003DJ8GO7S/+8vO+U0e49FHV75uwnc= X-Received: by 2002:ac2:4ac7:: with SMTP id m7mr2138739lfp.572.1605639540932; Tue, 17 Nov 2020 10:59:00 -0800 (PST) MIME-Version: 1.0 References: <87k0uj6h03.fsf@mid.deneb.enyo.de> <20201117183652.GD2672@gate.crashing.org> <87r1or4yct.fsf@mid.deneb.enyo.de> In-Reply-To: <87r1or4yct.fsf@mid.deneb.enyo.de> From: Peter Oskolkov Date: Tue, 17 Nov 2020 10:58:49 -0800 Message-ID: Subject: Re: Is adding an argument to an existing syscall okay? To: Florian Weimer Cc: Segher Boessenkool , Andy Lutomirski , Linux API , Mathieu Desnoyers , Peter Zijlstra , linux-toolchains@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org My assumption here was that applications that are aware of the new API will always provide three parameters, while older applications will continue calling the syscall with two. I can't think of a situation/architecture where this will break anything. Thanks, Peter On Tue, Nov 17, 2020 at 10:44 AM Florian Weimer wrote: > > * Segher Boessenkool: > > > But this isn't variadic in the sense of "..." -- on Power that always > > passes the unspecified arguments in memory, while in this case it just > > passes in either two or three registers. I don't know any arg where > > that would not work, given the Linux system call restrictions. > > > > This is similar to the "open" system call. > > Exactly. You cannot call the open function through a non-variadic > function pointer. I've seen it cause stack corruption in practice: > > commit c7774174beffe9a8d29dd4fb38bbed43ece1cecd > Author: Andreas Schneider > Date: Wed Aug 2 13:21:59 2017 +0200 > > swrap: Fix prototype of open[64] to prevent segfault on ppc64le > > The calling conventions for vaarg are different on ppc64le. The patch > fixes segfaults on that platform. > > Thanks to Florian Weimer who helped debugging it! > > Signed-off-by: Andreas Schneider > Reviewed-by: Stefan Metzmacher > > > > It is possible to implement the open function in such a way that it > does not have this problem (simply do not use the parameter save area, > using assembler if necessary), but it's another obscure step that libc > implementers would have to take.