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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 C3254CA9EAB for ; Sat, 19 Oct 2019 04:41:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8EF4820700 for ; Sat, 19 Oct 2019 04:41:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="T+l2Vpkn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726120AbfJSElW (ORCPT ); Sat, 19 Oct 2019 00:41:22 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:37791 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726004AbfJSElV (ORCPT ); Sat, 19 Oct 2019 00:41:21 -0400 Received: by mail-io1-f67.google.com with SMTP id b19so9890864iob.4; Fri, 18 Oct 2019 21:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-transfer-encoding; bh=p2VVU+8PljankkCSMCXqV9yM+SFP23m/H23f2IowcHc=; b=T+l2Vpkn9FUAiH16Xkxl9YFf/obtWD724fvhqZ05m4ZwdmFHOEhnZlZOLybtAPdmCT SKF6PpvONV1178FTeVeoa0C+moSh2BmwSLc5Tuw2rgnC2+cZPvsdCS/70I767A0kgr0M Tl4fi1FzYw/GwMmKMfNZHRHK2oQV6HFb9IqDSTc8ik7bhbu7hvkyL9IaCn3YM4Frpug+ kVDqSe1n3/bFbB+b67XjNJdmHh4Ic+1Opa/M7oKj9RAMcLLFLGzFlcm6lrjkfLX+fqtX 3QSXHVdsJAZ8oDfaZ08JDx7fS0bksC40ZEyYhV/CVfp3g87gVUEHT3nIywvrCqx9FV5c g6wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding; bh=p2VVU+8PljankkCSMCXqV9yM+SFP23m/H23f2IowcHc=; b=WWmR2y8T23H8uOr1NwDuZ+cIAcZNVqygCOFVjXTjVRdtsIQE4/Q3dd1XSvVhMQBgI8 BevnMRoSZWyRymxoPFhrPZk2Q0yOazLTRwVXEQ/CDo/Dw8/aG+nIy+EW5GJ8U8QBiiR6 hQgijQPgxzdQW0frwcWW4sd3FlU/4kh1AjMPxMhMoTUiw7IbkpEQt/g80cKfFYj8HCi0 vBcANCGK2qgLuSpiVVJHzsvUZw6bAOuXs6fMwgk04tVDpgT1L2naYCQFW4fjSdjGHBy1 SQXdnvd2Ez3c6H/KQaRVVb+GqihkBx56Y7k38jRdPjLRlRzphfFAdvRwTQ0N/10cNnaj 8p5Q== X-Gm-Message-State: APjAAAWFRPHcjs6a5wicP4fZdcaO/dFJHFn8HLEV/2RB7kw3WJfG6qmp KdJ22YN6TE8sZ4JK3Tz8Dcs= X-Google-Smtp-Source: APXvYqzLwhYAv+PlKOslXSIKp9Q5XxGd6tzlv/kzFqD5eR1PFumNUoSf8kaeuqGwNnzPi8/wBX8w/A== X-Received: by 2002:a02:b817:: with SMTP id o23mr12507895jam.101.1571460080843; Fri, 18 Oct 2019 21:41:20 -0700 (PDT) Received: from localhost ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id z20sm2928890iof.38.2019.10.18.21.41.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Oct 2019 21:41:20 -0700 (PDT) Date: Fri, 18 Oct 2019 21:41:12 -0700 From: John Fastabend To: Alexei Starovoitov , Andrii Nakryiko Cc: John Fastabend , "ast@kernel.org" , "daniel@iogearbox.net" , "netdev@vger.kernel.org" , "bpf@vger.kernel.org" Message-ID: <5daa93e8bfc26_3a012ad7c9bb25bca6@john-XPS-13-9370.notmuch> In-Reply-To: References: <157140968634.9073.6407090804163937103.stgit@john-XPS-13-9370> <4da33f52-e857-9997-4226-4eae0f440df9@fb.com> Subject: Re: [bpf-next PATCH] bpf: libbpf, add kernel version section parsing back Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Alexei Starovoitov wrote: > On Fri, Oct 18, 2019 at 9:52 AM Andrii Nakryiko wrote: > > > > On 10/18/19 7:41 AM, John Fastabend wrote: > > > With commit "libbpf: stop enforcing kern_version,..." we removed the > > > kernel version section parsing in favor of querying for the kernel > > > using uname() and populating the version using the result of the > > > query. After this any version sections were simply ignored. > > > > > > Unfortunately, the world of kernels is not so friendly. I've found some > > > customized kernels where uname() does not match the in kernel version. > > > To fix this so programs can load in this environment this patch adds > > > back parsing the section and if it exists uses the user specified > > > kernel version to override the uname() result. However, keep most the > > > kernel uname() discovery bits so users are not required to insert the > > > version except in these odd cases. > > > > > > Fixes: 5e61f27070292 ("libbpf: stop enforcing kern_version, populate it for users") > > > Signed-off-by: John Fastabend > > > --- > > > > In the name of not breaking users of weird kernels :) > > > > Acked-by: Andrii Nakryiko > > What does it mean that uname is cheated? > Can libbpf read it from /proc/sys/kernel/osrelease ? > or /proc/version? > Is that read only or user space can somehow overwrite it? In this case LINUX_VERSION_CODE as shown in version.h from linux-headers does not much what is being reported by /proc/version or osrelease. So its a bit surprising to me as well but I haven't got to the bottom of it. Maybe something to do with how proc is mounted in this kubernetes setup?