October 2023 - Linux-stable-mirror

[merged mm-hotfixes-stable] mm-zswap-fix-pool-refcount-bug-around-shrink_worker.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: zswap: fix pool refcount bug around shrink_worker() has been removed from the -mm tree. Its filename was mm-zswap-fix-pool-refcount-bug-around-shrink_worker.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Johannes Weiner <hannes(a)cmpxchg.org> Subject: mm: zswap: fix pool refcount bug around shrink_worker() Date: Fri, 6 Oct 2023 12:00:24 -0400 When a zswap store fails due to the limit, it acquires a pool reference and queues the shrinker. When the shrinker runs, it drops the reference. However, there can be multiple store attempts before the shrinker wakes up and runs once. This results in reference leaks and eventual saturation warnings for the pool refcount. Fix this by dropping the reference again when the shrinker is already queued. This ensures one reference per shrinker run. Link: https://lkml.kernel.org/r/20231006160024.170748-1-hannes@cmpxchg.org Fixes: 45190f01dd40 ("mm/zswap.c: add allocation hysteresis if pool limit is hit") Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org> Reported-by: Chris Mason <clm(a)fb.com> Acked-by: Nhat Pham <nphamcs(a)gmail.com> Cc: Vitaly Wool <vitaly.wool(a)konsulko.com> Cc: Domenico Cerasuolo <cerasuolodomenico(a)gmail.com> Cc: <stable(a)vger.kernel.org> [5.6+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/zswap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/zswap.c~mm-zswap-fix-pool-refcount-bug-around-shrink_worker +++ a/mm/zswap.c @@ -1383,8 +1383,8 @@ reject: shrink: pool = zswap_pool_last_get(); - if (pool) - queue_work(shrink_wq, &pool->shrink_work); + if (pool && !queue_work(shrink_wq, &pool->shrink_work)) + zswap_pool_put(pool); goto reject; } _ Patches currently in -mm which might be from hannes(a)cmpxchg.org are

1 year, 3 months

1
0
0 0

[PATCH v4 7/7] serial: 8250_exar: Set missing rs485_supported flag

by Lino Sanfilippo

The UART supports an auto-RTS mode in which the RTS pin is automatically activated during transmission. So mark this mode as being supported even if RTS is not controlled by the driver but the UART. Also the serial core expects now at least one of both modes rts-on-send or rts-after-send to be supported. This is since during sanitization unsupported flags are deleted from a RS485 configuration set by userspace. However if the configuration ends up with both flags unset, the core prints a warning since it considers such a configuration invalid (see uart_sanitize_serial_rs485()). Cc: stable(a)vger.kernel.org Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/8250/8250_exar.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) This patch is only required if "serial: core: fix sanitizing check for RTS settings" is applied, which is also part of this series. Therefore it lacks a "Fixes:" tag. diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c index 077c3ba3539e..8385be846840 100644 --- a/drivers/tty/serial/8250/8250_exar.c +++ b/drivers/tty/serial/8250/8250_exar.c @@ -446,7 +446,7 @@ static int generic_rs485_config(struct uart_port *port, struct ktermios *termios } static const struct serial_rs485 generic_rs485_supported = { - .flags = SER_RS485_ENABLED, + .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND, }; static const struct exar8250_platform exar8250_default_platform = { @@ -490,7 +490,8 @@ static int iot2040_rs485_config(struct uart_port *port, struct ktermios *termios } static const struct serial_rs485 iot2040_rs485_supported = { - .flags = SER_RS485_ENABLED | SER_RS485_RX_DURING_TX | SER_RS485_TERMINATE_BUS, + .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | + SER_RS485_RX_DURING_TX | SER_RS485_TERMINATE_BUS, }; static const struct property_entry iot2040_gpio_properties[] = { -- 2.40.1

1 year, 3 months

1
0
0 0

[PATCH v4 6/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 v4 5/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: Shawn Guo <shawnguo(a)kernel.org> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> 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 49dd5e864719..c85275a573e3 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -3586,6 +3586,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 v4 4/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: Shawn Guo <shawnguo(a)kernel.org> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> 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 f1d889f9fd6e..49dd5e864719 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1443,6 +1443,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); @@ -1460,7 +1463,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 v4 3/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 ef9e9014bfab..f1d889f9fd6e 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 v4 2/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 35e014f83465..ef9e9014bfab 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -3632,6 +3632,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 v4 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 rs485_config(). Since this function 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 moving the GPIO setting outside of the port lock into the serial core and thus making it a generic feature. Since both setting the term and the rx-during-tx GPIO is done at the same code place, move it into a common function. 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: Shawn Guo <shawnguo(a)kernel.org> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> 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 | 15 +++++++++++---- drivers/tty/serial/stm32-usart.c | 5 +---- 3 files changed, 12 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 d5ba6e90bd95..35e014f83465 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1391,14 +1391,21 @@ 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) +/* + * Set optional RS485 GPIOs for bus termination and data reception during + * transmission. These GPIOs are controlled by the serial core independently + * from the UART driver. + */ +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) @@ -1411,7 +1418,7 @@ static int uart_rs485_config(struct uart_port *port) return 0; 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, NULL, rs485); @@ -1455,7 +1462,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

[PATCH 5.15] xfs: don't expose internal symlink metadata buffers to the vfs

by Leah Rumancik

