October 2024 - Linux-stable-mirror

[PATCH v2 01/13] iio: chemical: bme680: Fix missing header

by Vasileios Amoiridis

Add the linux/regmap.h header since the struct regmap_config is used in this file. Cc: <Stable(a)vger.kernel.org> Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor") Signed-off-by: Vasileios Amoiridis <vassilisamir(a)gmail.com> --- drivers/iio/chemical/bme680.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/chemical/bme680.h b/drivers/iio/chemical/bme680.h index b2c547ac8d34..dc9ff477da34 100644 --- a/drivers/iio/chemical/bme680.h +++ b/drivers/iio/chemical/bme680.h @@ -2,6 +2,8 @@ #ifndef BME680_H_ #define BME680_H_ +#include <linux/regmap.h> + #define BME680_REG_CHIP_ID 0xD0 #define BME680_CHIP_ID_VAL 0x61 #define BME680_REG_SOFT_RESET 0xE0 -- 2.43.0

1 week

3
2
0 0

[tip: timers/urgent] posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone

by tip-bot2 for Benjamin Segall

The following commit has been merged into the timers/urgent branch of tip: Commit-ID: b5413156bad91dc2995a5c4eab1b05e56914638a Gitweb: https://git.kernel.org/tip/b5413156bad91dc2995a5c4eab1b05e56914638a Author: Benjamin Segall <bsegall(a)google.com> AuthorDate: Fri, 25 Oct 2024 18:35:35 -07:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Sun, 27 Oct 2024 10:36:04 +01:00 posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone When cloning a new thread, its posix_cputimers are not inherited, and are cleared by posix_cputimers_init(). However, this does not clear the tick dependency it creates in tsk->tick_dep_mask, and the handler does not reach the code to clear the dependency if there were no timers to begin with. Thus if a thread has a cputimer running before clone/fork, all descendants will prevent nohz_full unless they create a cputimer of their own. Fix this by entirely clearing the tick_dep_mask in copy_process(). (There is currently no inherited state that needs a tick dependency) Process-wide timers do not have this problem because fork does not copy signal_struct as a baseline, it creates one from scratch. Fixes: b78783000d5c ("posix-cpu-timers: Migrate to use new tick dependency mask model") Signed-off-by: Ben Segall <bsegall(a)google.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Frederic Weisbecker <frederic(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/xm26o737bq8o.fsf@google.com --- include/linux/tick.h | 8 ++++++++ kernel/fork.c | 2 ++ 2 files changed, 10 insertions(+) diff --git a/include/linux/tick.h b/include/linux/tick.h index 7274463..99c9c5a 100644 --- a/include/linux/tick.h +++ b/include/linux/tick.h @@ -251,12 +251,19 @@ static inline void tick_dep_set_task(struct task_struct *tsk, if (tick_nohz_full_enabled()) tick_nohz_dep_set_task(tsk, bit); } + static inline void tick_dep_clear_task(struct task_struct *tsk, enum tick_dep_bits bit) { if (tick_nohz_full_enabled()) tick_nohz_dep_clear_task(tsk, bit); } + +static inline void tick_dep_init_task(struct task_struct *tsk) +{ + atomic_set(&tsk->tick_dep_mask, 0); +} + static inline void tick_dep_set_signal(struct task_struct *tsk, enum tick_dep_bits bit) { @@ -290,6 +297,7 @@ static inline void tick_dep_set_task(struct task_struct *tsk, enum tick_dep_bits bit) { } static inline void tick_dep_clear_task(struct task_struct *tsk, enum tick_dep_bits bit) { } +static inline void tick_dep_init_task(struct task_struct *tsk) { } static inline void tick_dep_set_signal(struct task_struct *tsk, enum tick_dep_bits bit) { } static inline void tick_dep_clear_signal(struct signal_struct *signal, diff --git a/kernel/fork.c b/kernel/fork.c index 89ceb4a..6fa9fe6 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -105,6 +105,7 @@ #include <linux/rseq.h> #include <uapi/linux/pidfd.h> #include <linux/pidfs.h> +#include <linux/tick.h> #include <asm/pgalloc.h> #include <linux/uaccess.h> @@ -2292,6 +2293,7 @@ __latent_entropy struct task_struct *copy_process( acct_clear_integrals(p); posix_cputimers_init(&p->posix_cputimers); + tick_dep_init_task(p); p->io_context = NULL; audit_set_context(p, NULL);

