Re: [PATCH 5/5] ARM: dts: qcom: msm8974pro-castor: Rename wifi node name
On Wed, 6 Mar 2024 at 01:18, Luca Weiss wrote: > > Give the wifi node a generic node name 'wifi'. > > Signed-off-by: Luca Weiss > --- > arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 4/5] ARM: dts: qcom: msm8974pro-castor: Add debounce-interval for keys
On Wed, 6 Mar 2024 at 01:26, Luca Weiss wrote: > > Set the debounce-interval for the GPIO keys. > > Signed-off-by: Luca Weiss > --- > arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 2/5] ARM: dts: qcom: msm8974pro-castor: Add mmc aliases
On Wed, 6 Mar 2024 at 01:26, Luca Weiss wrote: > > Add the mmc0 & mmc1 aliases to make sure internal storage always becomes > /dev/mmcblk0 and SD card becomes /dev/mmcblk1 > > Signed-off-by: Luca Weiss > --- > arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[PATCH 0/2] ASoC: trace: trace more parameters in ASoC DAPM events
This small series adds parameters to existing DAPM trace events to make them more informative. Signed-off-by: Luca Ceresoli --- Luca Ceresoli (2): ASoC: trace: add component to set_bias_level trace events ASoC: trace: add event to snd_soc_dapm trace events include/trace/events/asoc.h | 45 + sound/soc/soc-dapm.c| 8 2 files changed, 29 insertions(+), 24 deletions(-) --- base-commit: e7cc5f08886d5a86cada34b421d75989413fdea6 change-id: 20240306-improve-asoc-trace-events-7ddb6b37edec Best regards, -- Luca Ceresoli
[PATCH 2/2] ASoC: trace: add event to snd_soc_dapm trace events
Add the event value to the snd_soc_dapm_start and snd_soc_dapm_done trace
events to make them more informative.
Trace before:
aplay-229 [000] 250.140309: snd_soc_dapm_start: card=vscn-2046
aplay-229 [000] 250.167531: snd_soc_dapm_done:card=vscn-2046
aplay-229 [000] 251.169588: snd_soc_dapm_start: card=vscn-2046
aplay-229 [000] 251.195245: snd_soc_dapm_done:card=vscn-2046
Trace after:
aplay-214 [000] 693.290612: snd_soc_dapm_start: card=vscn-2046
event=1
aplay-214 [000] 693.315508: snd_soc_dapm_done:card=vscn-2046
event=1
aplay-214 [000] 694.537349: snd_soc_dapm_start: card=vscn-2046
event=2
aplay-214 [000] 694.563241: snd_soc_dapm_done:card=vscn-2046
event=2
Signed-off-by: Luca Ceresoli
---
include/trace/events/asoc.h | 16 +---
sound/soc/soc-dapm.c| 4 ++--
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index b7ac7f100bb4..4eed9028bb11 100644
--- a/include/trace/events/asoc.h
+++ b/include/trace/events/asoc.h
@@ -57,34 +57,36 @@ DEFINE_EVENT(snd_soc_dapm, snd_soc_bias_level_done,
DECLARE_EVENT_CLASS(snd_soc_dapm_basic,
- TP_PROTO(struct snd_soc_card *card),
+ TP_PROTO(struct snd_soc_card *card, int event),
- TP_ARGS(card),
+ TP_ARGS(card, event),
TP_STRUCT__entry(
__string( name, card->name )
+ __field(int,event )
),
TP_fast_assign(
__assign_str(name, card->name);
+ __entry->event = event;
),
- TP_printk("card=%s", __get_str(name))
+ TP_printk("card=%s event=%d", __get_str(name), (int)__entry->event)
);
DEFINE_EVENT(snd_soc_dapm_basic, snd_soc_dapm_start,
- TP_PROTO(struct snd_soc_card *card),
+ TP_PROTO(struct snd_soc_card *card, int event),
- TP_ARGS(card)
+ TP_ARGS(card, event)
);
DEFINE_EVENT(snd_soc_dapm_basic, snd_soc_dapm_done,
- TP_PROTO(struct snd_soc_card *card),
+ TP_PROTO(struct snd_soc_card *card, int event),
- TP_ARGS(card)
+ TP_ARGS(card, event)
);
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 7e8a2a5312f5..ad8ba8fbbaee 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -1963,7 +1963,7 @@ static int dapm_power_widgets(struct snd_soc_card *card,
int event)
snd_soc_dapm_mutex_assert_held(card);
- trace_snd_soc_dapm_start(card);
+ trace_snd_soc_dapm_start(card, event);
for_each_card_dapms(card, d) {
if (dapm_idle_bias_off(d))
@@ -2088,7 +2088,7 @@ static int dapm_power_widgets(struct snd_soc_card *card,
int event)
"DAPM sequencing finished, waiting %dms\n", card->pop_time);
pop_wait(card->pop_time);
- trace_snd_soc_dapm_done(card);
+ trace_snd_soc_dapm_done(card, event);
return 0;
}
--
2.34.1
Re: [PATCH v6 7/7] Documentation: KVM: Add hypercall for LoongArch
On 3/6/24 11:28, maobibo wrote: On 2024/3/6 上午2:26, WANG Xuerui wrote: On 3/4/24 17:10, maobibo wrote: On 2024/3/2 下午5:41, WANG Xuerui wrote: On 3/2/24 16:47, Bibo Mao wrote: [snip] + +KVM hypercall ABI += + +Hypercall ABI on KVM is simple, only one scratch register a0 (v0) and at most +five generic registers used as input parameter. FP register and vector register +is not used for input register and should not be modified during hypercall. +Hypercall function can be inlined since there is only one scratch register. It should be pointed out explicitly that on hypercall return all Well, return value description will added. What do think about the meaning of return value for KVM_HCALL_FUNC_PV_IPI hypercall? The number of CPUs with IPI delivered successfully like kvm x86 or simply success/failure? I just noticed I've forgotten to comment on this question. FYI, RISC-V SBI's equivalent [1] doesn't even indicate errors. And from my perspective, we can always add a new hypercall returning more info should that info is needed in the future; for now I don't have a problem whether the return type is void, bool or number of CPUs that are successfully reached. [1]: https://github.com/riscv-non-isa/riscv-sbi-doc/blob/v2.0/src/ext-ipi.adoc architectural state except ``$a0`` is preserved. Or is the whole ``$a0 - $t8`` range clobbered, just like with Linux syscalls? what is advantage with $a0 - > $t8 clobbered? Because then a hypercall is going to behave identical as an ordinary C function call, which is easy for people and compilers to understand. If you really understand detailed behavior about hypercall/syscall, the conclusion may be different. If T0 - T8 is clobbered with hypercall instruction, hypercall caller need save clobbered register, now hypercall exception save/restore all the registers during VM exits. If so, hypercall caller need not save general registers and it is not necessary scratched for hypercall ABI. Until now all the discussion the macro level, no detail code level. Can you show me some example code where T0-T8 need not save/restore during LoongArch hypercall exception? I was emphasizing that consistency is generally good, and yes that's "macroscopic" level talk. Of course, the hypercall client code would have to do *less* work if *more* registers than the minimum are preserved -- if right now everything is already preserved, nothing needs to change. But please also notice that the context switch cost is paid for every hypercall, and we can't reduce the number of preserved registers without breaking compatibility. So I think we can keep the current implementation behavior, but promise less in the spec: this way we'll keep the possibility of reducing the context switch overhead. -- WANG "xen0n" Xuerui Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
[PATCH 1/2] ASoC: trace: add component to set_bias_level trace events
The snd_soc_bias_level_start and snd_soc_bias_level_done trace events currently look like: aplay-229 [000] 1250.140778: snd_soc_bias_level_start: card=vscn-2046 val=1 aplay-229 [000] 1250.140784: snd_soc_bias_level_done: card=vscn-2046 val=1 aplay-229 [000] 1250.140786: snd_soc_bias_level_start: card=vscn-2046 val=2 aplay-229 [000] 1250.140788: snd_soc_bias_level_done: card=vscn-2046 val=2 kworker/u8:1-21[000] 1250.140871: snd_soc_bias_level_start: card=vscn-2046 val=1 kworker/u8:0-11[000] 1250.140951: snd_soc_bias_level_start: card=vscn-2046 val=1 kworker/u8:0-11[000] 1250.140956: snd_soc_bias_level_done: card=vscn-2046 val=1 kworker/u8:0-11[000] 1250.140959: snd_soc_bias_level_start: card=vscn-2046 val=2 kworker/u8:0-11[000] 1250.140961: snd_soc_bias_level_done: card=vscn-2046 val=2 kworker/u8:1-21[000] 1250.167219: snd_soc_bias_level_done: card=vscn-2046 val=1 kworker/u8:1-21[000] 1250.167222: snd_soc_bias_level_start: card=vscn-2046 val=2 kworker/u8:1-21[000] 1250.167232: snd_soc_bias_level_done: card=vscn-2046 val=2 kworker/u8:0-11[000] 1250.167440: snd_soc_bias_level_start: card=vscn-2046 val=3 kworker/u8:0-11[000] 1250.167444: snd_soc_bias_level_done: card=vscn-2046 val=3 kworker/u8:1-21[000] 1250.167497: snd_soc_bias_level_start: card=vscn-2046 val=3 kworker/u8:1-21[000] 1250.167506: snd_soc_bias_level_done: card=vscn-2046 val=3 There are clearly multiple calls, one per component, but they cannot be discriminated from each other. Change the ftrace events to also print the component name, to make it clear which part of the code is involved. This requires changing the passed value from a struct snd_soc_card, where the DAPM context is not kwown, to a struct snd_soc_dapm_context where it is obviously known but the a card pointer is also available. With this change, the resulting trace becomes: aplay-247 [000] 1436.357332: snd_soc_bias_level_start: card=vscn-2046 component=(none) val=1 aplay-247 [000] 1436.357338: snd_soc_bias_level_done: card=vscn-2046 component=(none) val=1 aplay-247 [000] 1436.357340: snd_soc_bias_level_start: card=vscn-2046 component=(none) val=2 aplay-247 [000] 1436.357343: snd_soc_bias_level_done: card=vscn-2046 component=(none) val=2 kworker/u8:4-215 [000] 1436.357437: snd_soc_bias_level_start: card=vscn-2046 component=ff56.codec val=1 kworker/u8:5-231 [000] 1436.357518: snd_soc_bias_level_start: card=vscn-2046 component=ff32.i2s val=1 kworker/u8:5-231 [000] 1436.357523: snd_soc_bias_level_done: card=vscn-2046 component=ff32.i2s val=1 kworker/u8:5-231 [000] 1436.357526: snd_soc_bias_level_start: card=vscn-2046 component=ff32.i2s val=2 kworker/u8:5-231 [000] 1436.357528: snd_soc_bias_level_done: card=vscn-2046 component=ff32.i2s val=2 kworker/u8:4-215 [000] 1436.383217: snd_soc_bias_level_done: card=vscn-2046 component=ff56.codec val=1 kworker/u8:4-215 [000] 1436.383221: snd_soc_bias_level_start: card=vscn-2046 component=ff56.codec val=2 kworker/u8:4-215 [000] 1436.383231: snd_soc_bias_level_done: card=vscn-2046 component=ff56.codec val=2 kworker/u8:5-231 [000] 1436.383468: snd_soc_bias_level_start: card=vscn-2046 component=ff32.i2s val=3 kworker/u8:5-231 [000] 1436.383472: snd_soc_bias_level_done: card=vscn-2046 component=ff32.i2s val=3 kworker/u8:4-215 [000] 1436.383503: snd_soc_bias_level_start: card=vscn-2046 component=ff56.codec val=3 kworker/u8:4-215 [000] 1436.383513: snd_soc_bias_level_done: card=vscn-2046 component=ff56.codec val=3 Signed-off-by: Luca Ceresoli --- include/trace/events/asoc.h | 29 - sound/soc/soc-dapm.c| 4 ++-- 2 files changed, 18 insertions(+), 15 deletions(-) diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h index 4d8ef71090af..b7ac7f100bb4 100644 --- a/include/trace/events/asoc.h +++ b/include/trace/events/asoc.h @@ -17,38 +17,41 @@ struct snd_soc_card; struct snd_soc_dapm_widget; struct snd_soc_dapm_path; -DECLARE_EVENT_CLASS(snd_soc_card, +DECLARE_EVENT_CLASS(snd_soc_dapm, - TP_PROTO(struct snd_soc_card *card, int val), + TP_PROTO(struct snd_soc_dapm_context *dapm, int val), - TP_ARGS(card, val), + TP_ARGS(dapm, val), TP_STRUCT__entry( - __string( name, card->name ) - __field(int,val ) + __string( card_name, dapm->card->name) + __string( comp_name, dapm->component ? dapm->component->name : "(none)") + __field(int,val) ), TP_fast_assign( - __assign_str(name, card->name); +
Re: [PATCH] ring-buffer: mark racy accesses on work->wait_index
On Wed, 6 Mar 2024 10:55:34 +0800 linke li wrote: > Mark data races to work->wait_index as benign using READ_ONCE and WRITE_ONCE. > These accesses are expected to be racy. Are we now to the point that every single access of a variable (long size or less) needs a READ_ONCE/WRITE_ONCE even with all the necessary smp_r/wmb()s? > > Signed-off-by: linke li > --- > kernel/trace/ring_buffer.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c > index 0699027b4f4c..a47e9e9750cc 100644 > --- a/kernel/trace/ring_buffer.c > +++ b/kernel/trace/ring_buffer.c > @@ -798,7 +798,7 @@ void ring_buffer_wake_waiters(struct trace_buffer > *buffer, int cpu) > rbwork = &cpu_buffer->irq_work; > } > > - rbwork->wait_index++; > + WRITE_ONCE(rbwork->wait_index, READ_ONCE(rbwork->wait_index) + 1); I mean the above is really ugly. If this is the new thing to do, we need better macros. If anything, just convert it to an atomic_t. -- Steve > /* make sure the waiters see the new index */ > smp_wmb(); > > @@ -906,7 +906,7 @@ int ring_buffer_wait(struct trace_buffer *buffer, int > cpu, int full) > > /* Make sure to see the new wait index */ > smp_rmb(); > - if (wait_index != work->wait_index) > + if (wait_index != READ_ONCE(work->wait_index)) > break; > } >
[PATCH v3 1/3] input: touchscreen: imagis: use FIELD_GET where applicable
Instead of manually extracting certain bits from registers with binary
ANDs and shifts, the FIELD_GET macro can be used. With this in mind, the
*_SHIFT macros can be dropped.
Signed-off-by: Duje Mihanović
---
drivers/input/touchscreen/imagis.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/input/touchscreen/imagis.c
b/drivers/input/touchscreen/imagis.c
index e1fafa561ee3..4eae98771bd2 100644
--- a/drivers/input/touchscreen/imagis.c
+++ b/drivers/input/touchscreen/imagis.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include
#include
#include
#include
@@ -29,12 +30,9 @@
#define IST3038C_I2C_RETRY_COUNT 3
#define IST3038C_MAX_FINGER_NUM10
#define IST3038C_X_MASKGENMASK(23, 12)
-#define IST3038C_X_SHIFT 12
#define IST3038C_Y_MASKGENMASK(11, 0)
#define IST3038C_AREA_MASK GENMASK(27, 24)
-#define IST3038C_AREA_SHIFT24
#define IST3038C_FINGER_COUNT_MASK GENMASK(15, 12)
-#define IST3038C_FINGER_COUNT_SHIFT12
#define IST3038C_FINGER_STATUS_MASKGENMASK(9, 0)
struct imagis_properties {
@@ -106,8 +104,7 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
goto out;
}
- finger_count = (intr_message & IST3038C_FINGER_COUNT_MASK) >>
- IST3038C_FINGER_COUNT_SHIFT;
+ finger_count = FIELD_GET(IST3038C_FINGER_COUNT_MASK, intr_message);
if (finger_count > IST3038C_MAX_FINGER_NUM) {
dev_err(&ts->client->dev,
"finger count %d is more than maximum supported\n",
@@ -115,7 +112,7 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
goto out;
}
- finger_pressed = intr_message & IST3038C_FINGER_STATUS_MASK;
+ finger_pressed = FIELD_GET(IST3038C_FINGER_STATUS_MASK, intr_message);
for (i = 0; i < finger_count; i++) {
if (ts->tdata->protocol_b)
@@ -136,12 +133,10 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
input_mt_report_slot_state(ts->input_dev, MT_TOOL_FINGER,
finger_pressed & BIT(i));
touchscreen_report_pos(ts->input_dev, &ts->prop,
- (finger_status & IST3038C_X_MASK) >>
- IST3038C_X_SHIFT,
- finger_status & IST3038C_Y_MASK, 1);
+ FIELD_GET(IST3038C_X_MASK,
finger_status),
+ FIELD_GET(IST3038C_Y_MASK,
finger_status), 1);
input_report_abs(ts->input_dev, ABS_MT_TOUCH_MAJOR,
-(finger_status & IST3038C_AREA_MASK) >>
- IST3038C_AREA_SHIFT);
+ FIELD_GET(IST3038C_AREA_MASK,
finger_status));
}
input_mt_sync_frame(ts->input_dev);
--
2.44.0
[PATCH v3 3/3] input: touchscreen: imagis: Add touch key support
IST3032C (and possibly some other models) has touch keys. Add support
for them to the imagis driver.
Signed-off-by: Duje Mihanović
---
drivers/input/touchscreen/imagis.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/imagis.c
b/drivers/input/touchscreen/imagis.c
index 4eae98771bd2..625d9287eabe 100644
--- a/drivers/input/touchscreen/imagis.c
+++ b/drivers/input/touchscreen/imagis.c
@@ -34,6 +34,7 @@
#define IST3038C_AREA_MASK GENMASK(27, 24)
#define IST3038C_FINGER_COUNT_MASK GENMASK(15, 12)
#define IST3038C_FINGER_STATUS_MASKGENMASK(9, 0)
+#define IST3032C_KEY_STATUS_MASK GENMASK(20, 16)
struct imagis_properties {
unsigned int interrupt_msg_cmd;
@@ -41,6 +42,7 @@ struct imagis_properties {
unsigned int whoami_cmd;
unsigned int whoami_val;
bool protocol_b;
+ bool touch_keys_supported;
};
struct imagis_ts {
@@ -49,6 +51,8 @@ struct imagis_ts {
struct input_dev *input_dev;
struct touchscreen_properties prop;
struct regulator_bulk_data supplies[2];
+ u32 keycodes[5];
+ int num_keycodes;
};
static int imagis_i2c_read_reg(struct imagis_ts *ts,
@@ -93,7 +97,7 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
{
struct imagis_ts *ts = dev_id;
u32 intr_message, finger_status;
- unsigned int finger_count, finger_pressed;
+ unsigned int finger_count, finger_pressed, key_pressed;
int i;
int error;
@@ -139,6 +143,11 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
FIELD_GET(IST3038C_AREA_MASK,
finger_status));
}
+ key_pressed = FIELD_GET(IST3032C_KEY_STATUS_MASK, intr_message);
+
+ for (int i = 0; i < ts->num_keycodes; i++)
+ input_report_key(ts->input_dev, ts->keycodes[i], (key_pressed &
BIT(i)));
+
input_mt_sync_frame(ts->input_dev);
input_sync(ts->input_dev);
@@ -224,6 +233,23 @@ static int imagis_init_input_dev(struct imagis_ts *ts)
input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_X);
input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_Y);
input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0, 16, 0, 0);
+ if (ts->tdata->touch_keys_supported) {
+ ts->num_keycodes = of_property_read_variable_u32_array(
+ ts->client->dev.of_node, "linux,keycodes",
+ ts->keycodes, 0, ARRAY_SIZE(ts->keycodes));
+ if (ts->num_keycodes <= 0) {
+ ts->keycodes[0] = KEY_APPSELECT;
+ ts->keycodes[1] = KEY_BACK;
+ ts->num_keycodes = 2;
+ }
+
+ input_dev->keycodemax = ts->num_keycodes;
+ input_dev->keycodesize = sizeof(ts->keycodes[0]);
+ input_dev->keycode = ts->keycodes;
+ }
+
+ for (int i = 0; i < ts->num_keycodes; i++)
+ input_set_capability(input_dev, EV_KEY, ts->keycodes[i]);
touchscreen_parse_properties(input_dev, true, &ts->prop);
if (!ts->prop.max_x || !ts->prop.max_y) {
@@ -365,6 +391,7 @@ static const struct imagis_properties imagis_3032c_data = {
.touch_coord_cmd = IST3038C_REG_TOUCH_COORD,
.whoami_cmd = IST3038C_REG_CHIPID,
.whoami_val = IST3032C_WHOAMI,
+ .touch_keys_supported = true,
};
static const struct imagis_properties imagis_3038b_data = {
--
2.44.0
[PATCH v3 0/3] Imagis touch keys and FIELD_GET cleanup
Tiny series to clean up the field extraction and add touch key support.
This version is based on the next branch of Dmitry's input tree.
Signed-off-by: Duje Mihanović
---
Changes in v3:
- Rebase on input/next
- Add changelog to binding patch
- Fix binding constraint
- Allow changing keycodes in userspace as in 872e57abd171 ("Input:
tm2-touchkey - allow changing keycodes from userspace")
- Allow up to 5 keycodes (the key status field has 5 bits)
- Link to v2:
https://lore.kernel.org/r/20240120-b4-imagis-keys-v2-0-d7fc16f2e...@skole.hr
Changes in v2:
- Fix compile error
- Add FIELD_GET patch
- Allow specifying custom keycodes
- Link to v1:
https://lore.kernel.org/20231112194124.24916-1-duje.mihano...@skole.hr
---
Duje Mihanović (3):
input: touchscreen: imagis: use FIELD_GET where applicable
dt-bindings: input: imagis: Document touch keys
input: touchscreen: imagis: Add touch key support
.../input/touchscreen/imagis,ist3038c.yaml | 19 +++--
drivers/input/touchscreen/imagis.c | 46 --
2 files changed, 50 insertions(+), 15 deletions(-)
---
base-commit: b0f3f9ab419c243389da6c0dd6a9db0eea560146
change-id: 20240120-b4-imagis-keys-a0a9f2b31740
Best regards,
--
Duje Mihanović
[PATCH v3 2/3] dt-bindings: input: imagis: Document touch keys
IST3032C (and possibly some other models) has touch keys. Document this. Signed-off-by: Duje Mihanović --- Changes in v3: - Move allOf under additionalProperties and move if under allOf - Properly define linux,keycodes - Fix linux,keycodes constraint - Change maximum number of keycodes to 5 in accordance with the size of the key status field Changes in v2: - Allow specifying custom keycodes and document this in binding --- .../bindings/input/touchscreen/imagis,ist3038c.yaml | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml index 2af71cbcc97d..77ba280b3bdc 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml @@ -9,9 +9,6 @@ title: Imagis IST30XXC family touchscreen controller maintainers: - Markuss Broks -allOf: - - $ref: touchscreen.yaml# - properties: $nodename: pattern: "^touchscreen@[0-9a-f]+$" @@ -34,6 +31,10 @@ properties: vddio-supply: description: Power supply regulator for the I2C bus + linux,keycodes: +description: Keycodes for the touch keys +maxItems: 5 + touchscreen-size-x: true touchscreen-size-y: true touchscreen-fuzz-x: true @@ -44,6 +45,18 @@ properties: additionalProperties: false +allOf: + - $ref: touchscreen.yaml# + - if: + not: +properties: + compatible: +contains: + const: imagis,ist3032c +then: + properties: +linux,keycodes: false + required: - compatible - reg -- 2.44.0
Re: [PATCH 0/2] ASoC: trace: trace more parameters in ASoC DAPM events
On Wed, 06 Mar 2024 10:29:59 +0100, Luca Ceresoli wrote: > This small series adds parameters to existing DAPM trace events to make > them more informative. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: trace: add component to set_bias_level trace events commit: 6ef46a69ec32fe1cf56de67742fcd01af4bf48af [2/2] ASoC: trace: add event to snd_soc_dapm trace events commit: 7df3eb4cdb6bbfa482f51548b9fd47c2723c68ba All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2] tracing: Limit trace_marker writes to just 4K
On Mon, 4 Mar 2024 22:34:33 -0500
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Limit the max print event of trace_marker to just 4K string size. This must
> also be less than the amount that can be held by a trace_seq along with
> the text that is before the output (like the task name, PID, CPU, state,
> etc). As trace_seq is made to handle large events (some greater than 4K).
> Make the max size of a trace_marker write event be 4K which is guaranteed
> to fit in the trace_seq buffer.
>
> Suggested-by: Mathieu Desnoyers
> Signed-off-by: Steven Rostedt (Google)
This looks good to me.
Reviewed-by: Masami Hiramatsu (Google)
Thank you,
> ---
> Changes since v1:
> https://lore.kernel.org/linux-trace-kernel/20240304192710.4c996...@gandalf.local.home/
>
> - Just make the max limit 4K and not half of the trace_seq size.
> The trace_seq is already made to handle events greater than 4k.
>
> kernel/trace/trace.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8198bfc54b58..d16b95ca58a7 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -7293,6 +7293,8 @@ tracing_free_buffer_release(struct inode *inode, struct
> file *filp)
> return 0;
> }
>
> +#define TRACE_MARKER_MAX_SIZE4096
> +
> static ssize_t
> tracing_mark_write(struct file *filp, const char __user *ubuf,
> size_t cnt, loff_t *fpos)
> @@ -7320,6 +7322,9 @@ tracing_mark_write(struct file *filp, const char __user
> *ubuf,
> if ((ssize_t)cnt < 0)
> return -EINVAL;
>
> + if (cnt > TRACE_MARKER_MAX_SIZE)
> + cnt = TRACE_MARKER_MAX_SIZE;
> +
> meta_size = sizeof(*entry) + 2; /* add '\0' and possible '\n' */
> again:
> size = cnt + meta_size;
> @@ -7328,11 +7333,6 @@ tracing_mark_write(struct file *filp, const char
> __user *ubuf,
> if (cnt < FAULTED_SIZE)
> size += FAULTED_SIZE - cnt;
>
> - if (size > TRACE_SEQ_BUFFER_SIZE) {
> - cnt -= size - TRACE_SEQ_BUFFER_SIZE;
> - goto again;
> - }
> -
> buffer = tr->array_buffer.buffer;
> event = __trace_buffer_lock_reserve(buffer, TRACE_PRINT, size,
> tracing_gen_ctx());
> --
> 2.43.0
>
--
Masami Hiramatsu (Google)
Re: [PATCH 3/5] ARM: dts: qcom: msm8974pro-castor: Remove camera button definitions
On 3/6/24 00:18, Luca Weiss wrote:
From what I can tell, the camera buttons are not part of Z2 Tablet
hardware even though other devices based on 'shinano' do have them.
Fixes: ab80661883de ("ARM: dts: qcom: msm8974: Add Sony Xperia Z2 Tablet")
Signed-off-by: Luca Weiss
---
https://3dmodels.org/360-view/?id=82800
Doesn't look like!
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH 1/5] ARM: dts: qcom: msm8974pro-castor: Clean up formatting
On 3/6/24 00:18, Luca Weiss wrote: Clean up some easy things do prepare the dts for further changes. * Move pinctrl-names below pinctrl-* * Move status as last property * Remove default linux,input-type value Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
[RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V. This allows each ftrace callsite to provide an ftrace_ops to the common ftrace trampoline, allowing each callsite to invoke distinct tracer functions without the need to fall back to list processing or to allocate custom trampolines for each callsite. This significantly speeds up cases where multiple distinct trace functions are used and callsites are mostly traced by a single tracer. The idea and most of the implementation is taken from the ARM64's implementation of the same feature. The idea is to place a pointer to the ftrace_ops as a literal at a fixed offset from the function entry point, which can be recovered by the common ftrace trampoline. We use -fpatchable-function-entry to reserve 8 bytes above the function entry by emitting 2 4 byte or 4 2 byte nops depending on the presence of CONFIG_RISCV_ISA_C. These 8 bytes are patched at runtime with a pointer to the associated ftrace_ops for that callsite. Functions are aligned to 8 bytes to make sure that the accesses to this literal are atomic. This approach allows for directly invoking ftrace_ops::func even for ftrace_ops which are dynamically-allocated (or part of a module), without going via ftrace_ops_list_func. I've benchamrked this with the ftrace_ops sample module on Qemu, with the next version, I will provide benchmarks on real hardware: Without this patch: +---+-++ | Number of tracers| Total time (ns) | Per-call average time | |---+-+| | Relevant | Irrelevant |10 calls | Total (ns) | Overhead (ns) | |--++-++---| |0 | 0 |15615700 |156 | - | |0 | 1 |15917600 |159 | - | |0 | 2 |15668000 |156 | - | |0 | 10 |14971500 |149 | - | |0 |100 |15417600 |154 | - | |0 |200 |15387000 |153 | - | |--++-++---| |1 | 0 | 119906800 | 1199 | 1043 | |1 | 1 | 137428600 | 1374 | 1218 | |1 | 2 | 159562400 | 1374 | 1218 | |1 | 10 | 302099900 | 3020 | 2864 | |1 |100 | 2008785500 | 20087 | 19931 | |1 |200 | 3965221900 | 39652 | 39496 | |--++-++---| |1 | 0 | 119166700 | 1191 | 1035 | |2 | 0 | 15700 | 1579 | 1423 | | 10 | 0 | 425370100 | 4253 | 4097 | | 100 | 0 | 3595252100 | 35952 | 35796 | | 200 | 0 | 7023485700 | 70234 | 70078 | +--++-++---+ Note: per-call overhead is estimated relative to the baseline case with 0 relevant tracers and 0 irrelevant tracers. With this patch: +---+-++ | Number of tracers | Total time (ns) | Per-call average time | |---+-+| | Relevant | Irrelevant |10 calls | Total (ns) | Overhead (ns) | |--++-++---| |0 | 0 |15254600 |152 | - | |0 | 1 |16136700 |161 | - | |0 | 2 |15329500 |153 | - | |0 | 10 |15148800 |151 | - | |0 |100 |15746900 |157 | - | |0 |200 |15737400 |157 | - | |--++-++---| |1 | 0 |47909000 |479 | 327 | |1 | 1 |48297400 |482 | 330 | |1 | 2 |47314100 |473 | 321 | |1 | 10 |47844900 |478 | 326 | |1 |100 |46591900 |465 | 313 | |1 |200 |47178900 |471 | 319 | |--++-++---| |1 | 0 |46715800 |467 | 315 | |2 | 0 | 155134500 | 1551 | 1399 | | 10 | 0 | 442672800 | 4426 | 4274 | | 100 |
[RFC][PATCH 0/4] Make bpf_jit and kprobes work with CONFIG_MODULES=n
Hello all, This patchset makes it possible to use bpftrace with kprobes on kernels built without loadable module support. On a Raspberry Pi 4b, this saves about 700KB of memory where BPF is needed but loadable module support is not. These two kernels had identical configurations, except CONFIG_MODULE was off in the second: - Linux version 6.8.0-rc7 - Memory: 3330672K/4050944K available (16576K kernel code, 2390K rwdata, - 12364K rodata, 5632K init, 675K bss, 195984K reserved, 524288K cma-reserved) + Linux version 6.8.0-rc7-3-g2af01251ca21 + Memory: 3331400K/4050944K available (16512K kernel code, 2384K rwdata, + 11728K rodata, 5632K init, 673K bss, 195256K reserved, 524288K cma-reserved) I don't intend to present an exhaustive list of !MODULES usecases, since I'm sure there are many I'm not aware of. Performance is a common one, the primary justification being that static text is mapped on hugepages and module text is not. Security is another, since rootkits are much harder to implement without modules. The first patch is the interesting one: it moves module_alloc() into its own file with its own Kconfig option, so it can be utilized even when loadable module support is disabled. I got the idea from an unmerged patch from a few years ago I found on lkml (see [1/4] for details). I think this also has value in its own right, since I suspect there are potential users beyond bpf, hopefully we will hear from some. Patches 2-3 are proofs of concept to demonstrate the first patch is sufficient to achieve my goal (full ebpf functionality without modules). Patch 4 adds a new "-n" argument to vmtest.sh to run the BPF selftests without modules, so the prior three patches can be rigorously tested. If something like the first patch were to eventually be merged, the rest could go through the normal bpf-next process as I clean them up: I've only based them on Linus' tree and combined them into a series here to introduce the idea. If you prefer to fetch the patches via git: [1/4] https://github.com/jcalvinowens/linux.git work/module-alloc +[2/4]+[3/4] https://github.com/jcalvinowens/linux.git work/nomodule-bpf +[4/4] https://github.com/jcalvinowens/linux.git testing/nomodule-bpf-ci In addition to the automated BPF selftests, I've lightly tested this on my laptop (x86_64), a Raspberry Pi 4b (arm64), and a Raspberry Pi Zero W (arm). The other architectures have only been compile tested. I didn't want to spam all the arch maintainers with what I expect will be a discussion mostly about modules and bpf, so I've left them off this first submission. I will be sure to add them on future submissions of the first patch. Of course, feedback on the arch bits is welcome here. In addition to feedback on the patches themselves, I'm interested in hearing from anybody else who might find this functionality useful. Thanks, Calvin Calvin Owens (4): module: mm: Make module_alloc() generally available bpf: Allow BPF_JIT with CONFIG_MODULES=n kprobes: Allow kprobes with CONFIG_MODULES=n selftests/bpf: Support testing the !MODULES case arch/Kconfig | 4 +- arch/arm/kernel/module.c | 35 - arch/arm/mm/Makefile | 2 + arch/arm/mm/module_alloc.c| 40 ++ arch/arm64/kernel/module.c| 127 - arch/arm64/mm/Makefile| 1 + arch/arm64/mm/module_alloc.c | 130 ++ arch/loongarch/kernel/module.c| 6 - arch/loongarch/mm/Makefile| 2 + arch/loongarch/mm/module_alloc.c | 10 ++ arch/mips/kernel/module.c | 10 -- arch/mips/mm/Makefile | 2 + arch/mips/mm/module_alloc.c | 13 ++ arch/nios2/kernel/module.c| 20 --- arch/nios2/mm/Makefile| 2 + arch/nios2/mm/module_alloc.c | 22 +++ arch/parisc/kernel/module.c | 12 -- arch/parisc/mm/Makefile | 1 + arch/parisc/mm/module_alloc.c | 15 ++ arch/powerpc/kernel/module.c | 36 - arch/powerpc/mm/Makefile | 1 + arch/powerpc/mm/module_alloc.c| 41 ++ arch/riscv/kernel/module.c| 11 -- arch/riscv/mm/Makefile| 1 + arch/riscv/mm/module_alloc.c | 17 +++ arch/s390/kernel/module.c | 37 - arch/s390/mm/Makefile | 1 + arch/s390/mm/module_alloc.c | 42 ++ arch/sparc/kernel/module.c| 31 - arch/sparc/mm/Makefile| 2 + arch/sparc/mm/module_alloc.c | 31 + arch/x86/kernel/ftrace.c | 2 +- arch/x86/kernel/module.c |
[RFC][PATCH 2/4] bpf: Allow BPF_JIT with CONFIG_MODULES=n
No BPF code has to change, except in struct_ops (for module refs).
This conflicts with bpf-next because of this (relevant) series:
https://lore.kernel.org/all/20240119225005.668602-1-thinker...@gmail.com/
If something like this is merged down the road, it can go through
bpf-next at leisure once the module_alloc change is in: it's a one-way
dependency.
Signed-off-by: Calvin Owens
---
kernel/bpf/Kconfig | 2 +-
kernel/bpf/bpf_struct_ops.c | 28
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
index 6a906ff93006..77df483a8925 100644
--- a/kernel/bpf/Kconfig
+++ b/kernel/bpf/Kconfig
@@ -42,7 +42,7 @@ config BPF_JIT
bool "Enable BPF Just In Time compiler"
depends on BPF
depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
- depends on MODULES
+ select MODULE_ALLOC
help
BPF programs are normally handled by a BPF interpreter. This option
allows the kernel to generate native code when a program is loaded
diff --git a/kernel/bpf/bpf_struct_ops.c b/kernel/bpf/bpf_struct_ops.c
index 02068bd0e4d9..fbf08a1bb00c 100644
--- a/kernel/bpf/bpf_struct_ops.c
+++ b/kernel/bpf/bpf_struct_ops.c
@@ -108,11 +108,30 @@ const struct bpf_prog_ops bpf_struct_ops_prog_ops = {
#endif
};
+#if IS_ENABLED(CONFIG_MODULES)
static const struct btf_type *module_type;
+static int bpf_struct_module_type_init(struct btf *btf)
+{
+ s32 module_id;
+
+ module_id = btf_find_by_name_kind(btf, "module", BTF_KIND_STRUCT);
+ if (module_id < 0)
+ return 1;
+
+ module_type = btf_type_by_id(btf, module_id);
+ return 0;
+}
+#else
+static int bpf_struct_module_type_init(struct btf *btf)
+{
+ return 0;
+}
+#endif
+
void bpf_struct_ops_init(struct btf *btf, struct bpf_verifier_log *log)
{
- s32 type_id, value_id, module_id;
+ s32 type_id, value_id;
const struct btf_member *member;
struct bpf_struct_ops *st_ops;
const struct btf_type *t;
@@ -125,12 +144,10 @@ void bpf_struct_ops_init(struct btf *btf, struct
bpf_verifier_log *log)
#include "bpf_struct_ops_types.h"
#undef BPF_STRUCT_OPS_TYPE
- module_id = btf_find_by_name_kind(btf, "module", BTF_KIND_STRUCT);
- if (module_id < 0) {
+ if (bpf_struct_module_type_init(btf)) {
pr_warn("Cannot find struct module in btf_vmlinux\n");
return;
}
- module_type = btf_type_by_id(btf, module_id);
for (i = 0; i < ARRAY_SIZE(bpf_struct_ops); i++) {
st_ops = bpf_struct_ops[i];
@@ -433,12 +450,15 @@ static long bpf_struct_ops_map_update_elem(struct bpf_map
*map, void *key,
moff = __btf_member_bit_offset(t, member) / 8;
ptype = btf_type_resolve_ptr(btf_vmlinux, member->type, NULL);
+
+#if IS_ENABLED(CONFIG_MODULES)
if (ptype == module_type) {
if (*(void **)(udata + moff))
goto reset_unlock;
*(void **)(kdata + moff) = BPF_MODULE_OWNER;
continue;
}
+#endif
err = st_ops->init_member(t, member, kdata, udata);
if (err < 0)
--
2.43.0
[RFC][PATCH 1/4] module: mm: Make module_alloc() generally available
Both BPF_JIT and KPROBES depend on CONFIG_MODULES, but only require
module_alloc() itself, which can be easily separated into a standalone
allocator for executable kernel memory.
Thomas Gleixner sent a patch to do that for x86 as part of a larger
series a couple years ago:
https://lore.kernel.org/all/20220716230953.442937...@linutronix.de/
I've simply extended that approach to the whole kernel.
Signed-off-by: Calvin Owens
---
arch/Kconfig | 2 +-
arch/arm/kernel/module.c | 35 -
arch/arm/mm/Makefile | 2 +
arch/arm/mm/module_alloc.c | 40 ++
arch/arm64/kernel/module.c | 127 --
arch/arm64/mm/Makefile | 1 +
arch/arm64/mm/module_alloc.c | 130 +++
arch/loongarch/kernel/module.c | 6 --
arch/loongarch/mm/Makefile | 2 +
arch/loongarch/mm/module_alloc.c | 10 +++
arch/mips/kernel/module.c| 10 ---
arch/mips/mm/Makefile| 2 +
arch/mips/mm/module_alloc.c | 13
arch/nios2/kernel/module.c | 20 -
arch/nios2/mm/Makefile | 2 +
arch/nios2/mm/module_alloc.c | 22 ++
arch/parisc/kernel/module.c | 12 ---
arch/parisc/mm/Makefile | 1 +
arch/parisc/mm/module_alloc.c| 15
arch/powerpc/kernel/module.c | 36 -
arch/powerpc/mm/Makefile | 1 +
arch/powerpc/mm/module_alloc.c | 41 ++
arch/riscv/kernel/module.c | 11 ---
arch/riscv/mm/Makefile | 1 +
arch/riscv/mm/module_alloc.c | 17
arch/s390/kernel/module.c| 37 -
arch/s390/mm/Makefile| 1 +
arch/s390/mm/module_alloc.c | 42 ++
arch/sparc/kernel/module.c | 31
arch/sparc/mm/Makefile | 2 +
arch/sparc/mm/module_alloc.c | 31
arch/x86/kernel/ftrace.c | 2 +-
arch/x86/kernel/module.c | 56 -
arch/x86/mm/Makefile | 2 +
arch/x86/mm/module_alloc.c | 59 ++
fs/proc/kcore.c | 2 +-
kernel/module/Kconfig| 1 +
kernel/module/main.c | 17
mm/Kconfig | 3 +
mm/Makefile | 1 +
mm/module_alloc.c| 21 +
mm/vmalloc.c | 2 +-
42 files changed, 467 insertions(+), 402 deletions(-)
create mode 100644 arch/arm/mm/module_alloc.c
create mode 100644 arch/arm64/mm/module_alloc.c
create mode 100644 arch/loongarch/mm/module_alloc.c
create mode 100644 arch/mips/mm/module_alloc.c
create mode 100644 arch/nios2/mm/module_alloc.c
create mode 100644 arch/parisc/mm/module_alloc.c
create mode 100644 arch/powerpc/mm/module_alloc.c
create mode 100644 arch/riscv/mm/module_alloc.c
create mode 100644 arch/s390/mm/module_alloc.c
create mode 100644 arch/sparc/mm/module_alloc.c
create mode 100644 arch/x86/mm/module_alloc.c
create mode 100644 mm/module_alloc.c
diff --git a/arch/Kconfig b/arch/Kconfig
index a5af0edd3eb8..cfc24ced16dd 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1305,7 +1305,7 @@ config ARCH_HAS_STRICT_MODULE_RWX
config STRICT_MODULE_RWX
bool "Set loadable kernel module data as NX and text as RO" if
ARCH_OPTIONAL_KERNEL_RWX
- depends on ARCH_HAS_STRICT_MODULE_RWX && MODULES
+ depends on ARCH_HAS_STRICT_MODULE_RWX && MODULE_ALLOC
default !ARCH_OPTIONAL_KERNEL_RWX || ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
help
If this is set, module text and rodata memory will be made read-only,
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index e74d84f58b77..1c8798732d12 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -4,15 +4,12 @@
*
* Copyright (C) 2002 Russell King.
* Modified for nommu by Hyok S. Choi
- *
- * Module allocation method suggested by Andi Kleen.
*/
#include
#include
#include
#include
#include
-#include
#include
#include
#include
@@ -22,38 +19,6 @@
#include
#include
-#ifdef CONFIG_XIP_KERNEL
-/*
- * The XIP kernel text is mapped in the module area for modules and
- * some other stuff to work without any indirect relocations.
- * MODULES_VADDR is redefined here and not in asm/memory.h to avoid
- * recompiling the whole kernel when CONFIG_XIP_KERNEL is turned on/off.
- */
-#undef MODULES_VADDR
-#define MODULES_VADDR (((unsigned long)_exiprom + ~PMD_MASK) & PMD_MASK)
-#endif
-
-#ifdef CONFIG_MMU
-void *module_alloc(unsigned long size)
-{
- gfp_t gfp_mask = GFP_KERNEL;
- void *p;
-
- /* Silence the initial allocation */
- if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS))
- gfp_mask |= __GFP_NOWARN;
-
- p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
- gfp_mask, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
- __builtin_return_address(0));
- if (!IS_ENABLED(CONFIG_A
[RFC][PATCH 3/4] kprobes: Allow kprobes with CONFIG_MODULES=n
If something like this is merged down the road, it can go in at leisure
once the module_alloc change is in: it's a one-way dependency.
Signed-off-by: Calvin Owens
---
arch/Kconfig| 2 +-
kernel/kprobes.c| 22 ++
kernel/trace/trace_kprobe.c | 11 +++
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index cfc24ced16dd..e60ce984d095 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -52,8 +52,8 @@ config GENERIC_ENTRY
config KPROBES
bool "Kprobes"
- depends on MODULES
depends on HAVE_KPROBES
+ select MODULE_ALLOC
select KALLSYMS
select TASKS_RCU if PREEMPTION
help
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 9d9095e81792..194270e17d57 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1556,8 +1556,12 @@ static bool is_cfi_preamble_symbol(unsigned long addr)
str_has_prefix("__pfx_", symbuf);
}
+#if IS_ENABLED(CONFIG_MODULES)
static int check_kprobe_address_safe(struct kprobe *p,
struct module **probed_mod)
+#else
+static int check_kprobe_address_safe(struct kprobe *p)
+#endif
{
int ret;
@@ -1580,6 +1584,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
goto out;
}
+#if IS_ENABLED(CONFIG_MODULES)
/* Check if 'p' is probing a module. */
*probed_mod = __module_text_address((unsigned long) p->addr);
if (*probed_mod) {
@@ -1603,6 +1608,8 @@ static int check_kprobe_address_safe(struct kprobe *p,
ret = -ENOENT;
}
}
+#endif
+
out:
preempt_enable();
jump_label_unlock();
@@ -1614,7 +1621,9 @@ int register_kprobe(struct kprobe *p)
{
int ret;
struct kprobe *old_p;
+#if IS_ENABLED(CONFIG_MODULES)
struct module *probed_mod;
+#endif
kprobe_opcode_t *addr;
bool on_func_entry;
@@ -1633,7 +1642,11 @@ int register_kprobe(struct kprobe *p)
p->nmissed = 0;
INIT_LIST_HEAD(&p->list);
+#if IS_ENABLED(CONFIG_MODULES)
ret = check_kprobe_address_safe(p, &probed_mod);
+#else
+ ret = check_kprobe_address_safe(p);
+#endif
if (ret)
return ret;
@@ -1676,8 +1689,10 @@ int register_kprobe(struct kprobe *p)
out:
mutex_unlock(&kprobe_mutex);
+#if IS_ENABLED(CONFIG_MODULES)
if (probed_mod)
module_put(probed_mod);
+#endif
return ret;
}
@@ -2482,6 +2497,7 @@ int kprobe_add_area_blacklist(unsigned long start,
unsigned long end)
return 0;
}
+#if IS_ENABLED(CONFIG_MODULES)
/* Remove all symbols in given area from kprobe blacklist */
static void kprobe_remove_area_blacklist(unsigned long start, unsigned long
end)
{
@@ -2499,6 +2515,7 @@ static void kprobe_remove_ksym_blacklist(unsigned long
entry)
{
kprobe_remove_area_blacklist(entry, entry + 1);
}
+#endif
int __weak arch_kprobe_get_kallsym(unsigned int *symnum, unsigned long *value,
char *type, char *sym)
@@ -2564,6 +2581,7 @@ static int __init populate_kprobe_blacklist(unsigned long
*start,
return ret ? : arch_populate_kprobe_blacklist();
}
+#if IS_ENABLED(CONFIG_MODULES)
static void add_module_kprobe_blacklist(struct module *mod)
{
unsigned long start, end;
@@ -2665,6 +2683,7 @@ static struct notifier_block kprobe_module_nb = {
.notifier_call = kprobes_module_callback,
.priority = 0
};
+#endif /* IS_ENABLED(CONFIG_MODULES) */
void kprobe_free_init_mem(void)
{
@@ -2724,8 +2743,11 @@ static int __init init_kprobes(void)
err = arch_init_kprobes();
if (!err)
err = register_die_notifier(&kprobe_exceptions_nb);
+
+#if IS_ENABLED(CONFIG_MODULES)
if (!err)
err = register_module_notifier(&kprobe_module_nb);
+#endif
kprobes_initialized = (err == 0);
kprobe_sysctls_init();
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index c4c6e0e0068b..dd4598f775b9 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -102,6 +102,7 @@ static nokprobe_inline bool trace_kprobe_has_gone(struct
trace_kprobe *tk)
return kprobe_gone(&tk->rp.kp);
}
+#if IS_ENABLED(CONFIG_MODULES)
static nokprobe_inline bool trace_kprobe_within_module(struct trace_kprobe *tk,
struct module *mod)
{
@@ -129,6 +130,12 @@ static nokprobe_inline bool
trace_kprobe_module_exist(struct trace_kprobe *tk)
return ret;
}
+#else
+static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
+{
+ return true;
+}
+#endif
static bool trace_kprobe_is_busy(struct dyn_event *ev)
{
@@ -670,6 +677,7 @@ static int register_trace_kprobe(struct trace_kprobe *tk)
return ret;
}
+#if IS_ENABLED(CONFIG_MODULES)
/* Module notifier call bac
[RFC][PATCH 4/4] selftests/bpf: Support testing the !MODULES case
This symlinks bpf_testmod into the main source, so it can be built-in for running selftests in the new !MODULES case. To be clear, no changes to the existing selftests are required: this only exists to enable testing the new case which was not previously possible. I'm sure somebody will be able to suggest a less ugly way I can do this... Signed-off-by: Calvin Owens --- include/trace/events/bpf_testmod.h| 1 + kernel/bpf/Kconfig| 9 ++ kernel/bpf/Makefile | 2 ++ kernel/bpf/bpf_testmod/Makefile | 1 + kernel/bpf/bpf_testmod/bpf_testmod.c | 1 + kernel/bpf/bpf_testmod/bpf_testmod.h | 1 + kernel/bpf/bpf_testmod/bpf_testmod_kfunc.h| 1 + net/bpf/test_run.c| 2 ++ tools/testing/selftests/bpf/Makefile | 28 +-- .../selftests/bpf/bpf_testmod/Makefile| 2 +- .../bpf/bpf_testmod/bpf_testmod-events.h | 6 .../selftests/bpf/bpf_testmod/bpf_testmod.c | 4 +++ .../bpf/bpf_testmod/bpf_testmod_kfunc.h | 2 ++ tools/testing/selftests/bpf/config| 5 tools/testing/selftests/bpf/config.mods | 5 tools/testing/selftests/bpf/config.nomods | 1 + .../selftests/bpf/progs/btf_type_tag_percpu.c | 2 ++ .../selftests/bpf/progs/btf_type_tag_user.c | 2 ++ tools/testing/selftests/bpf/progs/core_kern.c | 2 ++ .../selftests/bpf/progs/iters_testmod_seq.c | 2 ++ .../bpf/progs/test_core_reloc_module.c| 2 ++ .../selftests/bpf/progs/test_ldsx_insn.c | 2 ++ .../selftests/bpf/progs/test_module_attach.c | 3 ++ .../selftests/bpf/progs/tracing_struct.c | 2 ++ tools/testing/selftests/bpf/testing_helpers.c | 14 ++ tools/testing/selftests/bpf/vmtest.sh | 24 ++-- 26 files changed, 110 insertions(+), 16 deletions(-) create mode 12 include/trace/events/bpf_testmod.h create mode 100644 kernel/bpf/bpf_testmod/Makefile create mode 12 kernel/bpf/bpf_testmod/bpf_testmod.c create mode 12 kernel/bpf/bpf_testmod/bpf_testmod.h create mode 12 kernel/bpf/bpf_testmod/bpf_testmod_kfunc.h create mode 100644 tools/testing/selftests/bpf/config.mods create mode 100644 tools/testing/selftests/bpf/config.nomods diff --git a/include/trace/events/bpf_testmod.h b/include/trace/events/bpf_testmod.h new file mode 12 index ..ae237a90d381 --- /dev/null +++ b/include/trace/events/bpf_testmod.h @@ -0,0 +1 @@ +../../../tools/testing/selftests/bpf/bpf_testmod/bpf_testmod-events.h \ No newline at end of file diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig index 77df483a8925..d5ba795182e5 100644 --- a/kernel/bpf/Kconfig +++ b/kernel/bpf/Kconfig @@ -100,4 +100,13 @@ config BPF_LSM If you are unsure how to answer this question, answer N. +config BPF_TEST_MODULE + bool "Build the module for BPF selftests as a built-in" + depends on BPF_SYSCALL + depends on BPF_JIT + depends on !MODULES + default n + help + This allows most of the bpf selftests to run without modules. + endmenu # "BPF subsystem" diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile index f526b7573e97..04b3e50ff940 100644 --- a/kernel/bpf/Makefile +++ b/kernel/bpf/Makefile @@ -46,3 +46,5 @@ obj-$(CONFIG_BPF_PRELOAD) += preload/ obj-$(CONFIG_BPF_SYSCALL) += relo_core.o $(obj)/relo_core.o: $(srctree)/tools/lib/bpf/relo_core.c FORCE $(call if_changed_rule,cc_o_c) + +obj-$(CONFIG_BPF_TEST_MODULE) += bpf_testmod/ diff --git a/kernel/bpf/bpf_testmod/Makefile b/kernel/bpf/bpf_testmod/Makefile new file mode 100644 index ..55a73fd8443e --- /dev/null +++ b/kernel/bpf/bpf_testmod/Makefile @@ -0,0 +1 @@ +obj-y += bpf_testmod.o diff --git a/kernel/bpf/bpf_testmod/bpf_testmod.c b/kernel/bpf/bpf_testmod/bpf_testmod.c new file mode 12 index ..ca3baca5d9c4 --- /dev/null +++ b/kernel/bpf/bpf_testmod/bpf_testmod.c @@ -0,0 +1 @@ +../../../tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c \ No newline at end of file diff --git a/kernel/bpf/bpf_testmod/bpf_testmod.h b/kernel/bpf/bpf_testmod/bpf_testmod.h new file mode 12 index ..f8d3df98b6a5 --- /dev/null +++ b/kernel/bpf/bpf_testmod/bpf_testmod.h @@ -0,0 +1 @@ +../../../tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.h \ No newline at end of file diff --git a/kernel/bpf/bpf_testmod/bpf_testmod_kfunc.h b/kernel/bpf/bpf_testmod/bpf_testmod_kfunc.h new file mode 12 index ..fdf42f5eaeb0 --- /dev/null +++ b/kernel/bpf/bpf_testmod/bpf_testmod_kfunc.h @@ -0,0 +1 @@ +../../../tools/testing/selftests/bpf/bpf_testmod/bpf_testmod_kfunc.h \ No newline at end of file diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c index dfd919374017..33029c91bf92 100644 --- a/net/bpf/test_run.c +++ b/net/bpf/test_run.c @@ -573,10 +573,12 @@ __bpf_kfunc int bpf_modify_return_test2(int a, int *b, short c, int d, return a + *b +
Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
Hi Puranjay, On 06/03/2024 17:59, Puranjay Mohan wrote: This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V. This allows each ftrace callsite to provide an ftrace_ops to the common ftrace trampoline, allowing each callsite to invoke distinct tracer functions without the need to fall back to list processing or to allocate custom trampolines for each callsite. This significantly speeds up cases where multiple distinct trace functions are used and callsites are mostly traced by a single tracer. The idea and most of the implementation is taken from the ARM64's implementation of the same feature. The idea is to place a pointer to the ftrace_ops as a literal at a fixed offset from the function entry point, which can be recovered by the common ftrace trampoline. We use -fpatchable-function-entry to reserve 8 bytes above the function entry by emitting 2 4 byte or 4 2 byte nops depending on the presence of CONFIG_RISCV_ISA_C. These 8 bytes are patched at runtime with a pointer to the associated ftrace_ops for that callsite. Functions are aligned to 8 bytes to make sure that the accesses to this literal are atomic. This approach allows for directly invoking ftrace_ops::func even for ftrace_ops which are dynamically-allocated (or part of a module), without going via ftrace_ops_list_func. I've benchamrked this with the ftrace_ops sample module on Qemu, with the next version, I will provide benchmarks on real hardware: Without this patch: +---+-++ | Number of tracers| Total time (ns) | Per-call average time | |---+-+| | Relevant | Irrelevant |10 calls | Total (ns) | Overhead (ns) | |--++-++---| |0 | 0 |15615700 |156 | - | |0 | 1 |15917600 |159 | - | |0 | 2 |15668000 |156 | - | |0 | 10 |14971500 |149 | - | |0 |100 |15417600 |154 | - | |0 |200 |15387000 |153 | - | |--++-++---| |1 | 0 | 119906800 | 1199 | 1043 | |1 | 1 | 137428600 | 1374 | 1218 | |1 | 2 | 159562400 | 1374 | 1218 | |1 | 10 | 302099900 | 3020 | 2864 | |1 |100 | 2008785500 | 20087 | 19931 | |1 |200 | 3965221900 | 39652 | 39496 | |--++-++---| |1 | 0 | 119166700 | 1191 | 1035 | |2 | 0 | 15700 | 1579 | 1423 | | 10 | 0 | 425370100 | 4253 | 4097 | | 100 | 0 | 3595252100 | 35952 | 35796 | | 200 | 0 | 7023485700 | 70234 | 70078 | +--++-++---+ Note: per-call overhead is estimated relative to the baseline case with 0 relevant tracers and 0 irrelevant tracers. With this patch: +---+-++ | Number of tracers | Total time (ns) | Per-call average time | |---+-+| | Relevant | Irrelevant |10 calls | Total (ns) | Overhead (ns) | |--++-++---| |0 | 0 |15254600 |152 | - | |0 | 1 |16136700 |161 | - | |0 | 2 |15329500 |153 | - | |0 | 10 |15148800 |151 | - | |0 |100 |15746900 |157 | - | |0 |200 |15737400 |157 | - | |--++-++---| |1 | 0 |47909000 |479 | 327 | |1 | 1 |48297400 |482 | 330 | |1 | 2 |47314100 |473 | 321 | |1 | 10 |47844900 |478 | 326 | |1 |100 |46591900 |465 | 313 | |1 |200 |47178900 |471 | 319 | |--++-++---| |1 | 0 |46715800 |467 | 315 | |2 | 0 | 155134500 | 1551 | 1399 | | 10 | 0 |
Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
+cc Andy and Evgenii On 06/03/2024 21:35, Alexandre Ghiti wrote: Hi Puranjay, On 06/03/2024 17:59, Puranjay Mohan wrote: This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V. This allows each ftrace callsite to provide an ftrace_ops to the common ftrace trampoline, allowing each callsite to invoke distinct tracer functions without the need to fall back to list processing or to allocate custom trampolines for each callsite. This significantly speeds up cases where multiple distinct trace functions are used and callsites are mostly traced by a single tracer. The idea and most of the implementation is taken from the ARM64's implementation of the same feature. The idea is to place a pointer to the ftrace_ops as a literal at a fixed offset from the function entry point, which can be recovered by the common ftrace trampoline. We use -fpatchable-function-entry to reserve 8 bytes above the function entry by emitting 2 4 byte or 4 2 byte nops depending on the presence of CONFIG_RISCV_ISA_C. These 8 bytes are patched at runtime with a pointer to the associated ftrace_ops for that callsite. Functions are aligned to 8 bytes to make sure that the accesses to this literal are atomic. This approach allows for directly invoking ftrace_ops::func even for ftrace_ops which are dynamically-allocated (or part of a module), without going via ftrace_ops_list_func. I've benchamrked this with the ftrace_ops sample module on Qemu, with the next version, I will provide benchmarks on real hardware: Without this patch: +---+-++ | Number of tracers | Total time (ns) | Per-call average time | |---+-+| | Relevant | Irrelevant | 10 calls | Total (ns) | Overhead (ns) | |--++-++---| | 0 | 0 | 15615700 | 156 | - | | 0 | 1 | 15917600 | 159 | - | | 0 | 2 | 15668000 | 156 | - | | 0 | 10 | 14971500 | 149 | - | | 0 | 100 | 15417600 | 154 | - | | 0 | 200 | 15387000 | 153 | - | |--++-++---| | 1 | 0 | 119906800 | 1199 | 1043 | | 1 | 1 | 137428600 | 1374 | 1218 | | 1 | 2 | 159562400 | 1374 | 1218 | | 1 | 10 | 302099900 | 3020 | 2864 | | 1 | 100 | 2008785500 | 20087 | 19931 | | 1 | 200 | 3965221900 | 39652 | 39496 | |--++-++---| | 1 | 0 | 119166700 | 1191 | 1035 | | 2 | 0 | 15700 | 1579 | 1423 | | 10 | 0 | 425370100 | 4253 | 4097 | | 100 | 0 | 3595252100 | 35952 | 35796 | | 200 | 0 | 7023485700 | 70234 | 70078 | +--++-++---+ Note: per-call overhead is estimated relative to the baseline case with 0 relevant tracers and 0 irrelevant tracers. With this patch: +---+-++ | Number of tracers | Total time (ns) | Per-call average time | |---+-+| | Relevant | Irrelevant | 10 calls | Total (ns) | Overhead (ns) | |--++-++---| | 0 | 0 | 15254600 | 152 | - | | 0 | 1 | 16136700 | 161 | - | | 0 | 2 | 15329500 | 153 | - | | 0 | 10 | 15148800 | 151 | - | | 0 | 100 | 15746900 | 157 | - | | 0 | 200 | 15737400 | 157 | - | |--++-++---| | 1 | 0 | 47909000 | 479 | 327 | | 1 | 1 | 48297400 | 482 | 330 | | 1 | 2 | 47314100 | 473 | 321 | | 1 | 10 | 47844900 | 478 | 326 | | 1 | 100 | 46591900 | 465 | 313 | | 1 | 200 | 47178900 | 471 | 319 | |--++-++---| | 1 | 0 | 46715800 | 467 | 315 | | 2 | 0 | 155134500 | 1551 |
Re: [RFC][PATCH 0/4] Make bpf_jit and kprobes work with CONFIG_MODULES=n
On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote: > Hello all, > > This patchset makes it possible to use bpftrace with kprobes on kernels > built without loadable module support. This is a step in the right direction for another reason: clearly the module_alloc() is not about modules, and we have special reasons for it now beyond modules. The effort to share a generalize a huge page for these things is also another reason for some of this but that is more long term. I'm all for minor changes here so to avoid regressions but it seems a rename is in order -- if we're going to all this might as well do it now. And for that I'd just like to ask you paint the bikeshed with Song Liu as he's been the one slowly making way to help us get there with the "module: replace module_layout with module_memory", and Mike Rapoport as he's had some follow up attempts [0]. As I see it, the EXECMEM stuff would be what we use instead then. Mike kept the module_alloc() and the execmem was just a wrapper but your move of the arch stuff makes sense as well and I think would complement his series nicely. If you're gonna split code up to move to another place, it'd be nice if you can add copyright headers as was done with the kernel/module.c split into kernel/module/*.c Can we start with some small basic stuff we can all agree on? [0] https://lwn.net/Articles/944857/ Luis
Re: [RFC][PATCH 0/4] Make bpf_jit and kprobes work with CONFIG_MODULES=n
On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote: > On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote: > > Hello all, > > > > This patchset makes it possible to use bpftrace with kprobes on kernels > > built without loadable module support. > > This is a step in the right direction for another reason: clearly the > module_alloc() is not about modules, and we have special reasons for it > now beyond modules. The effort to share a generalize a huge page for > these things is also another reason for some of this but that is more > long term. > > I'm all for minor changes here so to avoid regressions but it seems a > rename is in order -- if we're going to all this might as well do it > now. And for that I'd just like to ask you paint the bikeshed with > Song Liu as he's been the one slowly making way to help us get there > with the "module: replace module_layout with module_memory", > and Mike Rapoport as he's had some follow up attempts [0]. As I see it, > the EXECMEM stuff would be what we use instead then. Mike kept the > module_alloc() and the execmem was just a wrapper but your move of the > arch stuff makes sense as well and I think would complement his series > nicely. I apologize for missing that. I think these are the four most recent versions of the different series referenced from that LWN link: a) https://lore.kernel.org/all/20230918072955.2507221-1-r...@kernel.org/ b) https://lore.kernel.org/all/20230526051529.3387103-1-s...@kernel.org/ c) https://lore.kernel.org/all/20221107223921.3451913-1-s...@kernel.org/ d) https://lore.kernel.org/all/20201120202426.18009-1-rick.p.edgeco...@intel.com/ Song and Mike, please correct me if I'm wrong, but I think what I've done here (see [1], sorry for not adding you initially) is compatible with everything both of you have recently proposed above. How do you feel about this as a first step? For naming, execmem_alloc() seems reasonable to me? I have no strong feelings at all, I'll just use that going forward unless somebody else expresses an opinion. [1] https://lore.kernel.org/lkml/cover.1709676663.git.jcalvinow...@gmail.com/T/#m337096e158a5f771d0c7c2fb15a3b80a4443226a > If you're gonna split code up to move to another place, it'd be nice > if you can add copyright headers as was done with the kernel/module.c > split into kernel/module/*.c Silly question: should it be the same copyright header as the original corresponding module.c, or a new one? I tried to preserve the license header because I wasn't sure what to do about it. Thanks, Calvin > Can we start with some small basic stuff we can all agree on? > > [0] https://lwn.net/Articles/944857/ > > Luis
Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
Hi Alex, On Wed, Mar 6, 2024 at 9:35 PM Alexandre Ghiti wrote: > > Hi Puranjay, > > On 06/03/2024 17:59, Puranjay Mohan wrote: > > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V. > > This allows each ftrace callsite to provide an ftrace_ops to the common > > ftrace trampoline, allowing each callsite to invoke distinct tracer > > functions without the need to fall back to list processing or to > > allocate custom trampolines for each callsite. This significantly speeds > > up cases where multiple distinct trace functions are used and callsites > > are mostly traced by a single tracer. > > > > The idea and most of the implementation is taken from the ARM64's > > implementation of the same feature. The idea is to place a pointer to > > the ftrace_ops as a literal at a fixed offset from the function entry > > point, which can be recovered by the common ftrace trampoline. > > > > We use -fpatchable-function-entry to reserve 8 bytes above the function > > entry by emitting 2 4 byte or 4 2 byte nops depending on the presence of > > CONFIG_RISCV_ISA_C. These 8 bytes are patched at runtime with a pointer > > to the associated ftrace_ops for that callsite. Functions are aligned to > > 8 bytes to make sure that the accesses to this literal are atomic. > > > > This approach allows for directly invoking ftrace_ops::func even for > > ftrace_ops which are dynamically-allocated (or part of a module), > > without going via ftrace_ops_list_func. > > > > I've benchamrked this with the ftrace_ops sample module on Qemu, with > > the next version, I will provide benchmarks on real hardware: > > > > Without this patch: > > > > +---+-++ > > | Number of tracers| Total time (ns) | Per-call average time | > > |---+-+| > > | Relevant | Irrelevant |10 calls | Total (ns) | Overhead (ns) | > > |--++-++---| > > |0 | 0 |15615700 |156 | - | > > |0 | 1 |15917600 |159 | - | > > |0 | 2 |15668000 |156 | - | > > |0 | 10 |14971500 |149 | - | > > |0 |100 |15417600 |154 | - | > > |0 |200 |15387000 |153 | - | > > |--++-++---| > > |1 | 0 | 119906800 | 1199 | 1043 | > > |1 | 1 | 137428600 | 1374 | 1218 | > > |1 | 2 | 159562400 | 1374 | 1218 | > > |1 | 10 | 302099900 | 3020 | 2864 | > > |1 |100 | 2008785500 | 20087 | 19931 | > > |1 |200 | 3965221900 | 39652 | 39496 | > > |--++-++---| > > |1 | 0 | 119166700 | 1191 | 1035 | > > |2 | 0 | 15700 | 1579 | 1423 | > > | 10 | 0 | 425370100 | 4253 | 4097 | > > | 100 | 0 | 3595252100 | 35952 | 35796 | > > | 200 | 0 | 7023485700 | 70234 | 70078 | > > +--++-++---+ > > > > Note: per-call overhead is estimated relative to the baseline case with > > 0 relevant tracers and 0 irrelevant tracers. > > > > With this patch: > > > > +---+-++ > > | Number of tracers | Total time (ns) | Per-call average time | > > |---+-+| > > | Relevant | Irrelevant |10 calls | Total (ns) | Overhead (ns) | > > |--++-++---| > > |0 | 0 |15254600 |152 | - | > > |0 | 1 |16136700 |161 | - | > > |0 | 2 |15329500 |153 | - | > > |0 | 10 |15148800 |151 | - | > > |0 |100 |15746900 |157 | - | > > |0 |200 |15737400 |157 | - | > > |--++-++---| > > |1 | 0 |47909000 |479 | 327 | > > |1 | 1 |48297400 |482 | 330 | > > |1 | 2 |47314100 |473 | 321 | > > |1 | 10 |47844900 |478 | 326 | > > |1 |100 |
Re: [RFC][PATCH 0/4] Make bpf_jit and kprobes work with CONFIG_MODULES=n
Hi Calvin, It is great to hear from you! :) On Wed, Mar 6, 2024 at 3:23 PM Calvin Owens wrote: > > On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote: > > On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote: > > > Hello all, > > > > > > This patchset makes it possible to use bpftrace with kprobes on kernels > > > built without loadable module support. > > > > This is a step in the right direction for another reason: clearly the > > module_alloc() is not about modules, and we have special reasons for it > > now beyond modules. The effort to share a generalize a huge page for > > these things is also another reason for some of this but that is more > > long term. > > > > I'm all for minor changes here so to avoid regressions but it seems a > > rename is in order -- if we're going to all this might as well do it > > now. And for that I'd just like to ask you paint the bikeshed with > > Song Liu as he's been the one slowly making way to help us get there > > with the "module: replace module_layout with module_memory", > > and Mike Rapoport as he's had some follow up attempts [0]. As I see it, > > the EXECMEM stuff would be what we use instead then. Mike kept the > > module_alloc() and the execmem was just a wrapper but your move of the > > arch stuff makes sense as well and I think would complement his series > > nicely. > > I apologize for missing that. I think these are the four most recent > versions of the different series referenced from that LWN link: > > a) https://lore.kernel.org/all/20230918072955.2507221-1-r...@kernel.org/ > b) https://lore.kernel.org/all/20230526051529.3387103-1-s...@kernel.org/ > c) https://lore.kernel.org/all/20221107223921.3451913-1-s...@kernel.org/ > d) > https://lore.kernel.org/all/20201120202426.18009-1-rick.p.edgeco...@intel.com/ > > Song and Mike, please correct me if I'm wrong, but I think what I've > done here (see [1], sorry for not adding you initially) is compatible > with everything both of you have recently proposed above. How do you > feel about this as a first step? I agree that the work here is compatible with other efforts. I have no objection to making this the first step. > > For naming, execmem_alloc() seems reasonable to me? I have no strong > feelings at all, I'll just use that going forward unless somebody else > expresses an opinion. I am not good at naming things. No objection from me to "execmem_alloc". Thanks, Song
Re: [RFC PATCH v2 0/7] DAMON based 2-tier memory management for CXL memory
Hello, On Tue, 27 Feb 2024 15:51:20 -0800 SeongJae Park wrote: > On Mon, 26 Feb 2024 23:05:46 +0900 Honggyu Kim wrote: > > > There was an RFC IDEA "DAMOS-based Tiered-Memory Management" previously > > posted at [1]. > > > > It says there is no implementation of the demote/promote DAMOS action > > are made. This RFC is about its implementation for physical address > > space. [...] > Honggyu joined DAMON Beer/Coffee/Tea Chat[1] yesterday, and we discussed about > this patchset in high level. Sharing the summary here for open discussion. > As > also discussed on the first version of this patchset[2], we want to make > single > action for general page migration with minimum changes, but would like to keep > page level access re-check. We also agreed the previously proposed DAMOS > filter-based approach could make sense for the purpose. > > Because I was anyway planning making such DAMOS filter for not only > promotion/demotion but other types of DAMOS action, I will start developing > the > page level access re-check results based DAMOS filter. Once the > implementation > of the prototype is done, I will share the early implementation. Then, > Honggyu > will adjust their implementation based on the filter, and run their tests > again > and share the results. I just posted an RFC patchset for the page level access re-check DAMOS filter: https://lore.kernel.org/r/20240307030013.47041-1...@kernel.org I hope it to help you better understanding and testing the idea. > > [1] https://lore.kernel.org/damon/20220810225102.124459-1...@kernel.org/ > [2] https://lore.kernel.org/damon/20240118171756.80356-1...@kernel.org Thanks, SJ [...]
Re: [RFC][PATCH 0/4] Make bpf_jit and kprobes work with CONFIG_MODULES=n
Hi Calvin, On Wed, Mar 06, 2024 at 03:23:22PM -0800, Calvin Owens wrote: > On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote: > > On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote: > > > Hello all, > > > > > > This patchset makes it possible to use bpftrace with kprobes on kernels > > > built without loadable module support. > > > > This is a step in the right direction for another reason: clearly the > > module_alloc() is not about modules, and we have special reasons for it > > now beyond modules. The effort to share a generalize a huge page for > > these things is also another reason for some of this but that is more > > long term. > > > > I'm all for minor changes here so to avoid regressions but it seems a > > rename is in order -- if we're going to all this might as well do it > > now. And for that I'd just like to ask you paint the bikeshed with > > Song Liu as he's been the one slowly making way to help us get there > > with the "module: replace module_layout with module_memory", > > and Mike Rapoport as he's had some follow up attempts [0]. As I see it, > > the EXECMEM stuff would be what we use instead then. Mike kept the > > module_alloc() and the execmem was just a wrapper but your move of the > > arch stuff makes sense as well and I think would complement his series > > nicely. Actually I've dropped module_alloc() in favor of execmem_alloc() ;-) > I apologize for missing that. I think these are the four most recent > versions of the different series referenced from that LWN link: > > a) https://lore.kernel.org/all/20230918072955.2507221-1-r...@kernel.org/ > b) https://lore.kernel.org/all/20230526051529.3387103-1-s...@kernel.org/ > c) https://lore.kernel.org/all/20221107223921.3451913-1-s...@kernel.org/ > d) > https://lore.kernel.org/all/20201120202426.18009-1-rick.p.edgeco...@intel.com/ > > Song and Mike, please correct me if I'm wrong, but I think what I've > done here (see [1], sorry for not adding you initially) is compatible > with everything both of you have recently proposed above. How do you > feel about this as a first step? No objections from me. > For naming, execmem_alloc() seems reasonable to me? I have no strong > feelings at all, I'll just use that going forward unless somebody else > expresses an opinion. I like execmem_alloc() and CONFIG_EXECMEM. -- Sincerely yours, Mike.
Re: [RFC][PATCH 3/4] kprobes: Allow kprobes with CONFIG_MODULES=n
On Wed, Mar 06, 2024 at 12:05:10PM -0800, Calvin Owens wrote:
> If something like this is merged down the road, it can go in at leisure
> once the module_alloc change is in: it's a one-way dependency.
>
> Signed-off-by: Calvin Owens
> ---
> arch/Kconfig| 2 +-
> kernel/kprobes.c| 22 ++
> kernel/trace/trace_kprobe.c | 11 +++
> 3 files changed, 34 insertions(+), 1 deletion(-)
When I did this in my last execmem posting, I think I've got slightly less
ugly ifdery, you may want to take a look at that:
https://lore.kernel.org/all/20230918072955.2507221-13-r...@kernel.org
> diff --git a/arch/Kconfig b/arch/Kconfig
> index cfc24ced16dd..e60ce984d095 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -52,8 +52,8 @@ config GENERIC_ENTRY
>
> config KPROBES
> bool "Kprobes"
> - depends on MODULES
> depends on HAVE_KPROBES
> + select MODULE_ALLOC
> select KALLSYMS
> select TASKS_RCU if PREEMPTION
> help
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 9d9095e81792..194270e17d57 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1556,8 +1556,12 @@ static bool is_cfi_preamble_symbol(unsigned long addr)
> str_has_prefix("__pfx_", symbuf);
> }
>
> +#if IS_ENABLED(CONFIG_MODULES)
> static int check_kprobe_address_safe(struct kprobe *p,
>struct module **probed_mod)
> +#else
> +static int check_kprobe_address_safe(struct kprobe *p)
> +#endif
> {
> int ret;
>
> @@ -1580,6 +1584,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
> goto out;
> }
>
> +#if IS_ENABLED(CONFIG_MODULES)
Plain #ifdef will do here and below. IS_ENABLED is for usage withing the
code, like
if (IS_ENABLED(CONFIG_MODULES))
;
> /* Check if 'p' is probing a module. */
> *probed_mod = __module_text_address((unsigned long) p->addr);
> if (*probed_mod) {
--
Sincerely yours,
Mike.
Re: [PATCH -next v6 0/2] Make memory reclamation measurable
在 2024/2/21 15:44, Michal Hocko 写道: It would be really helpful to have more details on why we need those trace points. It is my understanding that you would like to have a more fine grained numbers for the time duration of different parts of the reclaim process. I can imagine this could be useful in some cases but is it useful enough and for a wider variety of workloads? Is that worth a dedicated static tracepoints? Why an add-hoc dynamic tracepoints or BPF for a very special situation is not sufficient? In other words, tell us more about the usecases and why is this generally useful. Thank you for your reply, I'm sorry that I forgot to describe the detailed reason. Memory reclamation usually occurs when there is high memory pressure (or low memory) and is performed by Kswapd. In embedded systems, CPU resources are limited, and it is common for kswapd and critical processes (which typically require a large amount of memory and trigger memory reclamation) to compete for CPU resources. which in turn affects the execution of this key process, causing the execution time to increase and causing lags,such as dropped frames or slower startup times in mobile games. Currently, with the help of kernel trace events or tools like Perfetto, we can only see that kswapd is competing for CPU and the frequency of memory reclamation triggers, but we do not have detailed information or metrics about memory reclamation, such as the duration and amount of each reclamation, or who is releasing memory (super_cache, f2fs, ext4), etc. This makes it impossible to locate the above problems. Currently this patch helps us solve 2 actual performance problems (kswapd preempts the CPU causing game delay) 1. The increased memory allocation in the game (across different versions) has led to the degradation of kswapd. This is found by calculating the total amount of Reclaim(page) during the game startup phase. 2. The adoption of a different file system in the new system version has resulted in a slower reclamation rate. This is discovered through the OBJ_NAME change. For example, OBJ_NAME changes from super_cache_scan to ext4_es_scan. Subsequently, it is also possible to calculate the memory reclamation rate to evaluate the memory performance of different versions. The main reasons for adding static tracepoints are: 1. To subdivide the time spent in the shrinker->count_objects() and shrinker->scan_objects() functions within the do_shrink_slab function. Using BPF kprobe, we can only track the time spent in the do_shrink_slab function. 2. When tracing frequently called functions, static tracepoints (BPF tp/tracepoint) have lower performance impact compared to dynamic tracepoints (BPF kprobe). Thanks Bixuan Cui
