[PATCH v2] bpf: use flexible array members, not zero-length
This switches zero-length arrays in variable-length structs to C99
flexible array members. GCC will then ensure that the arrays are
always the last element in the struct.
Coccinelle:
@@
identifier S, fld;
type T;
@@
struct S {
...
T fld[
- 0
];
...
};
Signed-off-by: Stephen Kitt
---
Documentation/bpf/btf.rst | 2 +-
tools/lib/bpf/libbpf.c | 2 +-
tools/lib/bpf/libbpf_internal.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
index 4d565d202ce3..24ce50fc1fc1 100644
--- a/Documentation/bpf/btf.rst
+++ b/Documentation/bpf/btf.rst
@@ -670,7 +670,7 @@ func_info for each specific ELF section.::
__u32 sec_name_off; /* offset to section name */
__u32 num_info;
/* Followed by num_info * record_size number of bytes */
-__u8data[0];
+__u8data[];
};
Here, num_info must be greater than 0.
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index e0276520171b..c02ea0e1a588 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -5577,7 +5577,7 @@ static struct perf_buffer *__perf_buffer__new(int map_fd,
size_t page_cnt,
struct perf_sample_raw {
struct perf_event_header header;
uint32_t size;
- char data[0];
+ char data[];
};
struct perf_sample_lost {
diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h
index 2e83a34f8c79..930ada2276bf 100644
--- a/tools/lib/bpf/libbpf_internal.h
+++ b/tools/lib/bpf/libbpf_internal.h
@@ -86,7 +86,7 @@ struct btf_ext_info_sec {
__u32 sec_name_off;
__u32 num_info;
/* Followed by num_info * record_size number of bytes */
- __u8data[0];
+ __u8data[];
};
/* The minimum bpf_func_info checked by the loader */
--
2.20.1
Re: [PATCH] bpf: use flexible array members, not zero-length
On Sat, Sep 28, 2019 at 04:48:14PM +0200, Stephen Kitt wrote:
> This switches zero-length arrays in variable-length structs to C99
> flexible array members. GCC will then ensure that the arrays are
> always the last element in the struct.
>
> Coccinelle:
> @@
> identifier S, fld;
> type T;
> @@
>
> struct S {
> ...
> - T fld[0];
> + T fld[];
> ...
> };
You did not explain the "why is it needed" part, only what your
change is doing. What [compilation?] issue are you seeing that
you're trying to fix? This sort of information must be present
in a changelog.
> Signed-off-by: Stephen Kitt
Thanks,
Daniel
Re: [PATCH] bpf: use flexible array members, not zero-length
Le 30/09/2019 08:07, Song Liu a écrit : On Sep 28, 2019, at 10:49 PM, Gustavo A. R. Silva wrote: I think you should preserve the tab here. Agreed. Indeed (and I thought I’d checked whitespace changes!). V2 upcoming with an improved Coccinelle script which preserves whitespace and fixes a couple of other issues which appear in other files (attributes, and structs defined alongside the field declaration). Besides this: Acked-by: Song Liu Thanks! Regards, Stephen
Re: [PATCH] docs: arm64: Fix indentation and doc formatting
On Sat, Sep 28, 2019 at 10:58:19PM +1000, Adam Zerella wrote: > Sphinx generates the following warnings for the arm64 doc > pages: > > Documentation/arm64/memory.rst:158: WARNING: Unexpected indentation. > Documentation/arm64/memory.rst:162: WARNING: Unexpected indentation. > > These indentations warnings can be resolved by utilising code > hightlighting instead. > > Signed-off-by: Adam Zerella > --- > Documentation/arm64/memory.rst | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst > index b040909e45f8..f7db6a3898c5 100644 > --- a/Documentation/arm64/memory.rst > +++ b/Documentation/arm64/memory.rst > @@ -154,11 +154,16 @@ return virtual addresses to userspace from a 48-bit > range. > > Software can "opt-in" to receiving VAs from a 52-bit space by > specifying an mmap hint parameter that is larger than 48-bit. > -For example: > -maybe_high_address = mmap(~0UL, size, prot, flags,...); > + > +.. code-block:: c > + > + maybe_high_address = mmap(~0UL, size, prot, flags,...); Why did you drop the "For example:" prefix? Will
Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info
On Fri, Jul 12, 2019 at 09:04:23AM -0700, h...@zytor.com wrote: > On July 4, 2019 9:36:10 AM PDT, Daniel Kiper wrote: > >The relationships between the headers are analogous to the various data > >sections: > > > > setup_header = .data > > boot_params/setup_data = .bss > > > >What is missing from the above list? That's right: > > > > kernel_info = .rodata > > > >We have been (ab)using .data for things that could go into .rodata or > >.bss for > >a long time, for lack of alternatives and -- especially early on -- > >inertia. > >Also, the BIOS stub is responsible for creating boot_params, so it > >isn't > >available to a BIOS-based loader (setup_data is, though). > > > >setup_header is permanently limited to 144 bytes due to the reach of > >the > >2-byte jump field, which doubles as a length field for the structure, > >combined > >with the size of the "hole" in struct boot_params that a protected-mode > >loader > >or the BIOS stub has to copy it into. It is currently 119 bytes long, > >which > >leaves us with 25 very precious bytes. This isn't something that can be > >fixed > >without revising the boot protocol entirely, breaking backwards > >compatibility. > > > >boot_params proper is limited to 4096 bytes, but can be arbitrarily > >extended > >by adding setup_data entries. It cannot be used to communicate > >properties of > >the kernel image, because it is .bss and has no image-provided content. > > > >kernel_info solves this by providing an extensible place for > >information about > >the kernel image. It is readonly, because the kernel cannot rely on a > >bootloader copying its contents anywhere, but that is OK; if it becomes > >necessary it can still contain data items that an enabled bootloader > >would be > >expected to copy into a setup_data chunk. > > > >This patch does not bump setup_header version in arch/x86/boot/header.S > >because it will be followed by additional changes coming into the > >Linux/x86 boot protocol. > > > >Suggested-by: H. Peter Anvin > >Signed-off-by: Daniel Kiper > >Reviewed-by: Eric Snowberg > >Reviewed-by: Ross Philipson > >--- > >v2 - suggestions/fixes: > > - rename setup_header2 to kernel_info, > > (suggested by H. Peter Anvin), > > - change kernel_info.header value to "InfO" (0x4f666e49), > > - new kernel_info description in Documentation/x86/boot.rst, > > (suggested by H. Peter Anvin), > > - drop kernel_info_offset_update() as an overkill and > > update kernel_info offset directly from main(), > > (suggested by Eric Snowberg), > > - new commit message > > (suggested by H. Peter Anvin), > > - fix some commit message misspellings > > (suggested by Eric Snowberg). > >--- > >Documentation/x86/boot.rst | 89 > >++ > > arch/x86/boot/Makefile | 2 +- > > arch/x86/boot/compressed/Makefile | 4 +- > > arch/x86/boot/compressed/kernel_info.S | 12 + > > arch/x86/boot/header.S | 1 + > > arch/x86/boot/tools/build.c| 5 ++ > > arch/x86/include/uapi/asm/bootparam.h | 1 + > > 7 files changed, 111 insertions(+), 3 deletions(-) > > create mode 100644 arch/x86/boot/compressed/kernel_info.S > > > >diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst > >index 08a2f100c0e6..a934a56f0516 100644 > >--- a/Documentation/x86/boot.rst > >+++ b/Documentation/x86/boot.rst > >@@ -68,8 +68,25 @@ Protocol 2.12 (Kernel 3.8) Added the xloadflags > >field and extension fields > > Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in > > xloadflags to support booting a 64-bit kernel from 32-bit > > EFI > >+ > >+Protocol 2.14: BURNT BY INCORRECT COMMIT > >ae7e1238e68f2a472a125673ab506d49158c1889 > >+(x86/boot: Add ACPI RSDP address to setup_header) > >+DO NOT USE!!! ASSUME SAME AS 2.13. > >+ > >+Protocol 2.15: (Kernel 5.3) Added the kernel_info. > >= > > > > > >+.. note:: > >+ The protocol version number should be changed only if the setup > >header > >+ is changed. There is no need to update the version number if > >boot_params > >+ or kernel_info are changed. Additionally, it is recommended to > >use > >+ xloadflags (in this case the protocol version number should not > >be > >+ updated either) or kernel_info to communicate supported Linux > >kernel > >+ features to the boot loader. Due to very limited space available > >in > >+ the original setup header every update to it should be considered > >+ with great care. Starting from the protocol 2.15 the primary way > >to > >+ communicate things to the boot loader is the kernel_info. > >+ > > > > Memory Layout > > = > >@@ -207,6 +224,7 @@ Offset/Size Proto Name > >Meaning > > 0258/8 2.10+ pref_addressPreferred > > loading addres
Re: [GIT PULL] remove dead mutt url and add active mutt url
On 08:28 Mon 30 Sep 2019, Randy Dunlap wrote: On 9/30/19 8:26 AM, Bhaskar Chowdhury wrote: On 08:13 Mon 30 Sep 2019, Jonathan Corbet wrote: On Sat, 28 Sep 2019 20:43:03 +0530 Bhaskar Chowdhury wrote: The following changes since commit 4e4327891fe2a2a4db342985bff4d4c48703c707: replace dead mutt url with active one. (2019-09-28 20:11:00 +0530) are available in the Git repository at: Bhaskar, I'm not going to take a pull request for a change like this. If you would like to make this change (and it seems like a useful change to make), please send me a patch that is: - based on docs-next I have no clue where do I found out "docs-next" Jon. But I have stumbled over these places.. https://github.com/torvalds/linux/commit/81a84ad3cb5711cec79f4dd53a4ce026b092c432 and this: https://git.kernel.org/pub/scm/linux/kernel/git/rdunlap/linux-docs.git/ Now, do you want me to make changes there and sent a patch?? I am absolutely not sure . Kindly shed some light. - properly changelogged - demonstrated to build properly with sphinx Thanks, jon Thanks, Bhaskar Hi, The kernel MAINTAINERS file says: DOCUMENTATION M: Jonathan Corbet L: linux-doc@vger.kernel.org S: Maintained F: Documentation/ F: scripts/documentation-file-ref-check F: scripts/kernel-doc F: scripts/sphinx-pre-install X: Documentation/ABI/ X: Documentation/firmware-guide/acpi/ X: Documentation/devicetree/ X: Documentation/i2c/ X: Documentation/media/ X: Documentation/power/ X: Documentation/spi/ T: git git://git.lwn.net/linux.git docs-next that ^ -- ~Randy Thanks, a bunch Randy...my bad...was lazy and pathetic to not look into that file. ~Bhaskar signature.asc Description: PGP signature
Why no section for "Kernel/Linux Documentation" here : https://patchwork.kernel.org/
Hi Randy/Jon, Why that page missing a section "Kernel Documentation" ?? OR am I missing the title therenot sure...there must be some reason. Thanks, Bhaskar signature.asc Description: PGP signature
Re: [PATCH v2] bpf: use flexible array members, not zero-length
On 9/30/19 02:38, Stephen Kitt wrote:
> This switches zero-length arrays in variable-length structs to C99
> flexible array members. GCC will then ensure that the arrays are
> always the last element in the struct.
>
> Coccinelle:
> @@
> identifier S, fld;
> type T;
> @@
>
> struct S {
> ...
> T fld[
> - 0
> ];
> ...
> };
>
> Signed-off-by: Stephen Kitt
> ---
What changed in v2?
You should include a changelog here.
I encourage you to read the following document:
https://kernelnewbies.org/Outreachyfirstpatch
In particular this section "Versioning one patch revision"
Also, always CC the lkml: linux-ker...@vger.kernel.org
Thanks
--
Gustavo
> Documentation/bpf/btf.rst | 2 +-
> tools/lib/bpf/libbpf.c | 2 +-
> tools/lib/bpf/libbpf_internal.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
> index 4d565d202ce3..24ce50fc1fc1 100644
> --- a/Documentation/bpf/btf.rst
> +++ b/Documentation/bpf/btf.rst
> @@ -670,7 +670,7 @@ func_info for each specific ELF section.::
> __u32 sec_name_off; /* offset to section name */
> __u32 num_info;
> /* Followed by num_info * record_size number of bytes */
> -__u8data[0];
> +__u8data[];
> };
>
> Here, num_info must be greater than 0.
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index e0276520171b..c02ea0e1a588 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -5577,7 +5577,7 @@ static struct perf_buffer *__perf_buffer__new(int
> map_fd, size_t page_cnt,
> struct perf_sample_raw {
> struct perf_event_header header;
> uint32_t size;
> - char data[0];
> + char data[];
> };
>
> struct perf_sample_lost {
> diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h
> index 2e83a34f8c79..930ada2276bf 100644
> --- a/tools/lib/bpf/libbpf_internal.h
> +++ b/tools/lib/bpf/libbpf_internal.h
> @@ -86,7 +86,7 @@ struct btf_ext_info_sec {
> __u32 sec_name_off;
> __u32 num_info;
> /* Followed by num_info * record_size number of bytes */
> - __u8data[0];
> + __u8data[];
> };
>
> /* The minimum bpf_func_info checked by the loader */
>
Re: [PATCH] docs: use flexible array members, not zero-length
On Sat, 28 Sep 2019 10:55:57 +0200 Stephen Kitt wrote: > Wouldn’t it be better to update the docs simultaneously in each patch which > fixes a structure? Or is that unworkable with current development practices? Definitely update the two together. The doc fix should just go through the appropriate maintainer with the code change. Thanks, jon
Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info
On 2019-09-30 08:01, Daniel Kiper wrote:
>
> OK.
>
>> field for the entire .kernel_info section, thus ensuring it is a
>> single self-contained blob.
>
> .rodata.kernel_info contains its total size immediately behind the
> "InfO" header. Do you suggest that we should add the size of
> .rodata.kernel_info into setup_header too?
>
No, what I want is a chunked architecture for kernel_info.
That is:
/* Common chunk header */
struct kernel_info_header {
uint32_t magic;
uint32_t len;
};
/* Top-level chunk, always first */
#define KERNEL_INFO_MAGIC 0x45fdbe4f
struct kernel_info {
struct kernel_info_header hdr;
uint32_t total_size;/* Total size of all chunks */
/* Various fixed-sized data objects, OR offsets to other chunks */
};
Also "InfO" is a pretty hideous magic. In general, all-ASCII magics have much
higher risk of collision than *RANDOM* binary numbers. However, for a chunked
architecture they do have the advantage that they can be used also as a human
name or file name for the chunk, e.,g. in sysfs, so maybe something like
"LnuX" or even "LToP" for the top-level chunk might make sense.
How does that sound?
-hpa
Re: Why no section for "Kernel/Linux Documentation" here : https://patchwork.kernel.org/
On Mon, 30 Sep 2019 21:28:26 +0530 Bhaskar Chowdhury wrote: > Why that page missing a section "Kernel Documentation" ?? OR am I > missing the title therenot sure...there must be some reason. Many kernel subsystems do not use patchwork; documentation has always been one of them. Perhaps that should change someday; let's see how the workflow discussions go. jon
Re: [PATCH] docs: networking: Add title caret and missing doc
On Sat, 28 Sep 2019 22:39:17 +1000, Adam Zerella wrote: > Resolving a couple of Sphinx documentation warnings > that are generated in the networking section. > > - WARNING: document isn't included in any toctree > - WARNING: Title underline too short. > > Signed-off-by: Adam Zerella > --- > Documentation/networking/device_drivers/index.rst | 1 + > Documentation/networking/j1939.rst| 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/networking/device_drivers/index.rst > b/Documentation/networking/device_drivers/index.rst > index f51f92571e39..1f4a629e7caa 100644 > --- a/Documentation/networking/device_drivers/index.rst > +++ b/Documentation/networking/device_drivers/index.rst > @@ -24,6 +24,7 @@ Contents: > google/gve > mellanox/mlx5 > pensando/ionic > + netronome/nfp I wonder if it's worth keeping the entries in a roughly alphabetic order? > .. only:: subproject and html > > diff --git a/Documentation/networking/j1939.rst > b/Documentation/networking/j1939.rst > index ce7e7a044e08..dc60b13fcd09 100644 > --- a/Documentation/networking/j1939.rst > +++ b/Documentation/networking/j1939.rst > @@ -272,7 +272,7 @@ supported flags are: > * MSG_DONTWAIT, i.e. non-blocking operation. > > recvmsg(2) > -^ > +^^ > > In most cases recvmsg(2) is needed if you want to extract more information > than > recvfrom(2) can provide. For example package priority and timestamp. The
