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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21967C636D3 for ; Wed, 8 Feb 2023 23:52:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35E566B0071; Wed, 8 Feb 2023 18:52:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 30E5C6B0072; Wed, 8 Feb 2023 18:52:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AE846B0074; Wed, 8 Feb 2023 18:52:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0ABB16B0071 for ; Wed, 8 Feb 2023 18:52:57 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D471E1C64B0 for ; Wed, 8 Feb 2023 23:52:56 +0000 (UTC) X-FDA: 80445777552.19.313BD45 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf04.hostedemail.com (Postfix) with ESMTP id 11E2A40003 for ; Wed, 8 Feb 2023 23:52:53 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ac19gV4J; spf=pass (imf04.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675900374; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=g7flmy3/jyFAU4sjWzJzGvCMw9yaMqfZS+04g1NY/TE=; b=pVF9CYMyTLZVOngUZ1PAMnA6efA1svUxiiYT830+Yt1yG8ZKQkE8ltjEW87bSj36OnJh9Z eX4uSlnc0YxfdhTlxUTnVJOiJBb5Bgr9fTHvCSOMUDpnPUXC3l8n+mjlcL2vplD+EmgCcw UYaN0JV3fxtbf7M1Uy7u0Kc8s0cMSL4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ac19gV4J; spf=pass (imf04.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675900374; a=rsa-sha256; cv=none; b=wv/HyplD9uniLjHsVCBnsDGKtjBxOkjcH43CyPG2EHMO0ppnG2swWW5F/O+OW/UPzShZPF nFyRaBw/qZMxQPm8iPBAqdrDInCYHhP+NpwkSag5r5fKl6LObHaWi1vDVekv7EbusZxYGU QYTNjpOQbZMJ16E5V4LSkoLfY3DPrDs= Received: by mail-ej1-f43.google.com with SMTP id sa10so1623070ejc.9 for ; Wed, 08 Feb 2023 15:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=g7flmy3/jyFAU4sjWzJzGvCMw9yaMqfZS+04g1NY/TE=; b=Ac19gV4JVm98yvL3KzN2TixhwIUbkj9aMrZn/qmddD9VfS2zkLoJN2p5iZELDdEmCm 1nhWn5VXYdY05fShRkrKDumjYjNjvW/EWJwmXqFKVTZZUz/xuhATAw5M8viT0xiLb8iE K0hT9wtXh85YS7T3g9ZbQ34lyS+LmnxNIFRxjrDpYyPTLmYDOKSjUa3hZS3/NLPW7y+Q 3YF6sQFlIr0iZZcwlaSyx7ZdbKoUyRGYQSyxwiNTvvHEHoHPil5TSuC2vNBfxKrC2BH/ JlQsc+/JynNioS/wKM/98dRwF6lVDEbC9/i9OSG9a58F/vWkKtTgLg5L2dofoIo0Kisu z4Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=g7flmy3/jyFAU4sjWzJzGvCMw9yaMqfZS+04g1NY/TE=; b=X0MVgS3xUidCTKgiZyLdB3+xULmHi2iw/KRFhgiosyuZA985Zv7exDuigAtOXPnDjt IY55Tmt5KO8mtt44KIrotYmR5XTLuknFhm9QpOXWYqfTrEfzCLZC50igtrjtLyQM048s vu6XKmDUuIaPpoUoY+/EpBiNu38vvI1LsJU95IhewUf4GP5LKHyCnoHW63nBWKo9Aw/q d8N2X1EAVI0GTwMfs65X8FcGoAaMMvAAk5EXXTJ3rTLsvAauYNjoLrmxJtgmuPhOibvt B2ZZuhIUiY1tIORF2NLNllHmBYmcoyAKgay9DhGm5Z+Tx/We1OSUozR4rJHErQofGanB Jixg== X-Gm-Message-State: AO0yUKXeLcIGJn7BWT+v+ls3bRCw0cJAbLoPF7Jpd44F2Nd4MXHjOftv lc2MunAdx6QJgd3HwT63+N0aV7j/ARi+ORaZinI= X-Google-Smtp-Source: AK7set83cYNIyE0vnJy611lFInZnOWMfKBNkj2YIsRgSBoiLIL9IVj9F3ehVTlCCPCJGIuFu+WIQNl29TZr3aodpGB0= X-Received: by 2002:a17:906:5a60:b0:8aa:bdec:d9ae with SMTP id my32-20020a1709065a6000b008aabdecd9aemr1309150ejc.12.1675900372409; Wed, 08 Feb 2023 15:52:52 -0800 (PST) MIME-Version: 1.0 References: <20230201135737.800527-1-jolsa@kernel.org> <20230201135737.800527-2-jolsa@kernel.org> In-Reply-To: <20230201135737.800527-2-jolsa@kernel.org> From: Andrii Nakryiko Date: Wed, 8 Feb 2023 15:52:40 -0800 Message-ID: Subject: Re: [PATCH RFC 1/5] mm: Store build id in file object To: Jiri Olsa Cc: Alexei Starovoitov , Andrii Nakryiko , Hao Luo , Andrew Morton , Alexander Viro , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Daniel Borkmann Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 11E2A40003 X-Stat-Signature: 4hcpgkpg7xripth7jk757s5satgh84b4 X-Rspam-User: X-HE-Tag: 1675900373-494152 X-HE-Meta: U2FsdGVkX18F1S9OINpwAewhZsmaVQq30Orm0JamOAfST6y+l5MQsoXx7T/tRyTt+oC5QO2yzvRHUN2DIywmgQNME0saU3+RNvOqsfNhCOVUtYBHZZTja/f8LTGahvpufhj4jZCA5Gm3vt5jRo2zIo3+Dp+US+4vJ8QS4dlaMjh9R89faEalR+qXOMSA9L1uujqPIkLqTtAVfLLigFcAWefvtQwQR/c4UBfGf2GV1YufoAwDW/eKetDJ3LlDkg95cCSytMrfRjkkqWTVdwm1+EUXVf74w7gFbHA5ibFdMbypBRC7mddqYoY1Tcjw65sb1W6xYiqn2B2+3avWPKzFNwYo1mMZall0jJJVIcm3CC+5WJJ7No+BUnCjtXaZcv/5FqJvuNWCgRKsQ97nSZFRPaGLt7nBKHs4pJnEg7g0KGw+5XvJ0ayvmMZAMY17DXBnRbunoJOFU4g/90o3qIq3pm5QXs3aeeb0hxblVzjvsyU+yJ7MXpt0IXwrFr5fWZ6ppMVnnvS1a8JV0h1krVdC74put/todpI9CO66OR0I29tqhDkxhGrX3wSWUtOkyt/onp2pXWm956+aC7wxa0ZEbiaqN5eCMa6JkCqNvOFVC+h3OGjAwxCzfl6/UkN6R417+CKZZMDRHAblz2tvcLrrr8Jv8svV63jdiJTQy23mDybx0oFRGyub0xbZoW1WhGxVhQr9jNBjszfUidL7J20uzFGJ/WhmAZG3Ihpp71/UIsAksOzU2cYSyN8m59mAeRZy7GiBAhnyw7kPyCa5dDvlZotQCA+SqEOcx3sDEqx626F+HoFdWc4L4OOl7hbHuxX7rMg69FutVdHmMnXPlgxhLUHv/THGFkarztY1jbDoyd0Z9+Ygctcd0QNIv10zxz2+ClEjyTqZfaBN5aoeTMQ1M6xm2ksvsj18nOuk2H8rwg939UbpBX6DKRHrYGk22oXtt2whqRNk07xYHIJqUjI Ov9BKR0a vBiu9xIViNfKQzMYIJQUyOt1QbEVHAcbOb2jIzj2S6tdyChbe6b6lSqgiXk5abu25Q03Gv9XiYFerr9tb1Oj4DQTp25k6GRUx8b9ArBl5brE0IENjDwAH00W2JYBEzv160dwmbGY+x9cIDNymVW+2rvc/tM4tccITpji6v33gSTzhsBpl5kU9PBwlVVOYubq2suysJlyO1iY9VVU/Dl7ZK8QnISjw8vVdDVpMoA0LImROMUQIpKFTSOnWmFBgaQk++MU/7m/W6jpq7mMp3bjBJw8c9lKxX8Y6zLgrPMAlcADk0xu1mBXIsikV47+/Z17S7Ix07KdQ7LoIxFD6P/G2QznCSCKPNmmoW4CLqbvQ+q0kHytwX/xMT1J5lh1zqbcp5ktpk0x/QRrpLW2niHScMnhXpPS66f2FfuX8kO8UYzsmB0vDg9qPE0XoKdveE231PTxGBMfxG+wLQrlPJ/MEVTTQTtGG1mkifVBU+lSfYcE5QnYWILZy7SIjiRvfWHt/HsTcB2S4UUaognolQdOyNOCfBQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 1, 2023 at 5:57 AM Jiri Olsa wrote: > > Storing build id in file object for elf executable with build > id defined. The build id is stored when file is mmaped. > > The build id object assignment to the file is locked with existing > file->f_mapping semaphore. > > It's hidden behind new config option CONFIG_FILE_BUILD_ID. > > Signed-off-by: Jiri Olsa > --- > fs/file_table.c | 3 +++ > include/linux/buildid.h | 17 ++++++++++++++++ > include/linux/fs.h | 3 +++ > lib/buildid.c | 44 +++++++++++++++++++++++++++++++++++++++++ > mm/Kconfig | 7 +++++++ > mm/mmap.c | 15 ++++++++++++++ > 6 files changed, 89 insertions(+) > > diff --git a/fs/file_table.c b/fs/file_table.c > index dd88701e54a9..d1c814cdb623 100644 > --- a/fs/file_table.c > +++ b/fs/file_table.c > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include > > #include > > @@ -47,6 +48,7 @@ static void file_free_rcu(struct rcu_head *head) > { > struct file *f = container_of(head, struct file, f_rcuhead); > > + file_build_id_free(f); > put_cred(f->f_cred); > kmem_cache_free(filp_cachep, f); > } > @@ -412,6 +414,7 @@ void __init files_init(void) > filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0, > SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT, NULL); > percpu_counter_init(&nr_files, 0, GFP_KERNEL); > + build_id_init(); > } > > /* > diff --git a/include/linux/buildid.h b/include/linux/buildid.h > index 3b7a0ff4642f..7c818085ad2c 100644 > --- a/include/linux/buildid.h > +++ b/include/linux/buildid.h > @@ -3,9 +3,15 @@ > #define _LINUX_BUILDID_H > > #include > +#include > > #define BUILD_ID_SIZE_MAX 20 > > +struct build_id { > + u32 sz; > + char data[BUILD_ID_SIZE_MAX]; don't know if 21 vs 24 matters for kmem_cache_create(), but we don't need 4 bytes to store build_id size, given max size is 20, so maybe use u8 for sz? > +}; > + > int build_id_parse(struct vm_area_struct *vma, unsigned char *build_id, > __u32 *size); > int build_id_parse_buf(const void *buf, unsigned char *build_id, u32 buf_size); > @@ -17,4 +23,15 @@ void init_vmlinux_build_id(void); > static inline void init_vmlinux_build_id(void) { } > #endif > > +#ifdef CONFIG_FILE_BUILD_ID > +void __init build_id_init(void); > +void build_id_free(struct build_id *bid); > +int vma_get_build_id(struct vm_area_struct *vma, struct build_id **bidp); > +void file_build_id_free(struct file *f); > +#else > +static inline void __init build_id_init(void) { } > +static inline void build_id_free(struct build_id *bid) { } > +static inline void file_build_id_free(struct file *f) { } > +#endif /* CONFIG_FILE_BUILD_ID */ > + > #endif > diff --git a/include/linux/fs.h b/include/linux/fs.h > index c1769a2c5d70..9ad5e5fbf680 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -975,6 +975,9 @@ struct file { > struct address_space *f_mapping; > errseq_t f_wb_err; > errseq_t f_sb_err; /* for syncfs */ > +#ifdef CONFIG_FILE_BUILD_ID > + struct build_id *f_bid; naming nit: anything wrong with f_buildid or f_build_id? all the related APIs use fully spelled out "build_id" > +#endif > } __randomize_layout > __attribute__((aligned(4))); /* lest something weird decides that 2 is OK */ > > diff --git a/lib/buildid.c b/lib/buildid.c > index dfc62625cae4..7f6c3ca7b257 100644 > --- a/lib/buildid.c > +++ b/lib/buildid.c > @@ -5,6 +5,7 @@ > #include > #include > #include > +#include > > #define BUILD_ID 3 > > @@ -189,3 +190,46 @@ void __init init_vmlinux_build_id(void) > build_id_parse_buf(&__start_notes, vmlinux_build_id, size); > } > #endif > + > +#ifdef CONFIG_FILE_BUILD_ID > + > +/* SLAB cache for build_id structures */ > +static struct kmem_cache *build_id_cachep; > + > +int vma_get_build_id(struct vm_area_struct *vma, struct build_id **bidp) > +{ > + struct build_id *bid; > + int err; > + > + bid = kmem_cache_alloc(build_id_cachep, GFP_KERNEL); > + if (!bid) > + return -ENOMEM; > + err = build_id_parse(vma, bid->data, &bid->sz); > + if (err) { > + build_id_free(bid); > + /* ignore parsing error */ > + return 0; > + } > + *bidp = bid; > + return 0; > +} > + > +void file_build_id_free(struct file *f) > +{ > + build_id_free(f->f_bid); > +} > + > +void build_id_free(struct build_id *bid) > +{ > + if (!bid) > + return; > + kmem_cache_free(build_id_cachep, bid); > +} > + > +void __init build_id_init(void) > +{ > + build_id_cachep = kmem_cache_create("build_id", sizeof(struct build_id), 0, > + SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT, NULL); > +} > + > +#endif /* CONFIG_FILE_BUILD_ID */ > diff --git a/mm/Kconfig b/mm/Kconfig > index ff7b209dec05..68911c3780c4 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1183,6 +1183,13 @@ config LRU_GEN_STATS > This option has a per-memcg and per-node memory overhead. > # } > > +config FILE_BUILD_ID > + bool "Store build id in file object" > + default n > + help > + Store build id in file object for elf executable with build id > + defined. The build id is stored when file is mmaped. > + > source "mm/damon/Kconfig" > > endmenu > diff --git a/mm/mmap.c b/mm/mmap.c > index 425a9349e610..a06f744206e3 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -2530,6 +2530,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > pgoff_t vm_pgoff; > int error; > MA_STATE(mas, &mm->mm_mt, addr, end - 1); > + struct build_id *bid = NULL; > > /* Check against address space limit. */ > if (!may_expand_vm(mm, vm_flags, len >> PAGE_SHIFT)) { > @@ -2626,6 +2627,13 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > if (error) > goto unmap_and_free_vma; > > +#ifdef CONFIG_FILE_BUILD_ID > + if (vma->vm_flags & VM_EXEC && !file->f_bid) { > + error = vma_get_build_id(vma, &bid); > + if (error) > + goto close_and_free_vma; do we want to fail mmap_region() if we get -ENOMEM from vma_get_build_id()? can't we just store ERR_PTR(error) in f_bid field? So we'll have f_bid == NULL for non-exec files, ERR_PTR() for when we tried and failed to get build ID, and a valid pointer if we succeeded? > + } > +#endif > /* > * Expansion is handled above, merging is handled below. > * Drivers should not alter the address of the VMA. > @@ -2699,6 +2707,12 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > if (vma->vm_flags & VM_SHARED) > mapping_allow_writable(vma->vm_file->f_mapping); > > +#ifdef CONFIG_FILE_BUILD_ID > + if (bid && !file->f_bid) > + file->f_bid = bid; > + else > + build_id_free(bid); > +#endif > flush_dcache_mmap_lock(vma->vm_file->f_mapping); > vma_interval_tree_insert(vma, &vma->vm_file->f_mapping->i_mmap); > flush_dcache_mmap_unlock(vma->vm_file->f_mapping); > @@ -2759,6 +2773,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > mapping_unmap_writable(file->f_mapping); > free_vma: > vm_area_free(vma); > + build_id_free(bid); > unacct_error: > if (charged) > vm_unacct_memory(charged); > -- > 2.39.1 >