Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2556899ybt; Tue, 16 Jun 2020 09:00:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+BcVPrkGQ5lAZb/eybC/3+WX3S4tuJOcTkJyQ02UTvMqIgVSOkwKOBeSWvLyMTSMRMvQU X-Received: by 2002:a17:906:aec5:: with SMTP id me5mr3651601ejb.54.1592323207029; Tue, 16 Jun 2020 09:00:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592323207; cv=none; d=google.com; s=arc-20160816; b=MTRrJgTyerNkzc1vvVXc+MYeKwSLWIHrRdgWP0xZt7fhG8BhpNHy7g+xE7QQmKmIeV 3eVdOnht6c8MCfDHoMKdsIpw45WF2oNLHjAe+Khsz7LUr3tzfMRtNK4CjP3wZfHoSPBt cX/Esza2fUogW7iRJqjz9WD6Tk3ltDnbQlWIJPaiL6qzto+7Sx2aEyLAwCALk4a7Wmcr yJG563oiY8auSF4HoW29tn3FcCgCVF5sVRzLo37WTo3boPVzYxBkouLa1JEln+aWYDI2 71fo5R+g3HSfWkjU4CTj/OvMIZsFegkSsr3CIYlVrEJBvXmsUl86fPKpV2f3xSgmYj9u JKvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :dkim-signature; bh=aDlbEbbNRivF3ebZedTH8Z8/FH+h6CNXcJR+iNKCKPU=; b=XtzdCutaddI3kcRz/KwDk0ltDou7BiROzuNzlGmpZA0HsMOp2QhssUdfyntxRVaABt BA6mDPeUxqgoAkqOtZGjX3ssTET6M+8TSvFRi7PzI2WZsNvmftz+zblMOgnBw0qFkN96 cZYsHjpq44CJ+FLk7sFFeKo5fjD2DWXKkq6NwI3Sj+bmXyIJImI7YI4A+6uirm55EZGG QALV/FN27RCsw0kMVxyqfaDiY3DtJtyxRs3SMsYfs5BOmzOTvRev3wvYb6GoCUgcxgXz TpKbHV/z0/qjRsPunwTRAiKgVOl3/LpTsmerMb7xH5gaH8DgB2ENnIG0BlGtApEeKEaW uHlw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ME1Vbzrx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p5si10982073eds.404.2020.06.16.08.59.43; Tue, 16 Jun 2020 09:00:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ME1Vbzrx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732998AbgFPP6A (ORCPT + 99 others); Tue, 16 Jun 2020 11:58:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732997AbgFPPyh (ORCPT ); Tue, 16 Jun 2020 11:54:37 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05152C061573 for ; Tue, 16 Jun 2020 08:54:37 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id p5so21297384wrw.9 for ; Tue, 16 Jun 2020 08:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=aDlbEbbNRivF3ebZedTH8Z8/FH+h6CNXcJR+iNKCKPU=; b=ME1VbzrxAlBBwHB1G/OhYY0V2n82GKbwpAk+OYZAtww0bAtsbbSlf4okMRpWh7j+Bg H27gXbFGmFm00VD4/LOcE7zFeAfyMelJFT43q9zRNfHMw8VvLQtsL2qEKBhRYS0rkzf8 OObTbu0l1g0UXn03vOXV3J8AlULwUp5xOtwbM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aDlbEbbNRivF3ebZedTH8Z8/FH+h6CNXcJR+iNKCKPU=; b=bMx1RToc0G0+5QTN9AxZ0c9v02hQLF1NXaZtvUYJ0pRPPGRDqAaDrvid2GYWQnygcw 7teJ1aiPB/fllgI/fia6kGmz6cGxyobnbEBGoqocPKlt1C15ZUxrAZxAq8KzDEZ7FG/v Z44vf0Khy/0BvmyoLTvZ0JwkhT+L9791Vk8k9tEXm5xjKg98y1fxfEzxbH2SeV6+8ipM wGcmwIHhmA0dTzacyW5N0NeDhlBDnM70m+u2RH9dzmudp78MM2axFmdhW1KyATIOWavE s+w743VaPvY07ihPX8fiB3uWEer1A1Ibob8bA8S6y58wHIM5UzDImxAVyr01BMxT3hiv fXhw== X-Gm-Message-State: AOAM530ThqRNeyjM8WLCshSp6eCc5nXSLGYFwgJqo5SkbopDiBoiVMPf LZrY9Xt+wje+PgZC+EDnkDwf2g== X-Received: by 2002:a5d:6b8c:: with SMTP id n12mr3763512wrx.61.1592322875641; Tue, 16 Jun 2020 08:54:35 -0700 (PDT) Received: from google.com ([81.6.44.51]) by smtp.gmail.com with ESMTPSA id v6sm31576887wrf.61.2020.06.16.08.54.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2020 08:54:34 -0700 (PDT) From: KP Singh X-Google-Original-From: KP Singh Date: Tue, 16 Jun 2020 17:54:33 +0200 To: Andrii Nakryiko Cc: KP Singh , open list , linux-fsdevel@vger.kernel.org, bpf , linux-security-module@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , James Morris , Alexander Viro , Martin KaFai Lau , Florent Revest Subject: Re: [PATCH bpf-next 4/4] bpf: Add selftests for local_storage Message-ID: <20200616155433.GA11971@google.com> References: <20200526163336.63653-1-kpsingh@chromium.org> <20200526163336.63653-5-kpsingh@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01-Jun 13:29, Andrii Nakryiko wrote: > On Tue, May 26, 2020 at 9:34 AM KP Singh wrote: > > > > From: KP Singh > > > > inode_local_storage: > > > > * Hook to the file_open and inode_unlink LSM hooks. > > * Create and unlink a temporary file. > > * Store some information in the inode's bpf_local_storage during > > file_open. > > * Verify that this information exists when the file is unlinked. > > > > sk_local_storage: > > > > * Hook to the socket_post_create and socket_bind LSM hooks. > > * Open and bind a socket and set the sk_storage in the > > socket_post_create hook using the start_server helper. > > * Verify if the information is set in the socket_bind hook. > > > > Signed-off-by: KP Singh > > --- > > .../bpf/prog_tests/test_local_storage.c | 60 ++++++++ > > .../selftests/bpf/progs/local_storage.c | 139 ++++++++++++++++++ > > 2 files changed, 199 insertions(+) > > create mode 100644 tools/testing/selftests/bpf/prog_tests/test_local_storage.c > > create mode 100644 tools/testing/selftests/bpf/progs/local_storage.c > > > > [...] > > > +struct dummy_storage { > > + __u32 value; > > +}; > > + > > +struct { > > + __uint(type, BPF_MAP_TYPE_INODE_STORAGE); > > + __uint(map_flags, BPF_F_NO_PREALLOC); > > + __type(key, int); > > + __type(value, struct dummy_storage); > > +} inode_storage_map SEC(".maps"); > > + > > +struct { > > + __uint(type, BPF_MAP_TYPE_SK_STORAGE); > > + __uint(map_flags, BPF_F_NO_PREALLOC | BPF_F_CLONE); > > + __type(key, int); > > + __type(value, struct dummy_storage); > > +} sk_storage_map SEC(".maps"); > > + > > +/* Using vmlinux.h causes the generated BTF to be so big that the object > > + * load fails at btf__load. > > + */ > > That's first time I hear about such issue. Do you have an error log > from verifier? Here's what I get when I do the following change. --- a/tools/testing/selftests/bpf/progs/local_storage.c +++ b/tools/testing/selftests/bpf/progs/local_storage.c @@ -4,8 +4,8 @@ * Copyright 2020 Google LLC. */ +#include "vmlinux.h" #include -#include #include #include #include @@ -37,24 +37,6 @@ struct { __type(value, struct dummy_storage); } sk_storage_map SEC(".maps"); -/* Using vmlinux.h causes the generated BTF to be so big that the object - * load fails at btf__load. - */ -struct sock {} __attribute__((preserve_access_index)); -struct sockaddr {} __attribute__((preserve_access_index)); -struct socket { - struct sock *sk; -} __attribute__((preserve_access_index)); - -struct inode {} __attribute__((preserve_access_index)); -struct dentry { - struct inode *d_inode; -} __attribute__((preserve_access_index)); -struct file { - struct inode *f_inode; -} __attribute__((preserve_access_index)); ./test_progs -t test_local_storage libbpf: Error loading BTF: Invalid argument(22) libbpf: magic: 0xeb9f version: 1 flags: 0x0 hdr_len: 24 type_off: 0 type_len: 4488 str_off: 4488 str_len: 3012 btf_total_size: 7524 [1] STRUCT (anon) size=32 vlen=4 type type_id=2 bits_offset=0 map_flags type_id=6 bits_offset=64 key type_id=8 bits_offset=128 value type_id=9 bits_offset=192 [2] PTR (anon) type_id=4 [3] INT int size=4 bits_offset=0 nr_bits=32 encoding=SIGNED [4] ARRAY (anon) type_id=3 index_type_id=5 nr_elems=28 [5] INT __ARRAY_SIZE_TYPE__ size=4 bits_offset=0 nr_bits=32 encoding=(none) [6] PTR (anon) type_id=7 [7] ARRAY (anon) type_id=3 index_type_id=5 nr_elems=1 [8] PTR (anon) type_id=3 [9] PTR (anon) type_id=10 [10] STRUCT dummy_storage size=4 vlen=1 value type_id=11 bits_offset=0 [11] TYPEDEF __u32 type_id=12 [... More BTF Dump ...] [91] TYPEDEF wait_queue_head_t type_id=175 [... More BTF Dump ...] [173] FWD super_block struct [174] FWD vfsmount struct [175] FWD wait_queue_head struct [106] STRUCT socket_wq size=128 vlen=4 wait type_id=91 bits_offset=0 Invalid member libbpf: Error loading .BTF into kernel: -22. libbpf: map 'inode_storage_map': failed to create: Invalid argument(-22) libbpf: failed to load object 'local_storage' libbpf: failed to load BPF skeleton 'local_storage': -22 test_test_local_storage:FAIL:skel_load lsm skeleton failed #81 test_local_storage:FAIL The failiure is in: [106] STRUCT socket_wq size=128 vlen=4 wait type_id=91 bits_offset=0 Invalid member > > Clang is smart enough to trim down used types to only those that are > actually necessary, so too big BTF shouldn't be a thing. But let's try > to dig into this and fix whatever issue it is, before giving up :) > I was wrong about the size being an issue. The verifier thinks the BTF is invalid and more specificially it thinks that the socket_wq's member with type_id=91, i.e. typedef wait_queue_head_t is invalid. Am I missing some toolchain patches? - KP > > +struct sock {} __attribute__((preserve_access_index)); > > +struct sockaddr {} __attribute__((preserve_access_index)); > > +struct socket { > > + struct sock *sk; > > +} __attribute__((preserve_access_index)); > > + > > +struct inode {} __attribute__((preserve_access_index)); > > +struct dentry { > > + struct inode *d_inode; > > +} __attribute__((preserve_access_index)); > > +struct file { > > + struct inode *f_inode; > > +} __attribute__((preserve_access_index)); > > + > > + > > [...]