From: "Darrick J. Wong" <djwong(a)kernel.org> [ Upstream commit 7b7820b83f230036fc48c3e7fb280c48c58adebf ] Ian Kent reported that for inline symlinks, it's possible for vfs_readlink to hang on to the target buffer returned by _vn_get_link_inline long after it's been freed by xfs inode reclaim. This is a layering violation -- we should never expose XFS internals to the VFS. When the symlink has a remote target, we allocate a separate buffer, copy the internal information, and let the VFS manage the new buffer's lifetime. Let's adapt the inline code paths to do this too. It's less efficient, but fixes the layering violation and avoids the need to adapt the if_data lifetime to rcu rules. Clearly I don't care about readlink benchmarks. As a side note, this fixes the minor locking violation where we can access the inode data fork without taking any locks; proper locking (and eliminating the possibility of having to switch inode_operations on a live inode) is essential to online repair coordinating repairs correctly. Reported-by: Ian Kent <raven(a)themaw.net> Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Dave Chinner <dchinner(a)redhat.com> Tested-by: Chandan Babu R <chandanbabu(a)kernel.org> Acked-by: Leah Rumancik <leah.rumancik(a)gmail.com> --- fs/xfs/xfs_iops.c | 34 +--------------------------------- fs/xfs/xfs_symlink.c | 29 +++++++++++++++++++---------- 2 files changed, 20 insertions(+), 43 deletions(-) diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index 1eb71275e5b0..8696d6551200 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -511,27 +511,6 @@ xfs_vn_get_link( return ERR_PTR(error); } -STATIC const char * -xfs_vn_get_link_inline( - struct dentry *dentry, - struct inode *inode, - struct delayed_call *done) -{ - struct xfs_inode *ip = XFS_I(inode); - char *link; - - ASSERT(ip->i_df.if_format == XFS_DINODE_FMT_LOCAL); - - /* - * The VFS crashes on a NULL pointer, so return -EFSCORRUPTED if - * if_data is junk. - */ - link = ip->i_df.if_u1.if_data; - if (XFS_IS_CORRUPT(ip->i_mount, !link)) - return ERR_PTR(-EFSCORRUPTED); - return link; -} - static uint32_t xfs_stat_blksize( struct xfs_inode *ip) @@ -1200,14 +1179,6 @@ static const struct inode_operations xfs_symlink_inode_operations = { .update_time = xfs_vn_update_time, }; -static const struct inode_operations xfs_inline_symlink_inode_operations = { - .get_link = xfs_vn_get_link_inline, - .getattr = xfs_vn_getattr, - .setattr = xfs_vn_setattr, - .listxattr = xfs_vn_listxattr, - .update_time = xfs_vn_update_time, -}; - /* Figure out if this file actually supports DAX. */ static bool xfs_inode_supports_dax( @@ -1358,10 +1329,7 @@ xfs_setup_iops( inode->i_fop = &xfs_dir_file_operations; break; case S_IFLNK: - if (ip->i_df.if_format == XFS_DINODE_FMT_LOCAL) - inode->i_op = &xfs_inline_symlink_inode_operations; - else - inode->i_op = &xfs_symlink_inode_operations; + inode->i_op = &xfs_symlink_inode_operations; break; default: inode->i_op = &xfs_inode_operations; diff --git a/fs/xfs/xfs_symlink.c b/fs/xfs/xfs_symlink.c index a31d2e5d0321..affbedf78160 100644 --- a/fs/xfs/xfs_symlink.c +++ b/fs/xfs/xfs_symlink.c @@ -22,6 +22,7 @@ #include "xfs_trace.h" #include "xfs_trans.h" #include "xfs_ialloc.h" +#include "xfs_error.h" /* ----- Kernel only functions below ----- */ int @@ -96,17 +97,15 @@ xfs_readlink_bmap_ilocked( int xfs_readlink( - struct xfs_inode *ip, - char *link) + struct xfs_inode *ip, + char *link) { - struct xfs_mount *mp = ip->i_mount; - xfs_fsize_t pathlen; - int error = 0; + struct xfs_mount *mp = ip->i_mount; + xfs_fsize_t pathlen; + int error = -EFSCORRUPTED; trace_xfs_readlink(ip); - ASSERT(ip->i_df.if_format != XFS_DINODE_FMT_LOCAL); - if (xfs_is_shutdown(mp)) return -EIO; @@ -121,12 +120,22 @@ xfs_readlink( __func__, (unsigned long long) ip->i_ino, (long long) pathlen); ASSERT(0); - error = -EFSCORRUPTED; goto out; } - - error = xfs_readlink_bmap_ilocked(ip, link); + if (ip->i_df.if_format == XFS_DINODE_FMT_LOCAL) { + /* + * The VFS crashes on a NULL pointer, so return -EFSCORRUPTED + * if if_data is junk. + */ + if (XFS_IS_CORRUPT(ip->i_mount, !ip->i_df.if_u1.if_data)) + goto out; + + memcpy(link, ip->i_df.if_u1.if_data, pathlen + 1); + error = 0; + } else { + error = xfs_readlink_bmap_ilocked(ip, link); + } out: xfs_iunlock(ip, XFS_ILOCK_SHARED); -- 2.42.0.655.g421f12c284-goog

1 year, 3 months

1
0
0 0

[request for patch inclusion to 5.15 stable] cifs: fix mid leak during reconnection after timeout threshold

by Shyam Prasad N

Hi Greg, It recently came to my attention that this patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?i… [Upstream commit 69cba9d3c1284e0838ae408830a02c4a063104bc] ... which is marked with Fixes tag for a change that went into 5.9 kernel, was taken into 6.4 and 6.1 stable trees. However, I do not see this in the 5.15 stable tree. I got emails about this fix being taken to the 6.4 and 6.1 stable. But I do not see any communication about 5.15 kernel. Was this missed? Or is there something in the process that I missed? Based on the kernel documentation about commit tags, I assumed that for commits that have the "Fixes: " tag, it was not necessary to add the "CC: stable" as well. Please let me know if that understanding is wrong. Regarding this particular fix, I discussed this with Steve, and he agrees that this fix needs to go into all stable kernels as well. -- Regards, Shyam

1 year, 3 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023