October 2023 - Linux-stable-mirror

[PATCH v3 4/6] serial: core: make sure RS485 cannot be enabled when it is not supported

by Lino Sanfilippo

Some uart drivers specify a rs485_config() function and then decide later to disable RS485 support for some reason (e.g. imx and ar933). In these cases userspace may be able to activate RS485 via TIOCSRS485 nevertheless, since in uart_set_rs485_config() an existing rs485_config() function indicates that RS485 is supported. Make sure that this is not longer possible by checking the uarts rs485_supported.flags instead and bailing out if SER_RS485_ENABLED is not set. Furthermore instead of returning an empty structure return -ENOTTY if the RS485 configuration is requested via TIOCGRS485 but RS485 is not supported. This has a small impact on userspace visibility but it is consistent with the -ENOTTY error for TIOCGRS485. Fixes: e849145e1fdd ("serial: ar933x: Fill in rs485_supported") Fixes: 55e18c6b6d42 ("serial: imx: Remove serial_rs485 sanitization") Cc: stable(a)vger.kernel.org Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/serial_core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index f4feebf8200f..dca09877fabc 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1432,6 +1432,9 @@ static int uart_get_rs485_config(struct uart_port *port, unsigned long flags; struct serial_rs485 aux; + if (!(port->rs485_supported.flags & SER_RS485_ENABLED)) + return -ENOTTY; + spin_lock_irqsave(&port->lock, flags); aux = port->rs485; spin_unlock_irqrestore(&port->lock, flags); @@ -1449,7 +1452,7 @@ static int uart_set_rs485_config(struct tty_struct *tty, struct uart_port *port, int ret; unsigned long flags; - if (!port->rs485_config) + if (!(port->rs485_supported.flags & SER_RS485_ENABLED)) return -ENOTTY; if (copy_from_user(&rs485, rs485_user, sizeof(*rs485_user))) -- 2.40.1

1 year, 3 months

1
0
0 0

[PATCH v3 2/6] serial: core: set missing supported flag for RX during TX GPIO

by Lino Sanfilippo

If the RS485 feature RX-during-TX is supported by means of a GPIO set the according supported flag. Otherwise setting this feature from userspace may not be possible, since in uart_sanitize_serial_rs485() the passed RS485 configuration is matched against the supported features and unsupported settings are thereby removed and thus take no effect. Cc: stable(a)vger.kernel.org Fixes: 163f080eb717 ("serial: core: Add option to output RS485 RX_DURING_TX state via GPIO") Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/serial_core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index ef0500be3553..697c36dc7ec8 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -3622,6 +3622,8 @@ int uart_get_rs485_mode(struct uart_port *port) port->rs485_rx_during_tx_gpio = NULL; return dev_err_probe(dev, ret, "Cannot get rs485-rx-during-tx-gpios\n"); } + if (port->rs485_rx_during_tx_gpio) + port->rs485_supported.flags |= SER_RS485_RX_DURING_TX; return 0; } -- 2.40.1

1 year, 3 months

1
0
0 0

[PATCH v2 7/7] serial: omap: do not override settings for RS485 support

by Lino Sanfilippo

In serial_omap_rs485() RS485 support may be deactivated due to a missing RTS GPIO. This is done by nullifying the ports rs485_supported struct. After that however the serial_omap_rs485_supported struct is assigned to the same structure unconditionally, which results in an unintended reactivation of RS485 support. Fix this by callling serial_omap_rs485() after the assignment of rs485_supported. Fixes: e2752ae3cfc9 ("serial: omap: Disallow RS-485 if rts-gpio is not specified") Cc: stable(a)vger.kernel.org Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/omap-serial.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 0ead88c5a19a..4f7ee4392034 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1604,10 +1604,6 @@ static int serial_omap_probe(struct platform_device *pdev) dev_info(up->port.dev, "no wakeirq for uart%d\n", up->port.line); - ret = serial_omap_probe_rs485(up, &pdev->dev); - if (ret < 0) - goto err_rs485; - sprintf(up->name, "OMAP UART%d", up->port.line); up->port.mapbase = mem->start; up->port.membase = base; @@ -1622,6 +1618,10 @@ static int serial_omap_probe(struct platform_device *pdev) DEFAULT_CLK_SPEED); } + ret = serial_omap_probe_rs485(up, &pdev->dev); + if (ret < 0) + goto err_rs485; + up->latency = PM_QOS_CPU_LATENCY_DEFAULT_VALUE; up->calc_latency = PM_QOS_CPU_LATENCY_DEFAULT_VALUE; cpu_latency_qos_add_request(&up->pm_qos_request, up->latency); -- 2.40.1

1 year, 3 months

1
0
0 0

[PATCH v2 6/7] serial: core, imx: do not set RS485 enabled if it is not supported

by Lino Sanfilippo

If the imx driver cannot support RS485 it sets the ports rs485_supported structure to NULL. But it still calls uart_get_rs485_mode() which may set the RS485_ENABLED flag nevertheless. This may lead to an attempt to configure RS485 even if it is not supported when the flag is evaluated in uart_configure_port() at port startup. Avoid this by bailing out of uart_get_rs485_mode() if the RS485_ENABLED flag is not supported by the caller. With this fix a check for RTS availability is now obsolete in the imx driver, since it can not evaluate to true any more. Remove this check, too. Fixes: 00d7a00e2a6f ("serial: imx: Fill in rs485_supported") Cc: stable(a)vger.kernel.org Suggested-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/imx.c | 4 ---- drivers/tty/serial/serial_core.c | 3 +++ 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index edb2ec6a5567..c8c19bf8585d 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -2332,10 +2332,6 @@ static int imx_uart_probe(struct platform_device *pdev) return ret; } - if (sport->port.rs485.flags & SER_RS485_ENABLED && - (!sport->have_rtscts && !sport->have_rtsgpio)) - dev_err(&pdev->dev, "no RTS control, disabling rs485\n"); - /* * If using the i.MX UART RTS/CTS control then the RTS (CTS_B) * signal cannot be set low during transmission in case the diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index dca09877fabc..95cec2343b35 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -3576,6 +3576,9 @@ int uart_get_rs485_mode(struct uart_port *port) int ret; int rx_during_tx_gpio_flag; + if (!(port->rs485_supported.flags & SER_RS485_ENABLED)) + return 0; + ret = device_property_read_u32_array(dev, "rs485-rts-delay", rs485_delay, 2); if (!ret) { -- 2.40.1

1 year, 3 months

1
0
0 0

[PATCH v2 5/7] serial: core: make sure RS485 cannot be enabled when it is not supported

by Lino Sanfilippo

Some uart drivers specify a rs485_config() function and then decide later to disable RS485 support for some reason (e.g. imx and ar933). In these cases userspace may be able to activate RS485 via TIOCSRS485 nevertheless, since in uart_set_rs485_config() an existing rs485_config() function indicates that RS485 is supported. Make sure that this is not longer possible by checking the uarts rs485_supported.flags instead and bailing out if SER_RS485_ENABLED is not set. Furthermore instead of returning an empty structure return -ENOTTY if the RS485 configuration is requested via TIOCGRS485 but RS485 is not supported. This has a small impact on userspace visibility but it is consistent with the -ENOTTY error for TIOCGRS485. Fixes: e849145e1fdd ("serial: ar933x: Fill in rs485_supported") Fixes: 55e18c6b6d42 ("serial: imx: Remove serial_rs485 sanitization") Cc: stable(a)vger.kernel.org Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/serial_core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index f4feebf8200f..dca09877fabc 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1432,6 +1432,9 @@ static int uart_get_rs485_config(struct uart_port *port, unsigned long flags; struct serial_rs485 aux; + if (!(port->rs485_supported.flags & SER_RS485_ENABLED)) + return -ENOTTY; + spin_lock_irqsave(&port->lock, flags); aux = port->rs485; spin_unlock_irqrestore(&port->lock, flags); @@ -1449,7 +1452,7 @@ static int uart_set_rs485_config(struct tty_struct *tty, struct uart_port *port, int ret; unsigned long flags; - if (!port->rs485_config) + if (!(port->rs485_supported.flags & SER_RS485_ENABLED)) return -ENOTTY; if (copy_from_user(&rs485, rs485_user, sizeof(*rs485_user))) -- 2.40.1

1 year, 3 months

1
0
0 0

[PATCH v2 4/7] serial: core: fix sanitizing check for RTS settings

by Lino Sanfilippo

Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS settings in a RS485 configuration that has been passed by userspace. If RTS-on-send and RTS-after-send are both set or unset the configuration is adjusted and RTS-after-send is disabled and RTS-on-send enabled. This however makes only sense if both RTS modes are actually supported by the driver. With commit be2e2cb1d281 ("serial: Sanitize rs485_struct") the code does take the driver support into account but only checks if one of both RTS modes are supported. This may lead to the errorneous result of RTS-on-send being set even if only RTS-after-send is supported. Fix this by changing the implemented logic: First clear all unsupported flags in the RS485 configuration, then adjust an invalid RTS setting by taking into account which RTS mode is supported. Cc: stable(a)vger.kernel.org Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct") Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/serial_core.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 697c36dc7ec8..f4feebf8200f 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1370,19 +1370,27 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4 return; } + rs485->flags &= supported_flags; + /* Pick sane settings if the user hasn't */ - if ((supported_flags & (SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND)) && - !(rs485->flags & SER_RS485_RTS_ON_SEND) == + if (!(rs485->flags & SER_RS485_RTS_ON_SEND) == !(rs485->flags & SER_RS485_RTS_AFTER_SEND)) { - dev_warn_ratelimited(port->dev, - "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n", - port->name, port->line); - rs485->flags |= SER_RS485_RTS_ON_SEND; - rs485->flags &= ~SER_RS485_RTS_AFTER_SEND; - supported_flags |= SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND; - } + if (supported_flags & SER_RS485_RTS_ON_SEND) { + rs485->flags |= SER_RS485_RTS_ON_SEND; + rs485->flags &= ~SER_RS485_RTS_AFTER_SEND; - rs485->flags &= supported_flags; + dev_warn_ratelimited(port->dev, + "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n", + port->name, port->line); + } else { + rs485->flags |= SER_RS485_RTS_AFTER_SEND; + rs485->flags &= ~SER_RS485_RTS_ON_SEND; + + dev_warn_ratelimited(port->dev, + "%s (%d): invalid RTS setting, using RTS_AFTER_SEND instead\n", + port->name, port->line); + } + } uart_sanitize_serial_rs485_delays(port, rs485); -- 2.40.1

1 year, 3 months

1
0
0 0

[PATCH v2 3/7] serial: core: set missing supported flag for RX during TX GPIO

by Lino Sanfilippo

If the RS485 feature RX-during-TX is supported by means of a GPIO set the according supported flag. Otherwise setting this feature from userspace may not be possible, since in uart_sanitize_serial_rs485() the passed RS485 configuration is matched against the supported features and unsupported settings are thereby removed and thus take no effect. Cc: stable(a)vger.kernel.org Fixes: 163f080eb717 ("serial: core: Add option to output RS485 RX_DURING_TX state via GPIO") Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/serial_core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index ef0500be3553..697c36dc7ec8 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -3622,6 +3622,8 @@ int uart_get_rs485_mode(struct uart_port *port) port->rs485_rx_during_tx_gpio = NULL; return dev_err_probe(dev, ret, "Cannot get rs485-rx-during-tx-gpios\n"); } + if (port->rs485_rx_during_tx_gpio) + port->rs485_supported.flags |= SER_RS485_RX_DURING_TX; return 0; } -- 2.40.1

1 year, 3 months

1
0
0 0

[PATCH v2 1/7] serial: Do not hold the port lock when setting rx-during-tx GPIO

by Lino Sanfilippo

Both the imx and stm32 driver set the rx-during-tx GPIO in the rs485_config() function by means of gpiod_set_value(). Since rs485_config() is called with the port lock held, this can be an problem in case that setting the GPIO line can sleep (e.g. if a GPIO expander is used which is connected via SPI or I2C). Avoid this issue by setting the GPIO outside of the port lock in the serial core and by using gpiod_set_value_cansleep() instead of gpiod_set_value(). Since now both the term and the rx-during-tx GPIO are set within the serial core use a common function uart_set_rs485_gpios() to set both. With moving it into the serial core setting the rx-during-tx GPIO is now automatically done for all drivers that support such a GPIO. Fixes: c54d48543689 ("serial: stm32: Add support for rs485 RX_DURING_TX output GPIO") Fixes: ca530cfa968c ("serial: imx: Add support for RS485 RX_DURING_TX output GPIO") Cc: stable(a)vger.kernel.org Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/imx.c | 4 ---- drivers/tty/serial/serial_core.c | 10 ++++++---- drivers/tty/serial/stm32-usart.c | 5 +---- 3 files changed, 7 insertions(+), 12 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 13cb78340709..edb2ec6a5567 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -1947,10 +1947,6 @@ static int imx_uart_rs485_config(struct uart_port *port, struct ktermios *termio rs485conf->flags & SER_RS485_RX_DURING_TX) imx_uart_start_rx(port); - if (port->rs485_rx_during_tx_gpio) - gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio, - !!(rs485conf->flags & SER_RS485_RX_DURING_TX)); - return 0; } diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 7bdc21d5e13b..ef0500be3553 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1391,14 +1391,16 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4 memset(rs485->padding1, 0, sizeof(rs485->padding1)); } -static void uart_set_rs485_termination(struct uart_port *port, - const struct serial_rs485 *rs485) +static void uart_set_rs485_gpios(struct uart_port *port, + const struct serial_rs485 *rs485) { if (!(rs485->flags & SER_RS485_ENABLED)) return; gpiod_set_value_cansleep(port->rs485_term_gpio, !!(rs485->flags & SER_RS485_TERMINATE_BUS)); + gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio, + !!(rs485->flags & SER_RS485_RX_DURING_TX)); } static int uart_rs485_config(struct uart_port *port) @@ -1407,7 +1409,7 @@ static int uart_rs485_config(struct uart_port *port) int ret; uart_sanitize_serial_rs485(port, rs485); - uart_set_rs485_termination(port, rs485); + uart_set_rs485_gpios(port, rs485); ret = port->rs485_config(port, NULL, rs485); if (ret) @@ -1449,7 +1451,7 @@ static int uart_set_rs485_config(struct tty_struct *tty, struct uart_port *port, if (ret) return ret; uart_sanitize_serial_rs485(port, &rs485); - uart_set_rs485_termination(port, &rs485); + uart_set_rs485_gpios(port, &rs485); spin_lock_irqsave(&port->lock, flags); ret = port->rs485_config(port, &tty->termios, &rs485); diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c index 5e9cf0c48813..8eb13bf055f2 100644 --- a/drivers/tty/serial/stm32-usart.c +++ b/drivers/tty/serial/stm32-usart.c @@ -226,10 +226,7 @@ static int stm32_usart_config_rs485(struct uart_port *port, struct ktermios *ter stm32_usart_clr_bits(port, ofs->cr1, BIT(cfg->uart_enable_bit)); - if (port->rs485_rx_during_tx_gpio) - gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio, - !!(rs485conf->flags & SER_RS485_RX_DURING_TX)); - else + if (!port->rs485_rx_during_tx_gpio) rs485conf->flags |= SER_RS485_RX_DURING_TX; if (rs485conf->flags & SER_RS485_ENABLED) { -- 2.40.1

1 year, 3 months

1
0
0 0

Can you reach your supplier at 3 p.m

by rattan furniture

1 year, 3 months

1
0
0 0

[PATCH] perf/core: Introduce cpuctx->cgrp_ctx_list

by Namhyung Kim

The commit bd2756811766 ("perf: Rewrite core context handling") removed cgrp_cpuctx_list to link active cpu (pmu) contexts together. It's used in the perf_cgroup_switch() to access cgroup events only. But after the change, it ended up iterating all pmus/events in the cpu context if there's a cgroup event somewhere on the cpu context. Unfortunately it includes uncore pmus which have much longer latency to control. That regressed some load tests occasionally (only when unrelated perf stat with cgroup events and uncore events ran on the same cpu) due to increased context switch time. AFAIK we don't have a tool to measure the context switch overhead directly. (I think I should add one to perf ftrace latency). But I can see it with a simple perf bench command like this. $ perf bench sched pipe -l 100000 # Running 'sched/pipe' benchmark: # Executed 100000 pipe operations between two processes Total time: 0.650 [sec] 6.505740 usecs/op 153710 ops/sec It runs two tasks communicate each other using a pipe so it should stress the context switch code. This is the normal numbers on my system. But after I run these two perf stat commands in background, the numbers vary a lot. $ sudo perf stat -a -e cycles -G user.slice -- sleep 100000 & $ sudo perf stat -a -e uncore_imc/cas_count_read/ -- sleep 10000 & I will show the last two lines of perf bench sched pipe output for three runs. 58.597060 usecs/op # run 1 17065 ops/sec 11.329240 usecs/op # run 2 88267 ops/sec 88.481920 usecs/op # run 3 11301 ops/sec I think the deviation comes from the fact that uncore events are managed a certain number of cpus only. If the target process runs on a cpu that manages uncore pmu, it'd take longer. Otherwise it won't affect the performance much. To fix the issue, I restored a linked list equivalent to cgrp_cpuctx_list in the perf_cpu_context and link perf_cpu_pmu_contexts that have cgroup events only. Also add new helpers to enable/disable and does ctx sched in/out for cgroups. After the change, I got something like this constantly. It's slightly higher than the normal, but it includes actual cgroup event switch time. 8.970910 usecs/op 111471 ops/sec Fixes: bd2756811766 ("perf: Rewrite core context handling") Cc: stable(a)vger.kernel.org Signed-off-by: Namhyung Kim <namhyung(a)kernel.org> --- include/linux/perf_event.h | 5 ++ kernel/events/core.c | 117 +++++++++++++++++++++++++++++++++---- 2 files changed, 111 insertions(+), 11 deletions(-) diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index e85cd1c0eaf3..7d56d7aa6b34 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -972,6 +972,10 @@ struct perf_cpu_pmu_context { struct perf_event_pmu_context epc; struct perf_event_pmu_context *task_epc; +#ifdef CONFIG_CGROUP_PERF + struct list_head cgrp_ctx_entry; +#endif + struct list_head sched_cb_entry; int sched_cb_usage; @@ -994,6 +998,7 @@ struct perf_cpu_context { #ifdef CONFIG_CGROUP_PERF struct perf_cgroup *cgrp; + struct list_head cgrp_ctx_list; #endif /* diff --git a/kernel/events/core.c b/kernel/events/core.c index 4c72a41f11af..06b39b8066a9 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -700,11 +700,73 @@ static void perf_ctx_enable(struct perf_event_context *ctx) perf_pmu_enable(pmu_ctx->pmu); } +static int __ctx_sched_out(struct perf_event_context *ctx, enum event_type_t event_type); static void ctx_sched_out(struct perf_event_context *ctx, enum event_type_t event_type); +static int __ctx_sched_in(struct perf_event_context *ctx, enum event_type_t event_type); static void ctx_sched_in(struct perf_event_context *ctx, enum event_type_t event_type); +static void __pmu_ctx_sched_out(struct perf_event_pmu_context *pmu_ctx, + enum event_type_t event_type); +static void ctx_pinned_sched_in(struct perf_event_context *ctx, struct pmu *pmu); +static void ctx_flexible_sched_in(struct perf_event_context *ctx, struct pmu *pmu); #ifdef CONFIG_CGROUP_PERF +static void perf_cgrp_ctx_disable(struct perf_event_context *ctx) +{ + struct perf_cpu_context *cpuctx; + struct perf_cpu_pmu_context *cpc; + + cpuctx = container_of(ctx, struct perf_cpu_context, ctx); + list_for_each_entry(cpc, &cpuctx->cgrp_ctx_list, cgrp_ctx_entry) + perf_pmu_disable(cpc->epc.pmu); +} + +static void perf_cgrp_ctx_enable(struct perf_event_context *ctx) +{ + struct perf_cpu_context *cpuctx; + struct perf_cpu_pmu_context *cpc; + + cpuctx = container_of(ctx, struct perf_cpu_context, ctx); + list_for_each_entry(cpc, &cpuctx->cgrp_ctx_list, cgrp_ctx_entry) + perf_pmu_enable(cpc->epc.pmu); +} + +static void cgrp_ctx_sched_out(struct perf_cpu_context *cpuctx, + enum event_type_t event_type) +{ + struct perf_cpu_pmu_context *cpc; + int is_active = __ctx_sched_out(&cpuctx->ctx, event_type); + + if (is_active < 0) + return; + + list_for_each_entry(cpc, &cpuctx->cgrp_ctx_list, cgrp_ctx_entry) + __pmu_ctx_sched_out(&cpc->epc, is_active); +} + +static void cgrp_ctx_sched_in(struct perf_cpu_context *cpuctx, + enum event_type_t event_type) +{ + struct perf_cpu_pmu_context *cpc; + int is_active = __ctx_sched_in(&cpuctx->ctx, event_type); + + if (is_active < 0) + return; + + list_for_each_entry(cpc, &cpuctx->cgrp_ctx_list, cgrp_ctx_entry) { + /* + * First go through the list and put on any pinned groups + * in order to give them the best chance of going on. + */ + if (is_active & EVENT_PINNED) + ctx_pinned_sched_in(&cpuctx->ctx, cpc->epc.pmu); + + /* Then walk through the lower prio flexible groups */ + if (is_active & EVENT_FLEXIBLE) + ctx_flexible_sched_in(&cpuctx->ctx, cpc->epc.pmu); + } +} + static inline bool perf_cgroup_match(struct perf_event *event) { @@ -856,9 +918,9 @@ static void perf_cgroup_switch(struct task_struct *task) return; perf_ctx_lock(cpuctx, cpuctx->task_ctx); - perf_ctx_disable(&cpuctx->ctx); + perf_cgrp_ctx_disable(&cpuctx->ctx); - ctx_sched_out(&cpuctx->ctx, EVENT_ALL); + cgrp_ctx_sched_out(cpuctx, EVENT_ALL); /* * must not be done before ctxswout due * to update_cgrp_time_from_cpuctx() in @@ -870,9 +932,9 @@ static void perf_cgroup_switch(struct task_struct *task) * perf_cgroup_set_timestamp() in ctx_sched_in() * to not have to pass task around */ - ctx_sched_in(&cpuctx->ctx, EVENT_ALL); + cgrp_ctx_sched_in(cpuctx, EVENT_ALL); - perf_ctx_enable(&cpuctx->ctx); + perf_cgrp_ctx_enable(&cpuctx->ctx); perf_ctx_unlock(cpuctx, cpuctx->task_ctx); } @@ -961,6 +1023,7 @@ static inline void perf_cgroup_event_enable(struct perf_event *event, struct perf_event_context *ctx) { struct perf_cpu_context *cpuctx; + struct perf_cpu_pmu_context *cpc; if (!is_cgroup_event(event)) return; @@ -975,12 +1038,16 @@ perf_cgroup_event_enable(struct perf_event *event, struct perf_event_context *ct return; cpuctx->cgrp = perf_cgroup_from_task(current, ctx); + + cpc = container_of(event->pmu_ctx, struct perf_cpu_pmu_context, epc); + list_add(&cpc->cgrp_ctx_entry, &cpuctx->cgrp_ctx_list); } static inline void perf_cgroup_event_disable(struct perf_event *event, struct perf_event_context *ctx) { struct perf_cpu_context *cpuctx; + struct perf_cpu_pmu_context *cpc; if (!is_cgroup_event(event)) return; @@ -995,6 +1062,9 @@ perf_cgroup_event_disable(struct perf_event *event, struct perf_event_context *c return; cpuctx->cgrp = NULL; + + cpc = container_of(event->pmu_ctx, struct perf_cpu_pmu_context, epc); + list_del(&cpc->cgrp_ctx_entry); } #else /* !CONFIG_CGROUP_PERF */ @@ -3238,11 +3308,10 @@ static void __pmu_ctx_sched_out(struct perf_event_pmu_context *pmu_ctx, perf_pmu_enable(pmu); } -static void -ctx_sched_out(struct perf_event_context *ctx, enum event_type_t event_type) +static int +__ctx_sched_out(struct perf_event_context *ctx, enum event_type_t event_type) { struct perf_cpu_context *cpuctx = this_cpu_ptr(&perf_cpu_context); - struct perf_event_pmu_context *pmu_ctx; int is_active = ctx->is_active; lockdep_assert_held(&ctx->lock); @@ -3254,7 +3323,7 @@ ctx_sched_out(struct perf_event_context *ctx, enum event_type_t event_type) WARN_ON_ONCE(ctx->is_active); if (ctx->task) WARN_ON_ONCE(cpuctx->task_ctx); - return; + return -1; } /* @@ -3290,6 +3359,18 @@ ctx_sched_out(struct perf_event_context *ctx, enum event_type_t event_type) is_active ^= ctx->is_active; /* changed bits */ + return is_active; +} + +static void +ctx_sched_out(struct perf_event_context *ctx, enum event_type_t event_type) +{ + struct perf_event_pmu_context *pmu_ctx; + int is_active = __ctx_sched_out(ctx, event_type); + + if (is_active < 0) + return; + list_for_each_entry(pmu_ctx, &ctx->pmu_ctx_list, pmu_ctx_entry) __pmu_ctx_sched_out(pmu_ctx, is_active); } @@ -3861,8 +3942,8 @@ static void __pmu_ctx_sched_in(struct perf_event_context *ctx, struct pmu *pmu) ctx_flexible_sched_in(ctx, pmu); } -static void -ctx_sched_in(struct perf_event_context *ctx, enum event_type_t event_type) +static int +__ctx_sched_in(struct perf_event_context *ctx, enum event_type_t event_type) { struct perf_cpu_context *cpuctx = this_cpu_ptr(&perf_cpu_context); int is_active = ctx->is_active; @@ -3870,7 +3951,7 @@ ctx_sched_in(struct perf_event_context *ctx, enum event_type_t event_type) lockdep_assert_held(&ctx->lock); if (likely(!ctx->nr_events)) - return; + return -1; if (!(is_active & EVENT_TIME)) { /* start ctx time */ @@ -3893,6 +3974,17 @@ ctx_sched_in(struct perf_event_context *ctx, enum event_type_t event_type) is_active ^= ctx->is_active; /* changed bits */ + return is_active; +} + +static void +ctx_sched_in(struct perf_event_context *ctx, enum event_type_t event_type) +{ + int is_active = __ctx_sched_in(ctx, event_type); + + if (is_active < 0) + return; + /* * First go through the list and put on any pinned groups * in order to give them the best chance of going on. @@ -13541,6 +13633,9 @@ static void __init perf_event_init_all_cpus(void) cpuctx->online = cpumask_test_cpu(cpu, perf_online_mask); cpuctx->heap_size = ARRAY_SIZE(cpuctx->heap_default); cpuctx->heap = cpuctx->heap_default; +#ifdef CONFIG_CGROUP_PERF + INIT_LIST_HEAD(&cpuctx->cgrp_ctx_list); +#endif } } -- 2.42.0.582.g8ccd20d70d-goog

1 year, 3 months

3
12
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023