1 week

1
0
0 0

[PATCH v2] iio: invensense: fix multiple odr switch when FIFO is off

by Jean-Baptiste Maneyrol via B4 Relay

From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> When multiple ODR switch happens during FIFO off, the change could not be taken into account if you get back to previous FIFO on value. For example, if you run sensor buffer at 50Hz, stop, change to 200Hz, then back to 50Hz and restart buffer, data will be timestamped at 200Hz. This due to testing against mult and not new_mult. To prevent this, let's just run apply_odr automatically when FIFO is off. It will also simplify driver code. Update inv_mpu6050 and inv_icm42600 to delete now useless apply_odr. Fixes: 95444b9eeb8c ("iio: invensense: fix odr switching to same value") Cc: stable(a)vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> --- Changes in v2: - Delete unused anymore local variables. - Link to v1: https://lore.kernel.org/r/20241017-invn-inv-sensors-timestamp-fix-switch-fi… --- drivers/iio/common/inv_sensors/inv_sensors_timestamp.c | 4 ++++ drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c | 2 -- drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c | 3 --- drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 1 - 4 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c b/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c index f44458c380d92823ce2e7e5f78ca877ea4c06118..37d0bdaa8d824f79dcd2f341be7501d249926951 100644 --- a/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c +++ b/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c @@ -70,6 +70,10 @@ int inv_sensors_timestamp_update_odr(struct inv_sensors_timestamp *ts, if (mult != ts->mult) ts->new_mult = mult; + /* When FIFO is off, directly apply the new ODR */ + if (!fifo) + inv_sensors_timestamp_apply_odr(ts, 0, 0, 0); + return 0; } EXPORT_SYMBOL_NS_GPL(inv_sensors_timestamp_update_odr, IIO_INV_SENSORS_TIMESTAMP); diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c index 56ac198142500a2e1fc40b62cdd465cc736d8bf0..7968aa27f9fd798f206e72891f1c9b483811dea2 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c @@ -200,7 +200,6 @@ static int inv_icm42600_accel_update_scan_mode(struct iio_dev *indio_dev, { struct inv_icm42600_state *st = iio_device_get_drvdata(indio_dev); struct inv_icm42600_sensor_state *accel_st = iio_priv(indio_dev); - struct inv_sensors_timestamp *ts = &accel_st->ts; struct inv_icm42600_sensor_conf conf = INV_ICM42600_SENSOR_CONF_INIT; unsigned int fifo_en = 0; unsigned int sleep_temp = 0; @@ -229,7 +228,6 @@ static int inv_icm42600_accel_update_scan_mode(struct iio_dev *indio_dev, } /* update data FIFO write */ - inv_sensors_timestamp_apply_odr(ts, 0, 0, 0); ret = inv_icm42600_buffer_set_fifo_en(st, fifo_en | st->fifo.en); out_unlock: diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c index 938af5b640b00f58d2b8185f752c4755edfb0d25..c6bb68bf5e1449d4b961ac962311cbc5aa3c0a97 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c @@ -99,8 +99,6 @@ static int inv_icm42600_gyro_update_scan_mode(struct iio_dev *indio_dev, const unsigned long *scan_mask) { struct inv_icm42600_state *st = iio_device_get_drvdata(indio_dev); - struct inv_icm42600_sensor_state *gyro_st = iio_priv(indio_dev); - struct inv_sensors_timestamp *ts = &gyro_st->ts; struct inv_icm42600_sensor_conf conf = INV_ICM42600_SENSOR_CONF_INIT; unsigned int fifo_en = 0; unsigned int sleep_gyro = 0; @@ -128,7 +126,6 @@ static int inv_icm42600_gyro_update_scan_mode(struct iio_dev *indio_dev, } /* update data FIFO write */ - inv_sensors_timestamp_apply_odr(ts, 0, 0, 0); ret = inv_icm42600_buffer_set_fifo_en(st, fifo_en | st->fifo.en); out_unlock: diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c index 3bfeabab0ec4f6fa28fbbcd47afe92af5b8a58e2..5b1088cc3704f1ad1288a0d65b2f957b91455d7f 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c @@ -112,7 +112,6 @@ int inv_mpu6050_prepare_fifo(struct inv_mpu6050_state *st, bool enable) if (enable) { /* reset timestamping */ inv_sensors_timestamp_reset(&st->timestamp); - inv_sensors_timestamp_apply_odr(&st->timestamp, 0, 0, 0); /* reset FIFO */ d = st->chip_config.user_ctrl | INV_MPU6050_BIT_FIFO_RST; ret = regmap_write(st->map, st->reg->user_ctrl, d); --- base-commit: c3e9df514041ec6c46be83801b1891392f4522f7 change-id: 20241017-invn-inv-sensors-timestamp-fix-switch-fifo-off-3f29110e95d0 Best regards, -- Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com>

