From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id BB77B385781F for ; Thu, 18 Mar 2021 17:29:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BB77B385781F Received: by mail-ot1-x335.google.com with SMTP id v24-20020a9d69d80000b02901b9aec33371so5933023oto.2 for ; Thu, 18 Mar 2021 10:29:59 -0700 (PDT) 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=sKFot1vt5h+G0eJtyNuSHsJs2VZeNWHUEMdwYCvmMpU=; b=GVvEx7ZMYuhAn/or+Q6bib+mbkvmjGZPhcgAsMr2W3N/UJROySUw+DzqhnqZrVG4Gt M7aBuK7E3FqQ/zW6BjGiMKXBUMKvUeLXXAXfjzSFl+zNIxIdH9Q67GI/YSiWF74Fh6RT 9AOWhq+qfevf2CeqqEYvjU3OscrEnXcWv9OaFaH4wYcE1aBPGu8Yz4w7R0NZE3zeEF2U cbYjllZ69a7p4TzIFJHdMLgKnLWD0a8A1IBGfskKAW9BnIM06JMJK2HCauytZFNeO9FM IZJZW1i3xty8dv6wn8JjVzq5V8vnuWkPzNXO3YZ22oaSyNtR6yltuB1VG5+z7MF0MYaZ 9mdQ== X-Gm-Message-State: AOAM533byW7tXg/UdrlDXayl/0cdkUEZbz4wgPNiwKPhay27nMdFxMpo QiGqIR98ZWTqVSbIpA2ZGpEcOLqlk8E3/KrLasU= X-Google-Smtp-Source: ABdhPJzO3AB2G6chTHXXu5nIA8WY89hKKTHb3fSCc22VBNScG6UU0feCZRzlaqySeaqFQgErxp/MlnJPrFkQQHVwCEs= X-Received: by 2002:a05:6830:1515:: with SMTP id k21mr8106416otp.269.1616088599156; Thu, 18 Mar 2021 10:29:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Thu, 18 Mar 2021 10:29:22 -0700 Message-ID: Subject: Re: tunables vs osxsave vs checkpointing vs _dl_runtime_resolve To: DJ Delorie Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3029.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:30:01 -0000 On Thu, Mar 18, 2021 at 10:18 AM DJ Delorie via Libc-alpha wrote: > > > In response to this customer bug... > > https://bugzilla.redhat.com/show_bug.cgi?id=1937515 > > I spent some time digging into this code, and was able to reproduce it > using criu (checkpoint/restore in userspace). In a nutshell: if you > create a task on a machine WITH xsave (or xsavec), and migrate it > (somehow) to a machine WITHOUT xsave (or xsavec), any further DSO > calls will fail because we've already chosen an xsave/xsavec resolver. > > This, of course, is guaranteed to fail, and cannot be fixed. With > criu I had to override the checks with a command line option just to > prove my point. > > However, if you *know* you might do this, there should be a way to use > tunables to avoid xsave/xsavec - with the usual caveats about "YMMV" - > so that a process could be migrated across such CPUs without fault. > > Our tunables almost provide this. > > IMHO the tunables logic should interact with cpu features like this: > > 1. Read the CPU features available > 2. Apply tunables > 3. Make secondary decisions based on the results > > The code that handles xsave breaks these rules; the save size for > extended registers is computed before tunables are applied, so > disabling xsave, xsavec, or osxsave in tunables has no affect. > *After* tunables, we use the save size to determine if xsave/xsavec > are enabled! > > It looks like just moving the save_size logic in update_usable() > (cpu_features.c) to after the tunables check in init_cpu_features() > should "solve" this problem, allowing tunables to determine if > xsave/xsavec are used in dl_runtime_resolve. However, the code is > complex and hairy and there's a good chance for gotchas in there. > > Comments? > Please open a glibc bug and CC me. -- H.J.