[PATCH v2 6/6] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v1: - Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES ---

[PATCH v2 5/6] kbuild: generate modules.builtin.ranges when linking the kernel

Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v1: - Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES --- scripts/Makefile.vmlinux | 17 + 1 file changed, 17 insertions(+) diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux

[PATCH v2 4/6] module: script to generate offset ranges for builtin modules

The offset range data for builtin modules is generated using: - modules.builtin.objs: associates object files with module names - vmlinux.map: provides load order of sections and offset of first member per section - vmlinux.o.map: provides offset of object file content per section The

[PATCH v2 3/6] kbuild: generate a linker map for vmlinux.o

When CONFIG_BUILTIN_MODULE_RANGES is set, a linker map for vmlinux.o needs to be generated. The generation of offset range data for builtin modules depends on that linker map to know what offsets in an ELF section belong to an object file for a particular builtin module. Signed-off-by: Kris Van

[PATCH v2 2/6] trace: add CONFIG_BUILTIN_MODULE_RANGES option

The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data is generated for kernel modules that are built into the kernel image. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire --- Changes since v1: - Renamed CONFIG_BUILTIN_RANGES to

[PATCH v2 1/6] kbuild: add modules.builtin.objs

From: Luis Chamberlain The file modules.builtin names all modules that are built into the kernel; this is checked by modprobe to not fail when trying to load something built-in. But for tools which want to see which object files make up each module, we want to help them with such a mapping as it

[PATCH v2 0/6] Generate address range data for built-in modules

Especially for tracing applications, it is convenient to be able to refer to a symbol using a pair and to be able to translate an address into a pair. But that does not work if the module is built into the kernel because the object files that comprise the built-in module implementation are

Re: [PATCH] modules: Drop the .export_symbol section from the final modules

On Wed, Apr 17, 2024 at 01:35:30PM +0800, wang...@lemote.com wrote: > From: Wang Yao > > Commit ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost") > forget drop the .export_symbol section from the final modules. > > Signed-off-by: Wang Yao Masahiro, commit ddb5cdbafaaa ("kbuild:

[PATCH v8 3/5] soc: qcom: pdr: extract PDR message marshalling data

The in-kernel PD mapper is going to use same message structures as the QCOM_PDR_HELPERS module. Extract message marshalling data to separate module that can be used by both PDR helpers and by PD mapper. Reviewed-by: Bryan O'Donoghue Tested-by: Steev Klimaszewski Tested-by: Alexey Minnekhanov

[PATCH v8 4/5] soc: qcom: add pd-mapper implementation

Existing userspace protection domain mapper implementation has several issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't reread JSON files if firmware location is changed (or if firmware was not available at the time pd-mapper was started but the corresponding directory is mounted

[PATCH v8 5/5] remoteproc: qcom: enable in-kernel PD mapper

Request in-kernel protection domain mapper to be started before starting Qualcomm DSP and release it once DSP is stopped. Once all DSPs are stopped, the PD mapper will be stopped too. Signed-off-by: Dmitry Baryshkov --- drivers/remoteproc/qcom_common.c| 87

[PATCH v8 2/5] soc: qcom: pdr: fix parsing of domains lists

While parsing the domains list, start offsets from 0 rather than from domains_read. The domains_read is equal to the total count of the domains we have seen, while the domains list in the message starts from offset 0. Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")

[PATCH v8 0/5] soc: qcom: add in-kernel pd-mapper implementation

Protection domain mapper is a QMI service providing mapping between 'protection domains' and services supported / allowed in these domains. For example such mapping is required for loading of the WiFi firmware or for properly starting up the UCSI / altmode / battery manager support. The existing

[PATCH v8 1/5] soc: qcom: pdr: protect locator_addr with the main mutex

If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock. Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Tested-by: Neil Armstrong #

Re: [PATCH v7 1/6] soc: qcom: pdr: protect locator_addr with the main mutex

On Thu, 25 Apr 2024 at 22:30, Chris Lew wrote: > > > On 4/24/2024 2:27 AM, Dmitry Baryshkov wrote: > > If the service locator server is restarted fast enough, the PDR can > > rewrite locator_addr fields concurrently. Protect them by placing > > modification of those fields under the main

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

On Thu, May 09, 2024 at 04:24:37PM +, Edgecombe, Rick P wrote: > On Thu, 2024-05-09 at 10:30 +0200, Jiri Olsa wrote: > > > Per the earlier discussion, this cannot be reached unless uretprobes are > > > in > > > use, > > > which cannot happen without something with privileges taking an action.

Re: [RFC PATCH v3 1/7] mm/damon/paddr: refactor DAMOS_PAGEOUT with migration_mode

On Fri, 5 Apr 2024 12:19:07 -0700 SeongJae Park wrote: > On Fri, 5 Apr 2024 15:08:50 +0900 Honggyu Kim wrote: > > > This is a preparation patch that introduces migration modes. > > > > The damon_pa_pageout is renamed to damon_pa_migrate and it receives an > > extra argument for

Re: [PATCH net-next] virtio_net: Fix error code in __virtnet_get_hw_stats()

On Fri, May 10, 2024 at 03:50:45PM +0300, Dan Carpenter wrote: > The virtnet_send_command_reply() function returns true on success or > false on failure. The "ok" variable is true/false depending on whether > it succeeds or not. It's up to the caller to translate the true/false > into -EINVAL on