Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH/RFC] Re: 'perf test BPF' failing, libbpf regression wrt
 "basic API for BPF obj name"
To:     Arnaldo Carvalho de Melo <acme@kernel.org>,
        Martin KaFai Lau <kafai@fb.com>
References: <20171128190519.GM3298@kernel.org>
 <20171129210734.lqs23q65ac6avlwr@kafai-mbp>
 <20171129211543.GC31403@kernel.org>
 <20171129223135.6iqvj6ho4ojxmhu6@kafai-mbp>
 <20171130030110.GA18880@kernel.org> <20171130165358.GN3298@kernel.org>
 <20171130182807.sjhapvmnimtlsmpo@kafai-mbp.dhcp.thefacebook.com>
 <20171130190042.GQ3298@kernel.org>
CC:     Wang Nan <wangnan0@huawei.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        "David S. Miller" <davem@davemloft.net>,
        David Ahern <dsahern@gmail.com>,
        Ingo Molnar <mingo@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>
From:   Alexei Starovoitov <ast@fb.com>
Message-ID: <312f7691-cb7a-5c2f-18c6-ab26cfaa26a6@fb.com>
Date:   Thu, 30 Nov 2017 13:51:15 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20171130190042.GQ3298@kernel.org>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2017 21:51:38.7028 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 487ba80c-5a68-4caf-8964-08d5383c89a4
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR15MB0976
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-30_06:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 11/30/17 11:00 AM, Arnaldo Carvalho de Melo wrote:
>> Instead of sinking all future bpf_attr's backward compatibility
>> requirements to sys_bpf,  I would push it up to its own BPF_* command
>> helper which has a better sense of its bpf_attr, i.e. push it up
>> to bpf_create_map_node() and bpf_load_program_name() in this case.
> Humm, we could try that approach, but the one in this patch seemed good
> enough.
>
> And after all if the first syscall() invokation, with the latest kernel
> and latest tooling will work, right?

I agree with Martin and I also don't think it will work to push
logic of all bpf commands into single sys_bpf syscall wrapper.
This logic will become more and more complex over time.
Like this case really belongs in bpf_create_map() which is a wrapper
on top of single BPF_CREATE_MAP command.

Note it's the first time we're facing this
'new libbpf.a running on top of old kernel' issue and should be
very careful adding such fallback code to the generic bpf library,
since all the selftests/bpf/ are using this lib and relying on
excepted behavior. We don't want tests that want to test the latest
kernel feature all of a sudden pass on old kernel that doesn't have it.

To some degree perf and selftests/bpf needs are diverging here,
so adding #ifdef to libbpf.a to match testcase expectations may be
necessary.


From 1585518758041948768@xxx Thu Nov 30 19:01:57 +0000 2017
X-GM-THRID: 1585337848965420889
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread