linux-kernel - Re: [PATCH 3/9] darray: lift from bcachefs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ef1347e4-64e3-4068-89cb-cb6038972b9e@quicinc.com>
Date: Tue, 20 Aug 2024 18:00:04 -0700
From: Jeff Johnson <quic_jjohnson@...cinc.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>, <rcu@...r.kernel.org>
CC: <paulmck@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/9] darray: lift from bcachefs

On 8/19/24 09:59, Kent Overstreet wrote:
> dynamic arrays - inspired from CCAN darrays, basically c++ stl vectors.
> 
> Used by thread_with_stdio, which is also being lifted from bcachefs for
> xfs.
> 
> Signed-off-by: Kent Overstreet <kent.overstreet@...ux.dev>
> ---
>  MAINTAINERS                             |  7 +++
>  fs/bcachefs/Makefile                    |  1 -
>  fs/bcachefs/btree_node_scan_types.h     |  2 +-
>  fs/bcachefs/btree_types.h               |  2 +-
>  fs/bcachefs/btree_update.c              |  2 +
>  fs/bcachefs/btree_write_buffer_types.h  |  2 +-
>  fs/bcachefs/disk_accounting_types.h     |  2 +-
>  fs/bcachefs/fsck.c                      |  2 +-
>  fs/bcachefs/journal_io.h                |  2 +-
>  fs/bcachefs/journal_sb.c                |  2 +-
>  fs/bcachefs/sb-downgrade.c              |  3 +-
>  fs/bcachefs/sb-errors_types.h           |  2 +-
>  fs/bcachefs/sb-members.h                |  2 +-
>  fs/bcachefs/subvolume.h                 |  1 -
>  fs/bcachefs/subvolume_types.h           |  2 +-
>  fs/bcachefs/thread_with_file_types.h    |  2 +-
>  fs/bcachefs/util.h                      | 29 +-----------
>  {fs/bcachefs => include/linux}/darray.h | 59 ++++++++++++++++---------
>  include/linux/darray_types.h            | 22 +++++++++
>  lib/Makefile                            |  2 +-
>  {fs/bcachefs => lib}/darray.c           | 12 ++++-
>  21 files changed, 96 insertions(+), 64 deletions(-)
>  rename {fs/bcachefs => include/linux}/darray.h (66%)
>  create mode 100644 include/linux/darray_types.h
>  rename {fs/bcachefs => lib}/darray.c (57%)

...

> diff --git a/fs/bcachefs/darray.c b/lib/darray.c
> similarity index 57%
> rename from fs/bcachefs/darray.c
> rename to lib/darray.c
> index b7d223f85873..b6868db7f956 100644
> --- a/fs/bcachefs/darray.c
> +++ b/lib/darray.c
> @@ -1,10 +1,14 @@
>  // SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) 2022-2024 Kent Overstreet <kent.overstreet@...ux.dev>
> + */
>  
> +#include <linux/darray.h>
>  #include <linux/log2.h>
> +#include <linux/module.h>
>  #include <linux/slab.h>
> -#include "darray.h"
>  
> -int __bch2_darray_resize(darray_char *d, size_t element_size, size_t new_size, gfp_t gfp)
> +int __darray_resize_slowpath(darray_char *d, size_t element_size, size_t new_size, gfp_t gfp)
>  {
>  	if (new_size > d->size) {
>  		new_size = roundup_pow_of_two(new_size);
> @@ -23,3 +27,7 @@ int __bch2_darray_resize(darray_char *d, size_t element_size, size_t new_size, g
>  
>  	return 0;
>  }
> +EXPORT_SYMBOL_GPL(__darray_resize_slowpath);
> +
> +MODULE_AUTHOR("Kent Overstreet");
> +MODULE_LICENSE("GPL");

Since commit 1fffe7a34c89 ("script: modpost: emit a warning when the
description is missing"), a module without a MODULE_DESCRIPTION() will
result in a warning when built with make W=1. Recently, multiple
developers, including myself, have been eradicating these warnings
treewide, and to prevent new instances from being introduced I scan lore
for patches which contain a MODULE_LICENSE but do not contain a
MODULE_DESCRIPTION(). This patch was flagged.

Normally I just ask that a MODULE_DESCRIPTION() be added. But in this
case I don't see how this can ever be built as a module since it is part
of an obj-y rule, and hence, unless I'm missing something, will always
be built-in. So in this case I would suggest removing the MODULE_AUTHOR
and MODULE_LICENSE.

However, if you do anticipate this could be built as a module in the
future, please just add the MODULE_DESCRIPTION().

/jeff