Re: [PATCH v2] bus: mhi: host: Add tracing support
Hi Krishna,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 3006adf3be79cde4d14b1800b963b82b6e5572e0]
url:
https://github.com/intel-lab-lkp/linux/commits/Krishna-chaitanya-chundru/bus-mhi-host-Add-tracing-support/20231017-120241
base: 3006adf3be79cde4d14b1800b963b82b6e5572e0
patch link:
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce010b5%40quicinc.com
patch subject: [PATCH v2] bus: mhi: host: Add tracing support
config: i386-randconfig-002-20231020
(https://download.01.org/0day-ci/archive/20231020/202310201110.s903hmed-...@intel.com/config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231020/202310201110.s903hmed-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202310201110.s903hmed-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/bus/mhi/host/main.c:249:12: warning: no previous declaration for
>> 'mhi_to_physical' [-Wmissing-declarations]
dma_addr_t mhi_to_physical(struct mhi_ring *ring, void *addr)
^~~
vim +/mhi_to_physical +249 drivers/bus/mhi/host/main.c
248
> 249 dma_addr_t mhi_to_physical(struct mhi_ring *ring, void *addr)
250 {
251 return (addr - ring->base) + ring->iommu_base;
252 }
253
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
RE: [PATCH v1 1/1] ACPI: NFIT: Switch to use acpi_evaluate_dsm_typed()
Andy Shevchenko wrote: > The acpi_evaluate_dsm_typed() provides a way to check the type of the > object evaluated by _DSM call. Use it instead of open coded variant. Looks good to me. Reviewed-by: Dan Williams
Re: [PATCH v1 1/1] ACPI: NFIT: Switch to use acpi_evaluate_dsm_typed()
Wilczynski, Michal wrote:
>
>
> On 10/2/2023 3:54 PM, Andy Shevchenko wrote:
> > The acpi_evaluate_dsm_typed() provides a way to check the type of the
> > object evaluated by _DSM call. Use it instead of open coded variant.
> >
> > Signed-off-by: Andy Shevchenko
> > ---
> > drivers/acpi/nfit/core.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> > index f96bf32cd368..280da408c02c 100644
> > --- a/drivers/acpi/nfit/core.c
> > +++ b/drivers/acpi/nfit/core.c
> > @@ -1737,9 +1737,8 @@ __weak void nfit_intel_shutdown_status(struct
> > nfit_mem *nfit_mem)
> > if ((nfit_mem->dsm_mask & (1 << func)) == 0)
> > return;
> >
> > - out_obj = acpi_evaluate_dsm(handle, guid, revid, func, _obj);
> > - if (!out_obj || out_obj->type != ACPI_TYPE_BUFFER
> > - || out_obj->buffer.length < sizeof(smart)) {
> > + out_obj = acpi_evaluate_dsm_typed(handle, guid, revid, func, _obj,
> > ACPI_TYPE_BUFFER);
>
> This line is 90 characters long, wouldn't it be better to split it ?
100 characters is allowed these days.
> > + if (!out_obj || out_obj->buffer.length < sizeof(smart)) {
> > dev_dbg(dev->parent, "%s: failed to retrieve initial health\n",
> > dev_name(dev));
>
> While at it maybe fix alignment ? :-)
Life is too short to fiddle with indentation. For old code leave it
alone, for new code just use clang-format.
[PATCH] eventfs: Fix failure path in eventfs_create_events_dir()
From: "Steven Rostedt (Google)"
The failure path of allocating ei goes to a path that dereferences ei.
Add another label that skips over the ei dereferences to do the rest of
the clean up.
Link: https://lore.kernel.org/all/70e7bace-561c-95f-1117-706c2c22...@inria.fr/
Fixes: 5790b1fb3d67 ("eventfs: Remove eventfs_file and just use eventfs_inode")
Reported-by: Julia Lawall
Signed-off-by: Steven Rostedt (Google)
---
fs/tracefs/event_inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index 9f19b6608954..1885f1f1f339 100644
--- a/fs/tracefs/event_inode.c
+++ b/fs/tracefs/event_inode.c
@@ -735,7 +735,7 @@ struct eventfs_inode *eventfs_create_events_dir(const char
*name, struct dentry
ei = kzalloc(sizeof(*ei), GFP_KERNEL);
if (!ei)
- goto fail;
+ goto fail_ei;
inode = tracefs_get_inode(dentry->d_sb);
if (unlikely(!inode))
@@ -781,6 +781,7 @@ struct eventfs_inode *eventfs_create_events_dir(const char
*name, struct dentry
fail:
kfree(ei->d_children);
kfree(ei);
+ fail_ei:
tracefs_failed_creating(dentry);
return ERR_PTR(-ENOMEM);
}
--
2.42.0
[PATCH v5 06/12] x86/bugs: Rename SLS to CONFIG_MITIGATION_SLS
CPU mitigations config entries are inconsistent, and names are hard to
related. There are concrete benefits for both users and developers of
having all the mitigation config options living in the same config
namespace.
The mitigation options should have consistency and start with
MITIGATION.
Rename the Kconfig entry from SLS to MITIGATION_SLS.
Suggested-by: Josh Poimboeuf
Signed-off-by: Breno Leitao
---
arch/x86/Kconfig | 2 +-
arch/x86/Makefile | 2 +-
arch/x86/include/asm/linkage.h | 4 ++--
arch/x86/kernel/alternative.c | 4 ++--
arch/x86/kernel/ftrace.c | 3 ++-
arch/x86/net/bpf_jit_comp.c| 4 ++--
scripts/Makefile.lib | 2 +-
7 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f3593461ce35..9dd2fb555973 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2556,7 +2556,7 @@ config CPU_SRSO
help
Enable the SRSO mitigation needed on AMD Zen1-4 machines.
-config SLS
+config MITIGATION_SLS
bool "Mitigate Straight-Line-Speculation"
depends on CC_HAS_SLS && X86_64
select OBJTOOL if HAVE_OBJTOOL
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 3053b60f017b..1ac5d6002f5f 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -204,7 +204,7 @@ ifdef CONFIG_MITIGATION_RETPOLINE
endif
endif
-ifdef CONFIG_SLS
+ifdef CONFIG_MITIGATION_SLS
KBUILD_CFLAGS += -mharden-sls=all
endif
diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index c5165204c66f..09e2d026df33 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -43,7 +43,7 @@
#if defined(CONFIG_RETHUNK) && !defined(__DISABLE_EXPORTS) &&
!defined(BUILD_VDSO)
#define RETjmp __x86_return_thunk
#else /* CONFIG_MITIGATION_RETPOLINE */
-#ifdef CONFIG_SLS
+#ifdef CONFIG_MITIGATION_SLS
#define RETret; int3
#else
#define RETret
@@ -55,7 +55,7 @@
#if defined(CONFIG_RETHUNK) && !defined(__DISABLE_EXPORTS) &&
!defined(BUILD_VDSO)
#define ASM_RET"jmp __x86_return_thunk\n\t"
#else /* CONFIG_MITIGATION_RETPOLINE */
-#ifdef CONFIG_SLS
+#ifdef CONFIG_MITIGATION_SLS
#define ASM_RET"ret; int3\n\t"
#else
#define ASM_RET"ret\n\t"
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 8932f524c935..ea9652eb455b 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -624,8 +624,8 @@ static int patch_retpoline(void *addr, struct insn *insn,
u8 *bytes)
/*
* The compiler is supposed to EMIT an INT3 after every unconditional
* JMP instruction due to AMD BTC. However, if the compiler is too old
-* or SLS isn't enabled, we still need an INT3 after indirect JMPs
-* even on Intel.
+* or MITIGATION_SLS isn't enabled, we still need an INT3 after
+* indirect JMPs even on Intel.
*/
if (op == JMP32_INSN_OPCODE && i < insn->length)
bytes[i++] = INT3_INSN_OPCODE;
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 0f26758c7a93..b000158b781a 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -297,7 +297,8 @@ union ftrace_op_code_union {
} __attribute__((packed));
};
-#define RET_SIZE (IS_ENABLED(CONFIG_MITIGATION_RETPOLINE) ? 5 : 1 +
IS_ENABLED(CONFIG_SLS))
+#define RET_SIZE \
+ (IS_ENABLED(CONFIG_MITIGATION_RETPOLINE) ? 5 : 1 +
IS_ENABLED(CONFIG_MITIGATION_SLS))
static unsigned long
create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index ef732f323926..96a63c4386a9 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -469,7 +469,7 @@ static void emit_indirect_jump(u8 **pprog, int reg, u8 *ip)
emit_jump(, &__x86_indirect_thunk_array[reg], ip);
} else {
EMIT2(0xFF, 0xE0 + reg);/* jmp *%\reg */
- if (IS_ENABLED(CONFIG_MITIGATION_RETPOLINE) ||
IS_ENABLED(CONFIG_SLS))
+ if (IS_ENABLED(CONFIG_MITIGATION_RETPOLINE) ||
IS_ENABLED(CONFIG_MITIGATION_SLS))
EMIT1(0xCC);/* int3 */
}
@@ -484,7 +484,7 @@ static void emit_return(u8 **pprog, u8 *ip)
emit_jump(, x86_return_thunk, ip);
} else {
EMIT1(0xC3);/* ret */
- if (IS_ENABLED(CONFIG_SLS))
+ if (IS_ENABLED(CONFIG_MITIGATION_SLS))
EMIT1(0xCC);/* int3 */
}
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index d6e157938b5f..0d5461276179 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -264,7 +264,7 @@ endif
objtool-args-$(CONFIG_UNWINDER_ORC)+= --orc
objtool-args-$(CONFIG_MITIGATION_RETPOLINE)+= --retpoline
objtool-args-$(CONFIG_RETHUNK)
Re: [PATCH v5 16/18] x86/sgx: Limit process EPC usage with misc cgroup controller
On Tue, 17 Oct 2023 13:54:54 -0500, Michal Koutný wrote:
On Fri, Sep 22, 2023 at 08:06:55PM -0700, Haitao Huang
wrote:
+static void sgx_epc_cgroup_free(struct misc_cg *cg)
+{
+ struct sgx_epc_cgroup *epc_cg;
+
+ epc_cg = sgx_epc_cgroup_from_misc_cg(cg);
It should check for !epc_cg since the misc controller implementation
in misc_cg_alloc() would roll back even on non-allocated resources.
Good catch. Will fix.
+ cancel_work_sync(_cg->reclaim_work);
+ kfree(epc_cg);
+}
+
+static void sgx_epc_cgroup_max_write(struct misc_cg *cg)
+{
+ struct sgx_epc_reclaim_control rc;
+ struct sgx_epc_cgroup *epc_cg;
+
+ epc_cg = sgx_epc_cgroup_from_misc_cg(cg);
+
+ sgx_epc_reclaim_control_init(, epc_cg);
+ /* Let the reclaimer to do the work so user is not blocked */
+ queue_work(sgx_epc_cg_wq, _cg->reclaim_work);
This is weird. The writer will never learn about the result of the
operation.
Right. With the new plan, this callback will be removed.
Thanks
Haitao
Re: [PATCH v1 1/1] ACPI: NFIT: Switch to use acpi_evaluate_dsm_typed()
On Mon, Oct 02, 2023 at 04:54:58PM +0300, Andy Shevchenko wrote: > The acpi_evaluate_dsm_typed() provides a way to check the type of the > object evaluated by _DSM call. Use it instead of open coded variant. Dan, do you have any comments? -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 0/2] Return EADDRNOTAVAIL when func matches several symbols during kprobe creation
On Thu, 19 Oct 2023 09:51:04 -0400
Steven Rostedt wrote:
> On Thu, 19 Oct 2023 21:18:43 +0900
> Masami Hiramatsu (Google) wrote:
>
> > > So why is this adding stable? (and as Greg's form letter states, that's
> > > not
> > > how you do that)
> > >
> > > I don't see this as a fix but a new feature.
> >
> > I asked him to make this a fix since the current kprobe event' behavior is
> > somewhat strange. It puts the probe on only the "first symbol" if user
> > specifies a symbol name which has multiple instances. In this case, the
> > actual probe address can not be solved by name. User must specify the
> > probe address by unique name + offset. Unless, it can put a probe on
> > unexpected address, especially if it specifies non-unique symbol + offset,
> > the address may NOT be the instruction boundary.
> > To avoid this issue, it should check the given symbol is unique.
> >
>
> OK, so what is broken is that when you add a probe to a function that has
> multiple names, it will attach to the first one and not necessarily the one
> you want.
>
> The change log needs to be more explicit in what the "bug" is. It does
> state this in a round about way, but it is written in a way that it doesn't
> stand out.
>
> Previously to this commit, if func matches several symbols, a kprobe,
> being either sysfs or PMU, would only be installed for the first
> matching address. This could lead to some misunderstanding when some
> BPF code was never called because it was attached to a function which
> was indeed not called, because the effectively called one has no
> kprobes attached.
>
> So, this commit returns EADDRNOTAVAIL when func matches several
> symbols. This way, user needs to use address to remove the ambiguity.
>
>
> What it should say is:
>
> When a kprobe is attached to a function that's name is not unique (is
> static and shares the name with other functions in the kernel), the
> kprobe is attached to the first function it finds. This is a bug as the
> function that it is attaching to is not necessarily the one that the
> user wants to attach to.
>
> Instead of blindly picking a function to attach to what is ambiguous,
> error with EADDRNOTAVAIL to let the user know that this function is not
> unique, and that the user must use another unique function with an
> address offset to get to the function they want to attach to.
>
Great!, yes this looks good to me too.
> And yes, it should have:
>
> Cc: sta...@vger.kernel.org
>
> which is how to mark something for stable, and
>
> Fixes: ...
>
> To the commit that caused the bug.
Yes, this should be the first one.
Fixes: 413d37d1eb69 ("tracing: Add kprobe-based event tracer")
Thank you,
>
> -- Steve
--
Masami Hiramatsu (Google)
Re: [PATCH v5 0/2] Return EADDRNOTAVAIL when func matches several symbols during kprobe creation
On Thu, 19 Oct 2023 21:18:43 +0900 Masami Hiramatsu (Google) wrote: > > So why is this adding stable? (and as Greg's form letter states, that's not > > how you do that) > > > > I don't see this as a fix but a new feature. > > I asked him to make this a fix since the current kprobe event' behavior is > somewhat strange. It puts the probe on only the "first symbol" if user > specifies a symbol name which has multiple instances. In this case, the > actual probe address can not be solved by name. User must specify the > probe address by unique name + offset. Unless, it can put a probe on > unexpected address, especially if it specifies non-unique symbol + offset, > the address may NOT be the instruction boundary. > To avoid this issue, it should check the given symbol is unique. > OK, so what is broken is that when you add a probe to a function that has multiple names, it will attach to the first one and not necessarily the one you want. The change log needs to be more explicit in what the "bug" is. It does state this in a round about way, but it is written in a way that it doesn't stand out. Previously to this commit, if func matches several symbols, a kprobe, being either sysfs or PMU, would only be installed for the first matching address. This could lead to some misunderstanding when some BPF code was never called because it was attached to a function which was indeed not called, because the effectively called one has no kprobes attached. So, this commit returns EADDRNOTAVAIL when func matches several symbols. This way, user needs to use address to remove the ambiguity. What it should say is: When a kprobe is attached to a function that's name is not unique (is static and shares the name with other functions in the kernel), the kprobe is attached to the first function it finds. This is a bug as the function that it is attaching to is not necessarily the one that the user wants to attach to. Instead of blindly picking a function to attach to what is ambiguous, error with EADDRNOTAVAIL to let the user know that this function is not unique, and that the user must use another unique function with an address offset to get to the function they want to attach to. And yes, it should have: Cc: sta...@vger.kernel.org which is how to mark something for stable, and Fixes: ... To the commit that caused the bug. -- Steve
Re: [PATCH v5 0/2] Return EADDRNOTAVAIL when func matches several symbols during kprobe creation
On Wed, 18 Oct 2023 13:00:42 -0400 Steven Rostedt wrote: > On Wed, 18 Oct 2023 17:40:28 +0300 > Francis Laniel wrote: > > > Changes since: > > v1: > > * Use EADDRNOTAVAIL instead of adding a new error code. > > * Correct also this behavior for sysfs kprobe. > > v2: > > * Count the number of symbols corresponding to function name and return > > EADDRNOTAVAIL if higher than 1. > > * Return ENOENT if above count is 0, as it would be returned later by > > while > > registering the kprobe. > > v3: > > * Check symbol does not contain ':' before testing its uniqueness. > > * Add a selftest to check this is not possible to install a kprobe for a > > non > > unique symbol. > > v5: > > * No changes, just add linux-stable as recipient. > > So why is this adding stable? (and as Greg's form letter states, that's not > how you do that) > > I don't see this as a fix but a new feature. I asked him to make this a fix since the current kprobe event' behavior is somewhat strange. It puts the probe on only the "first symbol" if user specifies a symbol name which has multiple instances. In this case, the actual probe address can not be solved by name. User must specify the probe address by unique name + offset. Unless, it can put a probe on unexpected address, especially if it specifies non-unique symbol + offset, the address may NOT be the instruction boundary. To avoid this issue, it should check the given symbol is unique. Thank you, > > -- Steve -- Masami Hiramatsu (Google)
Re: [PATCH v6 4/4] remoteproc: zynqmp: parse TCM from device tree
Hi Tanmay, kernel test robot noticed the following build warnings: [auto build test WARNING on a7d272979d3a89b117ca2c547dc8a465c4f28635] url: https://github.com/intel-lab-lkp/linux/commits/Tanmay-Shah/dt-bindings-remoteproc-add-Tightly-Coupled-Memory-TCM-bindings/20231017-120805 base: a7d272979d3a89b117ca2c547dc8a465c4f28635 patch link: https://lore.kernel.org/r/20231013042229.3954527-5-tanmay.shah%40amd.com patch subject: [PATCH v6 4/4] remoteproc: zynqmp: parse TCM from device tree config: arm64-randconfig-002-20231019 (https://download.01.org/0day-ci/archive/20231019/202310191806.njlsejwm-...@intel.com/config) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231019/202310191806.njlsejwm-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202310191806.njlsejwm-...@intel.com/ All warnings (new ones prefixed by >>): drivers/remoteproc/xlnx_r5_remoteproc.c: In function 'zynqmp_r5_get_tcm_node_from_dt': >> drivers/remoteproc/xlnx_r5_remoteproc.c:1162:28: warning: array subscript >> 'struct mem_bank_data[0]' is partly outside array bounds of 'unsigned >> char[8]' [-Warray-bounds=] 1162 | tcm->da = (u32)abs_addr; |^~ In file included from include/linux/dma-mapping.h:8, from drivers/remoteproc/xlnx_r5_remoteproc.c:8: In function 'devm_kzalloc', inlined from 'zynqmp_r5_get_tcm_node_from_dt' at drivers/remoteproc/xlnx_r5_remoteproc.c:1143:10: include/linux/device.h:314:16: note: object of size 8 allocated by 'devm_kmalloc' 314 | return devm_kmalloc(dev, size, gfp | __GFP_ZERO); |^ drivers/remoteproc/xlnx_r5_remoteproc.c: In function 'zynqmp_r5_get_tcm_node_from_dt': drivers/remoteproc/xlnx_r5_remoteproc.c:1163:28: warning: array subscript 'struct mem_bank_data[0]' is partly outside array bounds of 'unsigned char[8]' [-Warray-bounds=] 1163 | tcm->size = (u32)size; |^~ In function 'devm_kzalloc', inlined from 'zynqmp_r5_get_tcm_node_from_dt' at drivers/remoteproc/xlnx_r5_remoteproc.c:1143:10: include/linux/device.h:314:16: note: object of size 8 allocated by 'devm_kmalloc' 314 | return devm_kmalloc(dev, size, gfp | __GFP_ZERO); |^ drivers/remoteproc/xlnx_r5_remoteproc.c: In function 'zynqmp_r5_get_tcm_node_from_dt': drivers/remoteproc/xlnx_r5_remoteproc.c:1172:28: warning: array subscript 'struct mem_bank_data[0]' is partly outside array bounds of 'unsigned char[8]' [-Warray-bounds=] 1172 | tcm->addr = (u32)res->start; |^~ In function 'devm_kzalloc', inlined from 'zynqmp_r5_get_tcm_node_from_dt' at drivers/remoteproc/xlnx_r5_remoteproc.c:1143:10: include/linux/device.h:314:16: note: object of size 8 allocated by 'devm_kmalloc' 314 | return devm_kmalloc(dev, size, gfp | __GFP_ZERO); |^ drivers/remoteproc/xlnx_r5_remoteproc.c: In function 'zynqmp_r5_get_tcm_node_from_dt': drivers/remoteproc/xlnx_r5_remoteproc.c:1173:28: warning: array subscript 'struct mem_bank_data[0]' is partly outside array bounds of 'unsigned char[8]' [-Warray-bounds=] 1173 | tcm->bank_name = (char *)res->name; |^~ In function 'devm_kzalloc', inlined from 'zynqmp_r5_get_tcm_node_from_dt' at drivers/remoteproc/xlnx_r5_remoteproc.c:1143:10: include/linux/device.h:314:16: note: object of size 8 allocated by 'devm_kmalloc' 314 | return devm_kmalloc(dev, size, gfp | __GFP_ZERO); |^ In file included from include/linux/device.h:17: drivers/remoteproc/xlnx_r5_remoteproc.c: In function 'zynqmp_r5_get_tcm_node_from_dt': drivers/remoteproc/xlnx_r5_remoteproc.c:1174:74: warning: array subscript 'struct mem_bank_data[0]' is partly outside array bounds of 'unsigned char[8]' [-Warray-bounds=] 1174 | res = devm_request_mem_region(dev, tcm->addr, tcm->size, | ^~ include/linux/ioport.h:306:63: note: in definition of macro 'devm_request_mem_region' 306 | __devm_request_region(dev, _resource, (start), (n), (name)) | ^ In function 'devm_kzalloc', inlined f
Re: [PATCH v5 0/2] Return EADDRNOTAVAIL when func matches several symbols during kprobe creation
Hi! Le mercredi 18 octobre 2023, 20:00:42 EEST Steven Rostedt a écrit : > On Wed, 18 Oct 2023 17:40:28 +0300 > > Francis Laniel wrote: > > Changes since: > > v1: > > * Use EADDRNOTAVAIL instead of adding a new error code. > > * Correct also this behavior for sysfs kprobe. > > > > v2: > > * Count the number of symbols corresponding to function name and return > > EADDRNOTAVAIL if higher than 1. > > * Return ENOENT if above count is 0, as it would be returned later by > > while > > registering the kprobe. > > > > v3: > > * Check symbol does not contain ':' before testing its uniqueness. > > * Add a selftest to check this is not possible to install a kprobe for a > > non unique symbol. > > > > v5: > > * No changes, just add linux-stable as recipient. > > So why is this adding stable? (and as Greg's form letter states, that's not > how you do that) Oops! Really sorry for this, I will correct everything for the next version! > > I don't see this as a fix but a new feature. You mean I should add a "Fix:" in the commit description? > > -- Steve Best regards.
Re: [PATCH] dt-bindings: Drop kernel copy of common reserved-memory bindings
Hi Rob, kernel test robot noticed the following build errors: [auto build test ERROR on robh/for-next] [also build test ERROR on krzk-dt/for-next remoteproc/rproc-next broonie-sound/for-next linus/master v6.6-rc6 next-20231018] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Rob-Herring/dt-bindings-Drop-kernel-copy-of-common-reserved-memory-bindings/20231017-125913 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next patch link: https://lore.kernel.org/r/20231013200851.347042-1-robh%40kernel.org patch subject: [PATCH] dt-bindings: Drop kernel copy of common reserved-memory bindings config: arm64-allyesconfig (https://download.01.org/0day-ci/archive/20231019/202310191537.20z1aolb-...@intel.com/config) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20231019/202310191537.20z1aolb-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202310191537.20z1aolb-...@intel.com/ All errors (new ones prefixed by >>): sort: -:2: disorder: 2023.8.dev2+gd5e5147 >> ERROR: dtschema minimum version is v2023.9 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH 2/2] mm: multi-gen lru: fix stat count
在 2023/10/19 10:39, Yu Zhao 写道:
On Wed, Oct 18, 2023 at 8:17 PM Huan Yang wrote:
Hi Yu Zhao,
Thanks for your reply.
在 2023/10/19 0:21, Yu Zhao 写道:
On Wed, Oct 18, 2023 at 2:22 AM Huan Yang wrote:
For multi-gen lru reclaim in evict_folios, like shrink_inactive_list,
gather folios which isolate to reclaim, and invoke shirnk_folio_list.
But, when complete shrink, it not gather shrink reclaim stat into sc,
we can't get info like nr_dirty\congested in reclaim, and then
control writeback, dirty number and mark as LRUVEC_CONGESTED, or
just bpf trace shrink and get correct sc stat.
This patch fix this by simple copy code from shrink_inactive_list when
end of shrink list.
MGLRU doesn't try to write back dirt file pages in the reclaim path --
it filters them out in sort_folio() and leaves them to the page
Nice to know this, sort_folio() filters some folio indeed.
But, I want to know, if we touch some folio in shrink_folio_list(), may some
folio become dirty or writeback even if sort_folio() filter then?
Good question: in that case MGLRU still doesn't try to write those
folios back because isolate_folio() cleared PG_reclaim and
shrink_folio_list() checks PG_reclaim:
Thank you too much. So, MGLRU have many diff between typic LRU reclaim.
So, why don't offer MGLRU a own shrink path to avoid so many check of folio?
And more think, it's nice to assign a anon/file reclaim hook into
anon_vma/address_space?
(Each folio, have their own shrink path, don't try check path if it no
need.)
if (folio_test_dirty(folio)) {
/*
* Only kswapd can writeback filesystem folios
* to avoid risk of stack overflow. But avoid
* injecting inefficient single-folio I/O into
* flusher writeback as much as possible: only
* write folios when we've encountered many
* dirty folios, and when we've already scanned
* the rest of the LRU for clean folios and see
* the same dirty folios again (with the reclaim
* flag set).
*/
if (folio_is_file_lru(folio) &&
(!current_is_kswapd() ||
!folio_test_reclaim(folio) ||
!test_bit(PGDAT_DIRTY, >flags))) {
Thanks