1 week

2
1
0 0

Concerns over transparency of informal kernel groups

by Jiaxun Yang

Dear Linux Community Members, Over the years, various informal groups have formed within our community, serving purposes such as maintaining connections with companies and external bodies, handling sensitive information, making challenging decisions, and, at times, representing the community as a whole. These groups contribute significantly to our community's development and deserve our recognition and appreciation. I'll name a few below that I identified from `Documentation/`: - Code of Conduct Committee <conduct(a)kernel.org> - Linux kernel security team <security(a)kernel.org> - Linux kernel hardware security team <hardware-security(a)kernel.org> - Kernel CVE assignment team <cve(a)kernel.org> - Stable Team for unpublished vulnerabilities <stable(a)kernel.org> (I suspect it's just an alias to regular stable team, but I found no evidence). Over recent events, I've taken a closer look at how our community's governance operates, only to find that there's remarkably little public information available about those informal groups. With the exception of the Linux kernel hardware security team, it seems none of these groups maintain a public list of members that I can easily find. Upon digging into the details, I’d like to raise a few concerns and offer some thoughts for further discussion: - Absence of a Membership Register Our community is built on mutual trust. Without knowing who comprises these groups, it's understandably difficult for people to have full confidence in their work. A publicly available membership list would not only foster trust but also allow us to address our recognition and appreciation. - Lack of Guidelines for Actions Many of these groups appear to operate without documented guidelines. While I trust each respectful individual's integrity, documented guidelines would enable the wider community to better understand and appreciate the roles and responsibilities involved. - Insufficient Transparency in Decision-Making I fully respect the need for confidentiality in handling security matters, yet some degree of openness around decision-making processes is essential in my opinion. Releasing communications post-embargo, for instance, could promote understanding and prevent potential abuse of confidential procedures. - No Conflict of Interest Policy Particularly in the case of the Code of Conduct Committee, there may arise situations where individuals face challenging decisions involving personal connections. A conflict of interest policy would provide valuable guidance in such circumstances. Thank you for reading. I know none of us enjoy being pulled away by these non-technical concerns, we love coding after all. However, I feel these concerns are vital for the community's continued health. It might be a candidate of Linux TAB discussion. I'm looking forward to everyone's input. Thanks - Jiaxun

1 week

5
9
0 0

[PATCH can] can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing configuration when switching CAN modes

by Marc Kleine-Budde

Since commit 50ea5449c563 ("can: mcp251xfd: fix ring configuration when switching from CAN-CC to CAN-FD mode"), the current ring and coalescing configuration is passed to can_ram_get_layout(). That fixed the issue when switching between CAN-CC and CAN-FD mode with configured ring (rx, tx) and/or coalescing parameters (rx-frames-irq, tx-frames-irq). However 50ea5449c563 ("can: mcp251xfd: fix ring configuration when switching from CAN-CC to CAN-FD mode"), introduced a regression when switching CAN modes with disabled coalescing configuration: Even if the previous CAN mode has no coalescing configured, the new mode is configured with active coalescing. This leads to delayed receiving of CAN-FD frames. This comes from the fact, that ethtool uses usecs = 0 and max_frames = 1 to disable coalescing, however the driver uses internally priv->{rx,tx}_obj_num_coalesce_irq = 0 to indicate disabled coalescing. Fix the regression by assigning struct ethtool_coalesce ec->{rx,tx}_max_coalesced_frames_irq = 1 if coalescing is disabled in the driver as can_ram_get_layout() expects this. Reported-by: https://github.com/vdh-robothania Closes: https://github.com/raspberrypi/linux/issues/6407 Fixes: 50ea5449c563 ("can: mcp251xfd: fix ring configuration when switching from CAN-CC to CAN-FD mode") Cc: stable(a)vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/spi/mcp251xfd/mcp251xfd-ring.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-ring.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-ring.c index e684991fa3917d4f6b6ebda8329f72971237574e..7209a831f0f2089e409c6be635f0e5dc7b2271da 100644 --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-ring.c +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-ring.c @@ -2,7 +2,7 @@ // // mcp251xfd - Microchip MCP251xFD Family CAN controller driver // -// Copyright (c) 2019, 2020, 2021 Pengutronix, +// Copyright (c) 2019, 2020, 2021, 2024 Pengutronix, // Marc Kleine-Budde <kernel(a)pengutronix.de> // // Based on: @@ -483,9 +483,11 @@ int mcp251xfd_ring_alloc(struct mcp251xfd_priv *priv) }; const struct ethtool_coalesce ec = { .rx_coalesce_usecs_irq = priv->rx_coalesce_usecs_irq, - .rx_max_coalesced_frames_irq = priv->rx_obj_num_coalesce_irq, + .rx_max_coalesced_frames_irq = priv->rx_obj_num_coalesce_irq == 0 ? + 1 : priv->rx_obj_num_coalesce_irq, .tx_coalesce_usecs_irq = priv->tx_coalesce_usecs_irq, - .tx_max_coalesced_frames_irq = priv->tx_obj_num_coalesce_irq, + .tx_max_coalesced_frames_irq = priv->tx_obj_num_coalesce_irq == 0 ? + 1 : priv->tx_obj_num_coalesce_irq, }; struct can_ram_layout layout; --- base-commit: 9efc44fb2dba6138b0575826319200049078679a change-id: 20241010-mcp251xfd-fix-coalesing-f373066dd42e Best regards, -- Marc Kleine-Budde <mkl(a)pengutronix.de>

1 week, 1 day

2
1
0 0

[PATCHSET v5.1 3/9] xfs: metadata inode directory trees

by Darrick J. Wong

Hi all, This series delivers a new feature -- metadata inode directories. This is a separate directory tree (rooted in the superblock) that contains only inodes that contain filesystem metadata. Different metadata objects can be looked up with regular paths. Start by creating xfs_imeta{dir,file}* functions to mediate access to the metadata directory tree. By the end of this mega series, all existing metadata inodes (rt+quota) will use this directory tree instead of the superblock. Next, define the metadir on-disk format, which consists of marking inodes with a new iflag that says they're metadata. This prevents bulkstat and friends from ever getting their hands on fs metadata files. If you're going to start using this code, I strongly recommend pulling from my git trees, which are linked below. This has been running on the djcloud for months with no problems. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=me… xfsprogs git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h… --- Commits in this patchset: * xfs: constify the xfs_sb predicates * xfs: constify the xfs_inode predicates * xfs: rename metadata inode predicates * xfs: standardize EXPERIMENTAL warning generation * xfs: define the on-disk format for the metadir feature * xfs: iget for metadata inodes * xfs: load metadata directory root at mount time * xfs: enforce metadata inode flag * xfs: read and write metadata inode directory tree * xfs: disable the agi rotor for metadata inodes * xfs: hide metadata inodes from everyone because they are special * xfs: advertise metadata directory feature * xfs: allow bulkstat to return metadata directories * xfs: don't count metadata directory files to quota * xfs: mark quota inodes as metadata files * xfs: adjust xfs_bmap_add_attrfork for metadir * xfs: record health problems with the metadata directory * xfs: refactor directory tree root predicates * xfs: do not count metadata directory files when doing online quotacheck * xfs: don't fail repairs on metadata files with no attr fork * xfs: metadata files can have xattrs if metadir is enabled * xfs: adjust parent pointer scrubber for sb-rooted metadata files * xfs: fix di_metatype field of inodes that won't load * xfs: scrub metadata directories * xfs: check the metadata directory inumber in superblocks * xfs: move repair temporary files to the metadata directory tree * xfs: check metadata directory file path connectivity * xfs: confirm dotdot target before replacing it during a repair * xfs: repair metadata directory file path connectivity --- fs/xfs/Makefile | 5 fs/xfs/libxfs/xfs_attr.c | 5 fs/xfs/libxfs/xfs_bmap.c | 5 fs/xfs/libxfs/xfs_format.h | 121 +++++++-- fs/xfs/libxfs/xfs_fs.h | 25 ++ fs/xfs/libxfs/xfs_health.h | 6 fs/xfs/libxfs/xfs_ialloc.c | 58 +++- fs/xfs/libxfs/xfs_inode_buf.c | 90 ++++++- fs/xfs/libxfs/xfs_inode_buf.h | 3 fs/xfs/libxfs/xfs_inode_util.c | 2 fs/xfs/libxfs/xfs_log_format.h | 2 fs/xfs/libxfs/xfs_metadir.c | 481 ++++++++++++++++++++++++++++++++++++ fs/xfs/libxfs/xfs_metadir.h | 47 ++++ fs/xfs/libxfs/xfs_metafile.c | 52 ++++ fs/xfs/libxfs/xfs_metafile.h | 31 ++ fs/xfs/libxfs/xfs_ondisk.h | 2 fs/xfs/libxfs/xfs_sb.c | 12 + fs/xfs/libxfs/xfs_types.c | 4 fs/xfs/libxfs/xfs_types.h | 2 fs/xfs/scrub/agheader.c | 5 fs/xfs/scrub/common.c | 65 ++++- fs/xfs/scrub/common.h | 5 fs/xfs/scrub/dir.c | 10 + fs/xfs/scrub/dir_repair.c | 20 + fs/xfs/scrub/dirtree.c | 32 ++ fs/xfs/scrub/dirtree.h | 12 - fs/xfs/scrub/findparent.c | 28 ++ fs/xfs/scrub/health.c | 1 fs/xfs/scrub/inode.c | 35 ++- fs/xfs/scrub/inode_repair.c | 34 ++- fs/xfs/scrub/metapath.c | 521 +++++++++++++++++++++++++++++++++++++++ fs/xfs/scrub/nlinks.c | 4 fs/xfs/scrub/nlinks_repair.c | 4 fs/xfs/scrub/orphanage.c | 4 fs/xfs/scrub/parent.c | 39 ++- fs/xfs/scrub/parent_repair.c | 37 ++- fs/xfs/scrub/quotacheck.c | 7 - fs/xfs/scrub/refcount_repair.c | 2 fs/xfs/scrub/repair.c | 22 +- fs/xfs/scrub/repair.h | 3 fs/xfs/scrub/scrub.c | 12 + fs/xfs/scrub/scrub.h | 2 fs/xfs/scrub/stats.c | 1 fs/xfs/scrub/tempfile.c | 105 ++++++++ fs/xfs/scrub/tempfile.h | 3 fs/xfs/scrub/trace.c | 1 fs/xfs/scrub/trace.h | 42 +++ fs/xfs/xfs_dquot.c | 1 fs/xfs/xfs_fsops.c | 4 fs/xfs/xfs_health.c | 2 fs/xfs/xfs_icache.c | 74 ++++++ fs/xfs/xfs_inode.c | 19 + fs/xfs/xfs_inode.h | 36 ++- fs/xfs/xfs_inode_item.c | 7 - fs/xfs/xfs_inode_item_recover.c | 2 fs/xfs/xfs_ioctl.c | 7 + fs/xfs/xfs_iops.c | 15 + fs/xfs/xfs_itable.c | 33 ++ fs/xfs/xfs_itable.h | 3 fs/xfs/xfs_message.c | 47 ++++ fs/xfs/xfs_message.h | 19 + fs/xfs/xfs_mount.c | 31 ++ fs/xfs/xfs_mount.h | 11 + fs/xfs/xfs_qm.c | 36 +++ fs/xfs/xfs_quota.h | 5 fs/xfs/xfs_rtalloc.c | 38 ++- fs/xfs/xfs_super.c | 13 - fs/xfs/xfs_trace.c | 2 fs/xfs/xfs_trace.h | 102 ++++++++ fs/xfs/xfs_trans_dquot.c | 6 fs/xfs/xfs_xattr.c | 3 71 files changed, 2324 insertions(+), 201 deletions(-) create mode 100644 fs/xfs/libxfs/xfs_metadir.c create mode 100644 fs/xfs/libxfs/xfs_metadir.h create mode 100644 fs/xfs/libxfs/xfs_metafile.c create mode 100644 fs/xfs/libxfs/xfs_metafile.h create mode 100644 fs/xfs/scrub/metapath.c

1 week, 1 day

3
5
0 0

Re: No sound on speakers X1 Carbon Gen 12

by Takashi Iwai

On Sun, 20 Oct 2024 17:12:14 +0200, Dean Matthew Menezes wrote: > > The first change worked to fix the sound from the speaker. Then please double-check whether my original fix in https://lore.kernel.org/87cyjzrutw.wl-tiwai@suse.de really doesn't bring back the speaker output. If it's confirmed to be broken, run as root: echo 1 > /sys/module/snd_hda_codec/parameters/dump_coef and get alsa-info.sh outputs from both working and patched-but-not-working cases again, but at this time, during the playback. (Also, please keep Cc.) thanks, Takashi

1 week, 1 day

3
15
0 0

[merged mm-hotfixes-stable] mm-avoid-unconditional-one-tick-sleep-when-swapcache_prepare-fails.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: avoid unconditional one-tick sleep when swapcache_prepare fails has been removed from the -mm tree. Its filename was mm-avoid-unconditional-one-tick-sleep-when-swapcache_prepare-fails.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: Barry Song <v-songbaohua(a)oppo.com> Subject: mm: avoid unconditional one-tick sleep when swapcache_prepare fails Date: Fri, 27 Sep 2024 09:19:36 +1200 Commit 13ddaf26be32 ("mm/swap: fix race when skipping swapcache") introduced an unconditional one-tick sleep when `swapcache_prepare()` fails, which has led to reports of UI stuttering on latency-sensitive Android devices. To address this, we can use a waitqueue to wake up tasks that fail `swapcache_prepare()` sooner, instead of always sleeping for a full tick. While tasks may occasionally be woken by an unrelated `do_swap_page()`, this method is preferable to two scenarios: rapid re-entry into page faults, which can cause livelocks, and multiple millisecond sleeps, which visibly degrade user experience. Oven's testing shows that a single waitqueue resolves the UI stuttering issue. If a 'thundering herd' problem becomes apparent later, a waitqueue hash similar to `folio_wait_table[PAGE_WAIT_TABLE_SIZE]` for page bit locks can be introduced. [v-songbaohua(a)oppo.com: wake_up only when swapcache_wq waitqueue is active] Link: https://lkml.kernel.org/r/20241008130807.40833-1-21cnbao@gmail.com Link: https://lkml.kernel.org/r/20240926211936.75373-1-21cnbao@gmail.com Fixes: 13ddaf26be32 ("mm/swap: fix race when skipping swapcache") Signed-off-by: Barry Song <v-songbaohua(a)oppo.com> Reported-by: Oven Liyang <liyangouwen1(a)oppo.com> Tested-by: Oven Liyang <liyangouwen1(a)oppo.com> Cc: Kairui Song <kasong(a)tencent.com> Cc: "Huang, Ying" <ying.huang(a)intel.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Yosry Ahmed <yosryahmed(a)google.com> Cc: SeongJae Park <sj(a)kernel.org> Cc: Kalesh Singh <kaleshsingh(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/mm/memory.c~mm-avoid-unconditional-one-tick-sleep-when-swapcache_prepare-fails +++ a/mm/memory.c @@ -4187,6 +4187,8 @@ static struct folio *alloc_swap_folio(st } #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +static DECLARE_WAIT_QUEUE_HEAD(swapcache_wq); + /* * We enter with non-exclusive mmap_lock (to exclude vma changes, * but allow concurrent faults), and pte mapped but not yet locked. @@ -4199,6 +4201,7 @@ vm_fault_t do_swap_page(struct vm_fault { struct vm_area_struct *vma = vmf->vma; struct folio *swapcache, *folio = NULL; + DECLARE_WAITQUEUE(wait, current); struct page *page; struct swap_info_struct *si = NULL; rmap_t rmap_flags = RMAP_NONE; @@ -4297,7 +4300,9 @@ vm_fault_t do_swap_page(struct vm_fault * Relax a bit to prevent rapid * repeated page faults. */ + add_wait_queue(&swapcache_wq, &wait); schedule_timeout_uninterruptible(1); + remove_wait_queue(&swapcache_wq, &wait); goto out_page; } need_clear_cache = true; @@ -4604,8 +4609,11 @@ unlock: pte_unmap_unlock(vmf->pte, vmf->ptl); out: /* Clear the swap cache pin for direct swapin after PTL unlock */ - if (need_clear_cache) + if (need_clear_cache) { swapcache_clear(si, entry, nr_pages); + if (waitqueue_active(&swapcache_wq)) + wake_up(&swapcache_wq); + } if (si) put_swap_device(si); return ret; @@ -4620,8 +4628,11 @@ out_release: folio_unlock(swapcache); folio_put(swapcache); } - if (need_clear_cache) + if (need_clear_cache) { swapcache_clear(si, entry, nr_pages); + if (waitqueue_active(&swapcache_wq)) + wake_up(&swapcache_wq); + } if (si) put_swap_device(si); return ret; _ Patches currently in -mm which might be from v-songbaohua(a)oppo.com are mm-fix-pswpin-counter-for-large-folios-swap-in.patch

1 week, 1 day

1
0
0 0

+ mm-mmap-limit-thp-aligment-of-anonymous-mappings-to-pmd-aligned-sizes.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm, mmap: limit THP aligment of anonymous mappings to PMD-aligned sizes has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-mmap-limit-thp-aligment-of-anonymous-mappings-to-pmd-aligned-sizes.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Vlastimil Babka <vbabka(a)suse.cz> Subject: mm, mmap: limit THP aligment of anonymous mappings to PMD-aligned sizes Date: Thu, 24 Oct 2024 17:12:29 +0200 Since commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") a mmap() of anonymous memory without a specific address hint and of at least PMD_SIZE will be aligned to PMD so that it can benefit from a THP backing page. However this change has been shown to regress some workloads significantly. [1] reports regressions in various spec benchmarks, with up to 600% slowdown of the cactusBSSN benchmark on some platforms. The benchmark seems to create many mappings of 4632kB, which would have merged to a large THP-backed area before commit efa7df3e3bb5 and now they are fragmented to multiple areas each aligned to PMD boundary with gaps between. The regression then seems to be caused mainly due to the benchmark's memory access pattern suffering from TLB or cache aliasing due to the aligned boundaries of the individual areas. Another known regression bisected to commit efa7df3e3bb5 is darktable [2] [3] and early testing suggests this patch fixes the regression there as well. To fix the regression but still try to benefit from THP-friendly anonymous mapping alignment, add a condition that the size of the mapping must be a multiple of PMD size instead of at least PMD size. In case of many odd-sized mapping like the cactusBSSN creates, those will stop being aligned and with gaps between, and instead naturally merge again. Link: https://lkml.kernel.org/r/20241024151228.101841-2-vbabka@suse.cz Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Reported-by: Michael Matz <matz(a)suse.de> Debugged-by: Gabriel Krisman Bertazi <gabriel(a)krisman.be> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1229012 [1] Reported-by: Matthias Bodenbinder <matthias(a)bodenbinder.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219366 [2] Closes: https://lore.kernel.org/all/2050f0d4-57b0-481d-bab8-05e8d48fed0c@leemhuis.i… [3] Cc: Rik van Riel <riel(a)surriel.com> Cc: Yang Shi <yang(a)os.amperecomputing.com> Cc: Jann Horn <jannh(a)google.com> Cc: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Petr Tesarik <ptesarik(a)suse.com> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mmap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/mm/mmap.c~mm-mmap-limit-thp-aligment-of-anonymous-mappings-to-pmd-aligned-sizes +++ a/mm/mmap.c @@ -900,7 +900,8 @@ __get_unmapped_area(struct file *file, u if (get_area) { addr = get_area(file, addr, len, pgoff, flags); - } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { + } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) + && IS_ALIGNED(len, PMD_SIZE)) { /* Ensures that larger anonymous mappings are THP aligned. */ addr = thp_get_unmapped_area_vmflags(file, addr, len, pgoff, flags, vm_flags); _ Patches currently in -mm which might be from vbabka(a)suse.cz are mm-mmap-limit-thp-aligment-of-anonymous-mappings-to-pmd-aligned-sizes.patch

1 week, 1 day

1
0
0 0

+ mm-shrinker-avoid-memleak-in-alloc_shrinker_info.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: shrinker: avoid memleak in alloc_shrinker_info has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-shrinker-avoid-memleak-in-alloc_shrinker_info.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Chen Ridong <chenridong(a)huawei.com> Subject: mm: shrinker: avoid memleak in alloc_shrinker_info Date: Fri, 25 Oct 2024 06:09:42 +0000 A memleak was found as below: unreferenced object 0xffff8881010d2a80 (size 32): comm "mkdir", pid 1559, jiffies 4294932666 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 @............... backtrace (crc 2e7ef6fa): [<ffffffff81372754>] __kmalloc_node_noprof+0x394/0x470 [<ffffffff813024ab>] alloc_shrinker_info+0x7b/0x1a0 [<ffffffff813b526a>] mem_cgroup_css_online+0x11a/0x3b0 [<ffffffff81198dd9>] online_css+0x29/0xa0 [<ffffffff811a243d>] cgroup_apply_control_enable+0x20d/0x360 [<ffffffff811a5728>] cgroup_mkdir+0x168/0x5f0 [<ffffffff8148543e>] kernfs_iop_mkdir+0x5e/0x90 [<ffffffff813dbb24>] vfs_mkdir+0x144/0x220 [<ffffffff813e1c97>] do_mkdirat+0x87/0x130 [<ffffffff813e1de9>] __x64_sys_mkdir+0x49/0x70 [<ffffffff81f8c928>] do_syscall_64+0x68/0x140 [<ffffffff8200012f>] entry_SYSCALL_64_after_hwframe+0x76/0x7e alloc_shrinker_info(), when shrinker_unit_alloc() returns an errer, the info won't be freed. Just fix it. Link: https://lkml.kernel.org/r/20241025060942.1049263-1-chenridong@huaweicloud.c… Fixes: 307bececcd12 ("mm: shrinker: add a secondary array for shrinker_info::{map, nr_deferred}") Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Acked-by: Qi Zheng <zhengqi.arch(a)bytedance.com> Acked-by: Roman Gushchin <roman.gushchin(a)linux.dev> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Anshuman Khandual <anshuman.khandual(a)arm.com> Cc: Dave Chinner <david(a)fromorbit.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Wang Weiyang <wangweiyang2(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shrinker.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/mm/shrinker.c~mm-shrinker-avoid-memleak-in-alloc_shrinker_info +++ a/mm/shrinker.c @@ -76,19 +76,21 @@ void free_shrinker_info(struct mem_cgrou int alloc_shrinker_info(struct mem_cgroup *memcg) { - struct shrinker_info *info; int nid, ret = 0; int array_size = 0; mutex_lock(&shrinker_mutex); array_size = shrinker_unit_size(shrinker_nr_max); for_each_node(nid) { - info = kvzalloc_node(sizeof(*info) + array_size, GFP_KERNEL, nid); + struct shrinker_info *info = kvzalloc_node(sizeof(*info) + array_size, + GFP_KERNEL, nid); if (!info) goto err; info->map_nr_max = shrinker_nr_max; - if (shrinker_unit_alloc(info, NULL, nid)) + if (shrinker_unit_alloc(info, NULL, nid)) { + kvfree(info); goto err; + } rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_info, info); } mutex_unlock(&shrinker_mutex); _ Patches currently in -mm which might be from chenridong(a)huawei.com are mm-shrinker-avoid-memleak-in-alloc_shrinker_info.patch

1 week, 1 day

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024