6.5.6-rc1 review
Subsystems (9)
Greg Kroah-Hartman
maintainerPATCH 292/321 btrfs: set last dir index to the current last index when opening dir
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 357950361cbc6d54fb68ed878265c647384684ae upstream.
When opening a directory for reading it, we set the last index where we stop iteration to the value in struct btrfs_inode::index_cnt. That value does not match the index of the most recently added directory entry but it's instead the index number that will be assigned the next directory entry.
This means that if after the call to opendir(3) new directory entries are added, a readdir(3) call will return the first new directory entry. This is fine because POSIX says the following [1]:
"If a file is removed from or added to the directory after the most
recent call to opendir() or rewinddir(), whether a subsequent call to readdir() returns an entry for that file is unspecified."
For example for the test script from commit 9b378f6ad48c ("btrfs: fix infinite directory reads"), where we have 2000 files in a directory, ext4 doesn't return any new directory entry after opendir(3), while xfs returns the first 13 new directory entries added after the opendir(3) call.
If we move to a shorter example with an empty directory when opendir(3) is called, and 2 files added to the directory after the opendir(3) call, then readdir(3) on btrfs will return the first file, ext4 and xfs return the 2 files (but in a different order). A test program for this, reported by Ian Johnson, is the following:
#include <dirent.h>
#include <stdio.h>
int main(void) {
DIR *dir = opendir("test"); FILE *file;
file = fopen("test/1", "w");
fwrite("1", 1, 1, file);
fclose(file);
file = fopen("test/2", "w");
fwrite("2", 1, 1, file);
fclose(file);
struct dirent *entry;
while ((entry = readdir(dir))) {
printf("%s\n", entry->d_name);
}
closedir(dir);
return 0;}
To make this less odd, change the behaviour to never return new entries that were added after the opendir(3) call. This is done by setting the last_index field of the struct btrfs_file_private attached to the directory's file handle with a value matching btrfs_inode::index_cnt minus 1, since that value always matches the index of the next new directory entry and not the index of the most recently added entry.
[1] https://pubs.opengroup.org/onlinepubs/007904875/functions/readdir_r.html
--- fs/btrfs/inode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/btrfs/inode.c +2 -1
@@ -5942,7 +5942,8 @@ static int btrfs_get_dir_last_index(stru } } - *index = dir->index_cnt; +/* index_cnt is the index number of next new entry, so decrement it. */ + *index = dir->index_cnt -1 ;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 293/321 btrfs: fix race between reading a directory and adding entries to it
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 8e7f82deb0c0386a03b62e30082574347f8b57d5 upstream.
When opening a directory (opendir(3)) or rewinding it (rewinddir(3)), we are not holding the directory's inode locked, and this can result in later attempting to add two entries to the directory with the same index number, resulting in a transaction abort, with -EEXIST (-17), when inserting the second delayed dir index. This results in a trace like the following:
Sep 11 22:34:59 myhostname kernel: BTRFS error (device dm-3): err add delayed dir index item(name: cockroach-stderr.log) into the insertion tree of the delayed node(root id: 5, inode id: 4539217, errno: -17) Sep 11 22:34:59 myhostname kernel: ------------[ cut here ]------------ Sep 11 22:34:59 myhostname kernel: kernel BUG at fs/btrfs/delayed-inode.c:1504! Sep 11 22:34:59 myhostname kernel: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI Sep 11 22:34:59 myhostname kernel: CPU: 0 PID: 7159 Comm: cockroach Not tainted 6.4.15-200.fc38.x86_64 #1 Sep 11 22:34:59 myhostname kernel: Hardware name: ASUS ESC500 G3/P9D WS, BIOS 2402 06/27/2018 Sep 11 22:34:59 myhostname kernel: RIP: 0010:btrfs_insert_delayed_dir_index+0x1da/0x260 Sep 11 22:34:59 myhostname kernel: Code: eb dd 48 (...) Sep 11 22:34:59 myhostname kernel: RSP: 0000:ffffa9980e0fbb28 EFLAGS: 00010282 Sep 11 22:34:59 myhostname kernel: RAX: 0000000000000000 RBX: ffff8b10b8f4a3c0 RCX: 0000000000000000 Sep 11 22:34:59 myhostname kernel: RDX: 0000000000000000 RSI: ffff8b177ec21540 RDI: ffff8b177ec21540 Sep 11 22:34:59 myhostname kernel: RBP: ffff8b110cf80888 R08: 0000000000000000 R09: ffffa9980e0fb938 Sep 11 22:34:59 myhostname kernel: R10: 0000000000000003 R11: ffffffff86146508 R12: 0000000000000014 Sep 11 22:34:59 myhostname kernel: R13: ffff8b1131ae5b40 R14: ffff8b10b8f4a418 R15: 00000000ffffffef Sep 11 22:34:59 myhostname kernel: FS: 00007fb14a7fe6c0(0000) GS:ffff8b177ec00000(0000) knlGS:0000000000000000 Sep 11 22:34:59 myhostname kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 11 22:34:59 myhostname kernel: CR2: 000000c00143d000 CR3: 00000001b3b4e002 CR4: 00000000001706f0 Sep 11 22:34:59 myhostname kernel: Call Trace: Sep 11 22:34:59 myhostname kernel: <TASK> Sep 11 22:34:59 myhostname kernel: ? die+0x36/0x90 Sep 11 22:34:59 myhostname kernel: ? do_trap+0xda/0x100 Sep 11 22:34:59 myhostname kernel: ? btrfs_insert_delayed_dir_index+0x1da/0x260 Sep 11 22:34:59 myhostname kernel: ? do_error_trap+0x6a/0x90 Sep 11 22:34:59 myhostname kernel: ? btrfs_insert_delayed_dir_index+0x1da/0x260 Sep 11 22:34:59 myhostname kernel: ? exc_invalid_op+0x50/0x70 Sep 11 22:34:59 myhostname kernel: ? btrfs_insert_delayed_dir_index+0x1da/0x260 Sep 11 22:34:59 myhostname kernel: ? asm_exc_invalid_op+0x1a/0x20 Sep 11 22:34:59 myhostname kernel: ? btrfs_insert_delayed_dir_index+0x1da/0x260 Sep 11 22:34:59 myhostname kernel: ? btrfs_insert_delayed_dir_index+0x1da/0x260 Sep 11 22:34:59 myhostname kernel: btrfs_insert_dir_item+0x200/0x280 Sep 11 22:34:59 myhostname kernel: btrfs_add_link+0xab/0x4f0 Sep 11 22:34:59 myhostname kernel: ? ktime_get_real_ts64+0x47/0xe0 Sep 11 22:34:59 myhostname kernel: btrfs_create_new_inode+0x7cd/0xa80 Sep 11 22:34:59 myhostname kernel: btrfs_symlink+0x190/0x4d0 Sep 11 22:34:59 myhostname kernel: ? schedule+0x5e/0xd0 Sep 11 22:34:59 myhostname kernel: ? __d_lookup+0x7e/0xc0 Sep 11 22:34:59 myhostname kernel: vfs_symlink+0x148/0x1e0 Sep 11 22:34:59 myhostname kernel: do_symlinkat+0x130/0x140 Sep 11 22:34:59 myhostname kernel: __x64_sys_symlinkat+0x3d/0x50 Sep 11 22:34:59 myhostname kernel: do_syscall_64+0x5d/0x90 Sep 11 22:34:59 myhostname kernel: ? syscall_exit_to_user_mode+0x2b/0x40 Sep 11 22:34:59 myhostname kernel: ? do_syscall_64+0x6c/0x90 Sep 11 22:34:59 myhostname kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc
The race leading to the problem happens like this:
1) Directory inode X is loaded into memory, its ->index_cnt field is initialized to (u64)-1 (at btrfs_alloc_inode());
2) Task A is adding a new file to directory X, holding its vfs inode lock, and calls btrfs_set_inode_index() to get an index number for the entry.
Because the inode's index_cnt field is set to (u64)-1 it calls btrfs_inode_delayed_dir_index_count() which fails because no dir index entries were added yet to the delayed inode and then it calls btrfs_set_inode_index_count(). This functions finds the last dir index key and then sets index_cnt to that index value + 1. It found that the last index key has an offset of 100. However before it assigns a value of 101 to index_cnt...
3) Task B calls opendir(3), ending up at btrfs_opendir(), where the VFS lock for inode X is not taken, so it calls btrfs_get_dir_last_index() and sees index_cnt still with a value of (u64)-1. Because of that it calls btrfs_inode_delayed_dir_index_count() which fails since no dir index entries were added to the delayed inode yet, and then it also calls btrfs_set_inode_index_count(). This also finds that the last index key has an offset of 100, and before it assigns the value 101 to the index_cnt field of inode X...
4) Task A assigns a value of 101 to index_cnt. And then the code flow goes to btrfs_set_inode_index() where it increments index_cnt from 101 to 102. Task A then creates a delayed dir index entry with a sequence number of 101 and adds it to the delayed inode;
5) Task B assigns 101 to the index_cnt field of inode X;
6) At some later point when someone tries to add a new entry to the directory, btrfs_set_inode_index() will return 101 again and shortly after an attempt to add another delayed dir index key with index number 101 will fail with -EEXIST resulting in a transaction abort.
Fix this by locking the inode at btrfs_get_dir_last_index(), which is only only used when opening a directory or attempting to lseek on it.
--- fs/btrfs/inode.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
fs/btrfs/inode.c +7 -4
@@ -5931,21 +5931,24 @@ out:static int btrfs_get_dir_last_index (struct btrfs_inode *dir,u64 *index) { -if (dir->index_cnt == (u64)-1 ) { -int ret; +int ret =0 ; +btrfs_inode_lock (dir,0 ); +if (dir->index_cnt == (u64)-1 ) { ret =btrfs_inode_delayed_dir_index_count (dir);if (ret) { ret =btrfs_set_inode_index_count (dir);if (ret) -return ret; + goto out; } }/* index_cnt is the index number of next new entry, so decrement it. */ *index = dir->index_cnt -1 ; +out: +btrfs_inode_unlock (dir,0 ); -return 0 ; +return ret; }/*
Greg Kroah-Hartman
maintainerPATCH 294/321 btrfs: properly report 0 avail for very full file systems
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 58bfe2ccec5f9f137b41dd38f335290dcc13cd5c upstream.
A user reported some issues with smaller file systems that get very full. While investigating this issue I noticed that df wasn't showing 100% full, despite having 0 chunk space and having < 1MiB of available metadata space.
This turns out to be an overflow issue, we're doing:
total_available_metadata_space - SZ_4M < global_block_rsv_size
to determine if there's not enough space to make metadata allocations, which overflows if total_available_metadata_space is < 4M. Fix this by checking to see if our available space is greater than the 4M threshold. This makes df properly report 100% usage on the file system.
--- fs/btrfs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/super.c +1 -1
@@ -2111,7 +2111,7 @@ static int btrfs_statfs(struct dentry *d* calculated f_bavail. */ if (!mixed && block_rsv->space_info->full && - total_free_meta - thresh < block_rsv->size) + (total_free_meta < thresh || total_free_meta - thresh < block_rsv->size)) buf->f_bavail =0 ; buf->f_type =BTRFS_SUPER_MAGIC ;
Greg Kroah-Hartman
maintainerPATCH 295/321 media: uvcvideo: Fix OOB read
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricardo Ribalda <[email protected]>
commit 41ebaa5e0eebea4c3bac96b72f9f8ae0d77c0bdb upstream.
If the index provided by the user is bigger than the mask size, we might do an out of bound read.
--- drivers/media/usb/uvc/uvc_ctrl.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/media/usb/uvc/uvc_ctrl.c +3 -0
@@ -1402,6 +1402,9 @@ int uvc_query_v4l2_menu(struct uvc_video query_menu->id = id; query_menu->index = index; +if (index >=BITS_PER_TYPE (mapping->menu_mask)) +return -EINVAL ; + ret =mutex_lock_interruptible (&chain->ctrl_mutex);if (ret <0 )return -ERESTARTSYS ;
Greg Kroah-Hartman
maintainerPATCH 296/321 bpf: Add override check to kprobe multi link attach
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
commit 41bc46c12a8053a1b3279a379bd6b5e87b045b85 upstream.
Currently the multi_kprobe link attach does not check error injection list for programs with bpf_override_return helper and allows them to attach anywhere. Adding the missing check.
--- kernel/trace/bpf_trace.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
kernel/trace/bpf_trace.c +16 -0
@@ -2772,6 +2772,17 @@ static int get_modules_for_addrs(structreturn arr.mods_cnt; } +static int addrs_check_error_injection_list (unsigned long *addrs,u32 cnt) +{ +u32 i; + +for (i =0 ; i < cnt; i++) { +if (!within_error_injection_list (addrs[i])) +return -EINVAL ; + } +return 0 ; +} +int bpf_kprobe_multi_link_attach (const union bpf_attr *attr,struct bpf_prog *prog) {struct bpf_kprobe_multi_link *link =NULL ;
@@ -2849,6 +2860,11 @@ int bpf_kprobe_multi_link_attach(const u goto error; } +if (prog->kprobe_override &&addrs_check_error_injection_list (addrs, cnt)) { + err = -EINVAL ; + goto error; + } + link =kzalloc (sizeof (*link),GFP_KERNEL );if (!link) { err = -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 297/321 bpf: Fix BTF_ID symbol generation collision
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
commit 8f908db77782630c45ba29dac35c434b5ce0b730 upstream.
Marcus and Satya reported an issue where BTF_ID macro generates same symbol in separate objects and that breaks final vmlinux link.
ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol '__BTF_ID__struct__cgroup__624' is already defined
This can be triggered under specific configs when __COUNTER__ happens to be the same for the same symbol in two different translation units, which is already quite unlikely to happen.
Add __LINE__ number suffix to make BTF_ID symbol more unique, which is not a complete fix, but it would help for now and meanwhile we can work on better solution as suggested by Andrii.
--- include/linux/btf_ids.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/btf_ids.h +1 -1
@@ -49,7 +49,7 @@ word \ ____BTF_ID(symbol, word)#define __ID (prefix) \ - __PASTE(prefix, __COUNTER__) + __PASTE(__PASTE(prefix, __COUNTER__), __LINE__)/* * The BTF_ID defines unique symbol for each ID pointing
Greg Kroah-Hartman
maintainerPATCH 298/321 bpf: Fix BTF_ID symbol generation collision in tools/
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nick Desaulniers <[email protected]>
commit c0bb9fb0e52a64601d38b3739b729d9138d4c8a1 upstream.
Marcus and Satya reported an issue where BTF_ID macro generates same symbol in separate objects and that breaks final vmlinux link.
ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol '__BTF_ID__struct__cgroup__624' is already defined
This can be triggered under specific configs when __COUNTER__ happens to be the same for the same symbol in two different translation units, which is already quite unlikely to happen.
Add __LINE__ number suffix to make BTF_ID symbol more unique, which is not a complete fix, but it would help for now and meanwhile we can work on better solution as suggested by Andrii.
--- tools/include/linux/btf_ids.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/include/linux/btf_ids.h +1 -1
@@ -38,7 +38,7 @@ asm( \ ____BTF_ID(symbol)#define __ID (prefix) \ - __PASTE(prefix, __COUNTER__) + __PASTE(__PASTE(prefix, __COUNTER__), __LINE__)/* * The BTF_ID defines unique symbol for each ID pointing
Greg Kroah-Hartman
maintainerPATCH 299/321 net: thunderbolt: Fix TCPv6 GSO checksum calculation
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mika Westerberg <[email protected]>
commit e0b65f9b81fef180cf5f103adecbe5505c961153 upstream.
Alex reported that running ssh over IPv6 does not work with Thunderbolt/USB4 networking driver. The reason for that is that driver should call skb_is_gso() before calling skb_is_gso_v6(), and it should not return false after calculates the checksum successfully. This probably was a copy paste error from the original driver where it was done properly.
--- drivers/net/thunderbolt/main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/thunderbolt/main.c +1 -2
@@ -1049,12 +1049,11 @@ static bool tbnet_xmit_csum_and_map(stru *tucso = ~csum_tcpudp_magic (ip_hdr (skb)->saddr,ip_hdr (skb)->daddr,0 ,ip_hdr (skb)->protocol,0 ); - }else if (skb_is_gso_v6 (skb)) { + }else if (skb_is_gso (skb) &&skb_is_gso_v6 (skb)) { tucso = dest + ((void *)&(tcp_hdr (skb)->check) - data); *tucso = ~csum_ipv6_magic (&ipv6_hdr (skb)->saddr, &ipv6_hdr (skb)->daddr,0 ,IPPROTO_TCP ,0 ); -return false; }else if (protocol ==htons (ETH_P_IPV6 )) { tucso = dest +skb_checksum_start_offset (skb) + skb->csum_offset; *tucso = ~csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
Greg Kroah-Hartman
maintainerPATCH 300/321 thermal: sysfs: Fix trip_point_hyst_store()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
commit ea3105672c68a5b6d7368504067220682ee6c65c upstream.
After commit 2e38a2a981b2 ("thermal/core: Add a generic thermal_zone_set_trip() function") updating a trip point temperature doesn't actually work, because the value supplied by user space is subsequently overwritten with the current trip point hysteresis value.
Fix this by changing the code to parse the number string supplied by user space after retrieving the current trip point data from the thermal zone.
Also drop a redundant tab character from the code in question.
--- drivers/thermal/thermal_sysfs.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/thermal/thermal_sysfs.c +5 -4
@@ -185,9 +185,6 @@ trip_point_hyst_store(struct device *dev, struct device_attribute *attr,if (sscanf (attr->attr.name,"trip_point_%d_hyst" , &trip_id) !=1 )return -EINVAL ; -if (kstrtoint (buf,10 , &trip.hysteresis)) -return -EINVAL ; -mutex_lock (&tz->lock);if (!device_is_registered (dev)) {
@@ -198,7 +195,11 @@ trip_point_hyst_store(struct device *dev, struct device_attribute *attr, ret =__thermal_zone_get_trip (tz, trip_id, &trip);if (ret) goto unlock; - + + ret =kstrtoint (buf,10 , &trip.hysteresis); +if (ret) + goto unlock; + ret =thermal_zone_set_trip (tz, trip_id, &trip); unlock:mutex_unlock (&tz->lock);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 301/321 fs/smb/client: Reset password pointer to NULL
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quang Le <[email protected]>
commit e6e43b8aa7cd3c3af686caf0c2e11819a886d705 upstream.
Forget to reset ctx->password to NULL will lead to bug like double free
--- fs/smb/client/fs_context.c | 1 + 1 file changed, 1 insertion(+)
fs/smb/client/fs_context.c +1 -0
@@ -1532,6 +1532,7 @@ static int smb3_fs_context_parse_param(s cifs_parse_mount_err:kfree_sensitive (ctx->password); + ctx->password =NULL ;return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 302/321 tracing/user_events: Align set_bit() address for all archs
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Beau Belgrave <[email protected]>
commit 2de9ee94054263940122aee8720e902b30c27930 upstream.
All architectures should use a long aligned address passed to set_bit(). User processes can pass either a 32-bit or 64-bit sized value to be updated when tracing is enabled when on a 64-bit kernel. Both cases are ensured to be naturally aligned, however, that is not enough. The address must be long aligned without affecting checks on the value within the user process which require different adjustments for the bit for little and big endian CPUs.
Add a compat flag to user_event_enabler that indicates when a 32-bit value is being used on a 64-bit kernel. Long align addresses and correct the bit to be used by set_bit() to account for this alignment. Ensure compat flags are copied during forks and used during deletion clears.
--- kernel/trace/trace_events_user.c | 58 ++++++++++++++++++++++++++++++++++----- 1 file changed, 51 insertions(+), 7 deletions(-)
kernel/trace/trace_events_user.c +51 -7
@@ -127,8 +127,13 @@ struct user_event_enabler {/* Bit 7 is for freeing status of enablement */ #define ENABLE_VAL_FREEING_BIT 7 -/* Only duplicate the bit value */ -#define ENABLE_VAL_DUP_MASK ENABLE_VAL_BIT_MASK +/* Bit 8 is for marking 32-bit on 64-bit */ +#define ENABLE_VAL_32_ON_64_BIT 8 + +#define ENABLE_VAL_COMPAT_MASK (1 << ENABLE_VAL_32_ON_64_BIT) + +/* Only duplicate the bit and compat values */ +#define ENABLE_VAL_DUP_MASK (ENABLE_VAL_BIT_MASK | ENABLE_VAL_COMPAT_MASK)#define ENABLE_BITOPS (e) (&(e)->values)
@@ -174,6 +179,30 @@ struct user_event_validator {int flags; }; +static inline void align_addr_bit (unsigned long *addr,int *bit, +unsigned long *flags) +{ +if (IS_ALIGNED (*addr,sizeof (long ))) { +#ifdef __BIG_ENDIAN +/* 32 bit on BE 64 bit requires a 32 bit offset when aligned. */ +if (test_bit (ENABLE_VAL_32_ON_64_BIT , flags)) + *bit +=32 ; +#endif +return ; + } + + *addr =ALIGN_DOWN (*addr,sizeof (long )); + +/* +* We only support 32 and 64 bit values. The only time we need +* to align is a 32 bit value on a 64 bit kernel, which on LE +* is always 32 bits, and on BE requires no change when unaligned. +*/ +#ifdef __LITTLE_ENDIAN + *bit +=32 ; +#endif +} +typedef void (*user_event_func_t ) (struct user_event *user,struct iov_iter *i,void *tpdata,bool *faulted);
@@ -482,6 +511,7 @@ static int user_event_enabler_write(struunsigned long *ptr;struct page *page;void *kaddr; +int bit =ENABLE_BIT (enabler);int ret;lockdep_assert_held (&event_mutex);
@@ -497,6 +527,8 @@ static int user_event_enabler_write(stru test_bit(ENABLE_VAL_FREEING_BIT, ENABLE_BITOPS(enabler))))return -EBUSY ; +align_addr_bit (&uaddr, &bit,ENABLE_BITOPS (enabler)); + ret =pin_user_pages_remote (mm->mm, uaddr,1 ,FOLL_WRITE |FOLL_NOFAULT , &page,NULL );
@@ -515,9 +547,9 @@ static int user_event_enabler_write(stru/* Update bit atomically, user tracers must be atomic as well */ if (enabler->event && enabler->event->status) -set_bit (ENABLE_BIT (enabler), ptr); +set_bit (bit, ptr);else -clear_bit (ENABLE_BIT (enabler), ptr); +clear_bit (bit, ptr);kunmap_local (kaddr);unpin_user_pages_dirty_lock (&page,1 , true);
@@ -849,6 +881,12 @@ static struct user_event_enabler enabler->event = user; enabler->addr = uaddr; enabler->values = reg->enable_bit; + +#if BITS_PER_LONG >=64 +if (reg->enable_size ==4 ) +set_bit (ENABLE_VAL_32_ON_64_BIT ,ENABLE_BITOPS (enabler)); +#endif + retry:/* Prevents state changes from racing with new enablers */ mutex_lock (&event_mutex);
@@ -2376,7 +2414,8 @@ static long user_unreg_get(struct user_u }static int user_event_mm_clear_bit (struct user_event_mm *user_mm, -unsigned long uaddr,unsigned char bit) +unsigned long uaddr,unsigned char bit, +unsigned long flags) {struct user_event_enabler enabler;int result;
@@ -2384,7 +2423,7 @@ static int user_event_mm_clear_bit(strucmemset (&enabler,0 ,sizeof (enabler)); enabler.addr = uaddr; - enabler.values = bit; + enabler.values = bit | flags; retry:/* Prevents state changes from racing with new enablers */ mutex_lock (&event_mutex);
@@ -2414,6 +2453,7 @@ static long user_events_ioctl_unreg(unsistruct user_event_mm *mm = current->user_event_mm;struct user_event_enabler *enabler, *next;struct user_unreg reg; +unsigned long flags;long ret; ret =user_unreg_get (ureg, ®);
@@ -2424,6 +2464,7 @@ static long user_events_ioctl_unreg(unsiif (!mm)return -ENOENT ; + flags =0 ; ret = -ENOENT ;/*
@@ -2440,6 +2481,9 @@ static long user_events_ioctl_unreg(unsi ENABLE_BIT(enabler) == reg.disable_bit) {set_bit (ENABLE_VAL_FREEING_BIT ,ENABLE_BITOPS (enabler)); +/* We must keep compat flags for the clear */ + flags |= enabler->values &ENABLE_VAL_COMPAT_MASK ; +if (!test_bit (ENABLE_VAL_FAULTING_BIT ,ENABLE_BITOPS (enabler)))user_event_enabler_destroy (enabler, true);
@@ -2453,7 +2497,7 @@ static long user_events_ioctl_unreg(unsi/* Ensure bit is now cleared for user, regardless of event status */ if (!ret) ret =user_event_mm_clear_bit (mm, reg.disable_addr, - reg.disable_bit); + reg.disable_bit, flags);return ret; }
Greg Kroah-Hartman
maintainerPATCH 303/321 ata: libata-core: Fix ata_port_request_pm() locking
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 3b8e0af4a7a331d1510e963b8fd77e2fca0a77f1 upstream.
The function ata_port_request_pm() checks the port flag ATA_PFLAG_PM_PENDING and calls ata_port_wait_eh() if this flag is set to ensure that power management operations for a port are not scheduled simultaneously. However, this flag check is done without holding the port lock.
Fix this by taking the port lock on entry to the function and checking the flag under this lock. The lock is released and re-taken if ata_port_wait_eh() needs to be called. The two WARN_ON() macros checking that the ATA_PFLAG_PM_PENDING flag was cleared are removed as the first call is racy and the second one done without holding the port lock.
--- drivers/ata/libata-core.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/ata/libata-core.c +9 -9
@@ -5204,17 +5204,19 @@ static void ata_port_request_pm(struct astruct ata_link *link;unsigned long flags; -/* Previous resume operation might still be in -* progress. Wait for PM_PENDING to clear. +spin_lock_irqsave (ap->lock, flags); + +/* +* A previous PM operation might still be in progress. Wait for +* ATA_PFLAG_PM_PENDING to clear. */ if (ap->pflags &ATA_PFLAG_PM_PENDING ) { +spin_unlock_irqrestore (ap->lock, flags);ata_port_wait_eh (ap); -WARN_ON (ap->pflags &ATA_PFLAG_PM_PENDING ); +spin_lock_irqsave (ap->lock, flags); } -/* request PM ops to EH */ -spin_lock_irqsave (ap->lock, flags); - +/* Request PM operation to EH */ ap->pm_mesg = mesg; ap->pflags |=ATA_PFLAG_PM_PENDING ;ata_for_each_link (link, ap,HOST_FIRST ) {
@@ -5226,10 +5228,8 @@ static void ata_port_request_pm(struct aspin_unlock_irqrestore (ap->lock, flags); -if (!async) { +if (!async)ata_port_wait_eh (ap); -WARN_ON (ap->pflags &ATA_PFLAG_PM_PENDING ); - } }/*
Greg Kroah-Hartman
maintainerPATCH 304/321 ata: libata-core: Fix port and device removal
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 84d76529c650f887f1e18caee72d6f0589e1baf9 upstream.
Whenever an ATA adapter driver is removed (e.g. rmmod), ata_port_detach() is called repeatedly for all the adapter ports to remove (unload) the devices attached to the port and delete the port device itself. Removing of devices is done using libata EH with the ATA_PFLAG_UNLOADING port flag set. This causes libata EH to execute ata_eh_unload() which disables all devices attached to the port.
ata_port_detach() finishes by calling scsi_remove_host() to remove the scsi host associated with the port. This function will trigger the removal of all scsi devices attached to the host and in the case of disks, calls to sd_shutdown() which will flush the device write cache and stop the device. However, given that the devices were already disabled by ata_eh_unload(), the synchronize write cache command and start stop unit commands fail. E.g. running "rmmod ahci" with first removing sd_mod results in error messages like:
ata13.00: disable device
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:0:0: [sda] Stopping disk
sd 0:0:0:0: [sda] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Fix this by removing all scsi devices of the ata devices connected to the port before scheduling libata EH to disable the ATA devices.
--- drivers/ata/libata-core.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
drivers/ata/libata-core.c +20 -1
@@ -6130,11 +6130,30 @@ static void ata_port_detach(struct ata_pif (!ap->ops->error_handler) goto skip_eh; -/* tell EH we're leaving & flush EH */ +/* Wait for any ongoing EH */ +ata_port_wait_eh (ap); + +mutex_lock (&ap->scsi_scan_mutex);spin_lock_irqsave (ap->lock, flags); + +/* Remove scsi devices */ +ata_for_each_link (link, ap,HOST_FIRST ) { +ata_for_each_dev (dev, link,ALL ) { +if (dev->sdev) { +spin_unlock_irqrestore (ap->lock, flags); +scsi_remove_device (dev->sdev); +spin_lock_irqsave (ap->lock, flags); + dev->sdev =NULL ; + } + } + } + +/* Tell EH to disable all devices */ ap->pflags |=ATA_PFLAG_UNLOADING ;ata_port_schedule_eh (ap); +spin_unlock_irqrestore (ap->lock, flags); +mutex_unlock (&ap->scsi_scan_mutex);/* wait till EH commits suicide */ ata_port_wait_eh (ap);
Greg Kroah-Hartman
maintainerPATCH 305/321 ata: libata-core: Do not register PM operations for SAS ports
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 75e2bd5f1ede42a2bc88aa34b431e1ace8e0bea0 upstream.
libsas does its own domain based power management of ports. For such ports, libata should not use a device type defining power management operations as executing these operations for suspend/resume in addition to libsas calls to ata_sas_port_suspend() and ata_sas_port_resume() is not necessary (and likely dangerous to do, even though problems are not seen currently).
Introduce the new ata_port_sas_type device_type for ports managed by libsas. This new device type is used in ata_tport_add() and is defined without power management operations.
--- drivers/ata/libata-core.c | 2 +- drivers/ata/libata-transport.c | 9 ++++++++- drivers/ata/libata.h | 2 ++ 3 files changed, 11 insertions(+), 2 deletions(-)
drivers/ata/libata-core.c +1 -1
@@ -5396,7 +5396,7 @@ EXPORT_SYMBOL_GPL(ata_host_resume);#endif const struct device_type ata_port_type = { - .name ="ata_port" , + .name =ATA_PORT_TYPE_NAME , #ifdef CONFIG_PM .pm = &ata_port_pm_ops, #endif
drivers/ata/libata-transport.c +8 -1
@@ -266,6 +266,10 @@ void ata_tport_delete(struct ata_port *aput_device (dev); } +static const struct device_type ata_port_sas_type = { + .name =ATA_PORT_TYPE_NAME , +}; +/** ata_tport_add - initialize a transport ATA port structure * * @parent: parent device
@@ -283,7 +287,10 @@ int ata_tport_add(struct device *parent,struct device *dev = &ap->tdev;device_initialize (dev); - dev->type = &ata_port_type; +if (ap->flags &ATA_FLAG_SAS_HOST ) + dev->type = &ata_port_sas_type; +else + dev->type = &ata_port_type; dev->parent = parent;ata_host_get (ap->host);
drivers/ata/libata.h +2 -0
@@ -30,6 +30,8 @@ enum { ATA_DNXFER_QUIET = (1 << 31), }; +#define ATA_PORT_TYPE_NAME "ata_port" +extern atomic_t ata_print_id;extern int atapi_passthru16;extern int libata_fua;
Greg Kroah-Hartman
maintainerPATCH 306/321 ata: libata-sata: increase PMP SRST timeout to 10s
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthias Schiffer <[email protected]>
commit 753a4d531bc518633ea88ac0ed02b25a16823d51 upstream.
On certain SATA controllers, softreset fails after wakeup from S2RAM with the message "softreset failed (1st FIS failed)", sometimes resulting in drives not being detected again. With the increased timeout, this issue is avoided. Instead, "softreset failed (device not ready)" is now logged 1-2 times; this later failure seems to cause fewer problems however, and the drives are detected reliably once they've spun up and the probe is retried.
The issue was observed with the primary SATA controller of the QNAP TS-453B, which is an "Intel Corporation Celeron/Pentium Silver Processor SATA Controller [8086:31e3] (rev 06)" integrated in the Celeron J4125 CPU, and the following drives:
- Seagate IronWolf ST12000VN0008
- Seagate IronWolf ST8000NE0004
The SATA controller seems to be more relevant to this issue than the drives, as the same drives are always detected reliably on the secondary SATA controller on the same board (an ASMedia 106x) without any "softreset failed" errors even without the increased timeout.
--- include/linux/libata.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/libata.h +1 -1
@@ -259,7 +259,7 @@ enum {* advised to wait only for the following duration before * doing SRST. */ - ATA_TMOUT_PMP_SRST_WAIT = 5000, + ATA_TMOUT_PMP_SRST_WAIT = 10000,/* When the LPM policy is set to ATA_LPM_MAX_POWER, there might * be a spurious PHY event, so ignore the first PHY event that
Greg Kroah-Hartman
maintainerPATCH 307/321 i915: Limit the length of an sg list to the requested length
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Wilcox (Oracle) <[email protected]>
commit 863a8eb3f27098b42772f668e3977ff4cae10b04 upstream.
The folio conversion changed the behaviour of shmem_sg_alloc_table() to put the entire length of the last folio into the sg list, even if the sg list should have been shorter. gen8_ggtt_insert_entries() relied on the list being the right length and would overrun the end of the page tables. Other functions may also have been affected.
Clamp the length of the last entry in the sg list to be the expected length.
--- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/gpu/drm/i915/gem/i915_gem_shmem.c +7 -4
@@ -100,6 +100,7 @@ int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table *st, st->nents =0 ;for (i =0 ; i < page_count; i++) {struct folio *folio; +unsigned long nr_pages;const unsigned int shrink[] = {I915_SHRINK_BOUND |I915_SHRINK_UNBOUND ,0 ,
@@ -150,6 +151,8 @@ int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table *st, } }while (1 ); + nr_pages = min_t(unsigned long, +folio_nr_pages (folio), page_count - i);if (!i || sg->length >= max_segment ||folio_pfn (folio) != next_pfn) {
@@ -157,13 +160,13 @@ int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table *st, sg =sg_next (sg); st->nents++; -sg_set_folio (sg, folio,folio_size (folio),0 ); +sg_set_folio (sg, folio, nr_pages *PAGE_SIZE ,0 ); }else {/* XXX: could overflow? */ - sg->length +=folio_size (folio); + sg->length += nr_pages *PAGE_SIZE ; } - next_pfn =folio_pfn (folio) +folio_nr_pages (folio); - i +=folio_nr_pages (folio) -1 ; + next_pfn =folio_pfn (folio) + nr_pages; + i += nr_pages -1 ;/* Check that the i965g/gm workaround works. */ GEM_BUG_ON (gfp & __GFP_DMA32 && next_pfn >=0x00100000UL );
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 308/321 drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Pello <[email protected]>
commit b7599d241778d0b10cdf7a5c755aa7db9b83250c upstream.
There is an assertion in ggtt_reserve_guc_top that the global GTT is of size at least GUC_GGTT_TOP, which is not the case on a 32-bit platform; see commit 562d55d991b39ce376c492df2f7890fd6a541ffc ("drm/i915/bdw: Only use 2g GGTT for 32b platforms"). If GEM_BUG_ON is enabled, this triggers a BUG(); if GEM_BUG_ON is disabled, the subsequent reservation fails and the driver fails to initialise the device:
i915 0000:00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of GGTT for GuC
i915 0000:00:02.0: Device initialization failed (-28)
i915 0000:00:02.0: Please file a bug on drm/i915; see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details.
i915: probe of 0000:00:02.0 failed with error -28
Make the reservation at the top of the available space, whatever that is, instead of assuming that the top will be GUC_GGTT_TOP.
--- drivers/gpu/drm/i915/gt/intel_ggtt.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/gt/intel_ggtt.c +17 -6
@@ -511,20 +511,31 @@ void intel_ggtt_unbind_vma(struct i915_a vm->clear_range (vm, vma_res->start, vma_res->vma_size); } +/* +* Reserve the top of the GuC address space for firmware images. Addresses +* beyond GUC_GGTT_TOP in the GuC address space are inaccessible by GuC, +* which makes for a suitable range to hold GuC/HuC firmware images if the +* size of the GGTT is 4G. However, on a 32-bit platform the size of the GGTT +* is limited to 2G, which is less than GUC_GGTT_TOP, but we reserve a chunk +* of the same size anyway, which is far more than needed, to keep the logic +* in uc_fw_ggtt_offset() simple. +*/ +#define GUC_TOP_RESERVE_SIZE (SZ_4G - GUC_GGTT_TOP) +static int ggtt_reserve_guc_top (struct i915_ggtt *ggtt) { -u64 size; +u64 offset;int ret;if (!intel_uc_uses_guc (&ggtt->vm.gt->uc))return 0 ; -GEM_BUG_ON (ggtt->vm.total <=GUC_GGTT_TOP ); - size = ggtt->vm.total -GUC_GGTT_TOP ; +GEM_BUG_ON (ggtt->vm.total <=GUC_TOP_RESERVE_SIZE ); + offset = ggtt->vm.total -GUC_TOP_RESERVE_SIZE ; - ret =i915_gem_gtt_reserve (&ggtt->vm,NULL , &ggtt->uc_fw, size, -GUC_GGTT_TOP ,I915_COLOR_UNEVICTABLE , -PIN_NOEVICT ); + ret =i915_gem_gtt_reserve (&ggtt->vm,NULL , &ggtt->uc_fw, +GUC_TOP_RESERVE_SIZE , offset, +I915_COLOR_UNEVICTABLE ,PIN_NOEVICT );if (ret)drm_dbg (&ggtt->vm.i915->drm,"Failed to reserve top of GGTT for GuC\n" );
Greg Kroah-Hartman
maintainerPATCH 309/321 power: supply: rk817: Add missing module alias
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Frattaroli <[email protected]>
commit cbcdfbf5a6cd66e47e5ee5d49c4c5a27a07ba082 upstream.
Similar to the rk817 codec alias that was missing, the rk817 charger driver is missing a module alias as well. This absence prevents the driver from autoprobing on OF systems when it is built as a module.
Add the right MODULE_ALIAS to fix this.
--- drivers/power/supply/rk817_charger.c | 1 + 1 file changed, 1 insertion(+)
drivers/power/supply/rk817_charger.c +1 -0
@@ -1220,3 +1220,4 @@ MODULE_DESCRIPTION("Battery power supplyMODULE_AUTHOR ("Maya Matuszczyk <[email protected]>" );MODULE_AUTHOR ("Chris Morgan <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_ALIAS ("platform:rk817-charger" );
Greg Kroah-Hartman
maintainerPATCH 310/321 power: supply: ab8500: Set typing and props
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <[email protected]>
commit dc77721ea4aa1e8937e2436f230b5a69065cc508 upstream.
I had the following weird phenomena on a mobile phone: while the capacity in /sys/class/power_supply/ab8500_fg/capacity would reflect the actual charge and capacity of the battery, only 1/3 of the value was shown on the battery status indicator and warnings for low battery appeared.
It turns out that UPower, the Freedesktop power daemon, will average all the power supplies of type "battery" in /sys/class/power_supply/* if there is more than one battery.
For the AB8500, there was "battery" ab8500_fg, ab8500_btemp and ab8500_chargalg. The latter two don't know anything about the battery, and should not be considered. They were however averaged and with the capacity of 0.
Flag ab8500_btemp and ab8500_chargalg with type "unknown" so they are not averaged as batteries.
Remove the technology prop from ab8500_btemp as well, all it does is snoop in on knowledge from another supply.
After this the battery indicator shows the right value.
--- drivers/power/supply/ab8500_btemp.c | 9 +-------- drivers/power/supply/ab8500_chargalg.c | 2 +- 2 files changed, 2 insertions(+), 9 deletions(-)
drivers/power/supply/ab8500_btemp.c +1 -8
@@ -115,7 +115,6 @@ struct ab8500_btemp {static enum power_supply_property ab8500_btemp_props[] = {POWER_SUPPLY_PROP_PRESENT ,POWER_SUPPLY_PROP_ONLINE , -POWER_SUPPLY_PROP_TECHNOLOGY ,POWER_SUPPLY_PROP_TEMP , };
@@ -532,12 +531,6 @@ static int ab8500_btemp_get_property(strelse val->intval =1 ;break ; -case POWER_SUPPLY_PROP_TECHNOLOGY : -if (di->bm->bi) - val->intval = di->bm->bi->technology; -else - val->intval =POWER_SUPPLY_TECHNOLOGY_UNKNOWN ; -break ;case POWER_SUPPLY_PROP_TEMP : val->intval =ab8500_btemp_get_temp (di);break ;
@@ -662,7 +655,7 @@ static char *supply_interface[] = {static const struct power_supply_desc ab8500_btemp_desc = { .name ="ab8500_btemp" , - .type =POWER_SUPPLY_TYPE_BATTERY , + .type =POWER_SUPPLY_TYPE_UNKNOWN , .properties = ab8500_btemp_props, .num_properties =ARRAY_SIZE (ab8500_btemp_props), .get_property = ab8500_btemp_get_property,
drivers/power/supply/ab8500_chargalg.c +1 -1
@@ -1720,7 +1720,7 @@ static char *supply_interface[] = {static const struct power_supply_desc ab8500_chargalg_desc = { .name ="ab8500_chargalg" , - .type =POWER_SUPPLY_TYPE_BATTERY , + .type =POWER_SUPPLY_TYPE_UNKNOWN , .properties = ab8500_chargalg_props, .num_properties =ARRAY_SIZE (ab8500_chargalg_props), .get_property = ab8500_chargalg_get_property,
Greg Kroah-Hartman
maintainerPATCH 311/321 fs: binfmt_elf_efpic: fix personality for ELF-FDPIC
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Ungerer <[email protected]>
commit 7c3151585730b7095287be8162b846d31e6eee61 upstream.
The elf-fdpic loader hard sets the process personality to either PER_LINUX_FDPIC for true elf-fdpic binaries or to PER_LINUX for normal ELF binaries (in this case they would be constant displacement compiled with -pie for example). The problem with that is that it will lose any other bits that may be in the ELF header personality (such as the "bug emulation" bits).
On the ARM architecture the ADDR_LIMIT_32BIT flag is used to signify a normal 32bit binary - as opposed to a legacy 26bit address binary. This matters since start_thread() will set the ARM CPSR register as required based on this flag. If the elf-fdpic loader loses this bit the process will be mis-configured and crash out pretty quickly.
Modify elf-fdpic loader personality setting so that it preserves the upper three bytes by using the SET_PERSONALITY macro to set it. This macro in the generic case sets PER_LINUX and preserves the upper bytes. Architectures can override this for their specific use case, and ARM does exactly this.
The problem shows up quite easily running under qemu using the ARM architecture, but not necessarily on all types of real ARM hardware. If the underlying ARM processor does not support the legacy 26-bit addressing mode then everything will work as expected.
--- fs/binfmt_elf_fdpic.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
fs/binfmt_elf_fdpic.c +2 -3
@@ -345,10 +345,9 @@ static int load_elf_fdpic_binary(struct/* there's now no turning back... the old userspace image is dead, * defunct, deceased, etc. */ +SET_PERSONALITY (exec_params.hdr);if (elf_check_fdpic (&exec_params.hdr)) -set_personality (PER_LINUX_FDPIC ); -else -set_personality (PER_LINUX ); + current->personality |=PER_LINUX_FDPIC ;if (elf_read_implies_exec (&exec_params.hdr, executable_stack)) current->personality |=READ_IMPLIES_EXEC ;
Greg Kroah-Hartman
maintainerPATCH 312/321 drm/amdkfd: Use gpu_offset for user queues wptr
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: YuBiao Wang <[email protected]>
commit cc39f9ccb82426e576734b493e1777ea01b144a8 upstream.
Directly use tbo's start address will miss the domain start offset. Need to use gpu_offset instead.
--- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c +1 -1
@@ -216,7 +216,7 @@ static int add_queue_mes(struct device_qif (q->wptr_bo) { wptr_addr_off = (uint64_t )q->properties.write_ptr & (PAGE_SIZE -1 ); - queue_input.wptr_mc_addr = ((uint64_t )q->wptr_bo->tbo.resource->start <<PAGE_SHIFT ) + wptr_addr_off; + queue_input.wptr_mc_addr =amdgpu_bo_gpu_offset (q->wptr_bo) + wptr_addr_off; } queue_input.is_kfd_process =1 ;
Greg Kroah-Hartman
maintainerPATCH 313/321 drm/amd/display: fix the ability to use lower resolution modes on eDP
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hamza Mahfooz <[email protected]>
commit 2de19022c5d7ff519dd5b9690f7713267bd1abfe upstream.
On eDP we can receive invalid modes from dm_update_crtc_state() for entirely new streams for which drm_mode_set_crtcinfo() shouldn't be called on. So, instead of calling drm_mode_set_crtcinfo() from within create_stream_for_sink() we can instead call it from amdgpu_dm_connector_mode_valid(). Since, we are guaranteed to only call drm_mode_set_crtcinfo() for valid modes from that function (invalid modes are rejected by that callback) and that is the only user of create_validate_stream_for_sink() that we need to call drm_mode_set_crtcinfo() for (as before commit cb841d27b876 ("drm/amd/display: Always pass connector_state to stream validation"), that is the only place where create_validate_stream_for_sink()'s dm_state was NULL).
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +2 -2
@@ -6062,8 +6062,6 @@ create_stream_for_sink(struct amdgpu_dm_if (recalculate_timing)drm_mode_set_crtcinfo (&saved_mode,0 ); -else if (!old_stream) -drm_mode_set_crtcinfo (&mode,0 );/* * If scaling is enabled and refresh rate didn't change
@@ -6625,6 +6623,8 @@ enum drm_mode_status amdgpu_dm_connector goto fail; } +drm_mode_set_crtcinfo (mode,0 ); + stream =create_validate_stream_for_sink (aconnector, mode,to_dm_connector_state (connector->state),NULL );
Greg Kroah-Hartman
maintainerPATCH 314/321 drm/meson: fix memory leak on ->hpd_notify callback
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <[email protected]>
commit 099f0af9d98231bb74956ce92508e87cbcb896be upstream.
The EDID returned by drm_bridge_get_edid() needs to be freed.
--- drivers/gpu/drm/meson/meson_encoder_hdmi.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/meson/meson_encoder_hdmi.c +2 -0
@@ -332,6 +332,8 @@ static void meson_encoder_hdmi_hpd_notifreturn ;cec_notifier_set_phys_addr_from_edid (encoder_hdmi->cec_notifier, edid); + +kfree (edid); }else cec_notifier_phys_addr_invalidate (encoder_hdmi->cec_notifier); }
Greg Kroah-Hartman
maintainerPATCH 315/321 rbd: move rbd_dev_refresh() definition
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit 0b035401c57021fc6c300272cbb1c5a889d4fe45 upstream.
Move rbd_dev_refresh() definition further down to avoid having to move struct parent_image_info definition in the next commit. This spares some forward declarations too.
--- drivers/block/rbd.c | 68 +++++++++++++++++++++++++--------------------------- 1 file changed, 33 insertions(+), 35 deletions(-)
drivers/block/rbd.c +33 -35
@@ -633,8 +633,6 @@ static void rbd_dev_remove_parent(structstatic int rbd_dev_refresh (struct rbd_device *rbd_dev);static int rbd_dev_v2_header_onetime (struct rbd_device *rbd_dev); -static int rbd_dev_header_info (struct rbd_device *rbd_dev); -static int rbd_dev_v2_parent_info (struct rbd_device *rbd_dev);static const char *rbd_dev_v2_snap_name (struct rbd_device *rbd_dev,u64 snap_id); static int _rbd_dev_v2_snap_size(struct rbd_device *rbd_dev, u64 snap_id,
@@ -4931,39 +4929,6 @@ static void rbd_dev_update_size(struct r } } -static int rbd_dev_refresh (struct rbd_device *rbd_dev) -{ -u64 mapping_size; -int ret; - -down_write (&rbd_dev->header_rwsem); - mapping_size = rbd_dev->mapping.size; - - ret =rbd_dev_header_info (rbd_dev); -if (ret) - goto out; - -/* -* If there is a parent, see if it has disappeared due to the -* mapped image getting flattened. -*/ -if (rbd_dev->parent) { - ret =rbd_dev_v2_parent_info (rbd_dev); -if (ret) - goto out; - } - -rbd_assert (!rbd_is_snap (rbd_dev)); - rbd_dev->mapping.size = rbd_dev->header.image_size; - -out: -up_write (&rbd_dev->header_rwsem); -if (!ret && mapping_size != rbd_dev->mapping.size) -rbd_dev_update_size (rbd_dev); - -return ret; -} -static const struct blk_mq_ops rbd_mq_ops = { .queue_rq = rbd_queue_rq, };
@@ -7043,6 +7008,39 @@ err_out_format:return ret; } +static int rbd_dev_refresh (struct rbd_device *rbd_dev) +{ +u64 mapping_size; +int ret; + +down_write (&rbd_dev->header_rwsem); + mapping_size = rbd_dev->mapping.size; + + ret =rbd_dev_header_info (rbd_dev); +if (ret) + goto out; + +/* +* If there is a parent, see if it has disappeared due to the +* mapped image getting flattened. +*/ +if (rbd_dev->parent) { + ret =rbd_dev_v2_parent_info (rbd_dev); +if (ret) + goto out; + } + +rbd_assert (!rbd_is_snap (rbd_dev)); + rbd_dev->mapping.size = rbd_dev->header.image_size; + +out: +up_write (&rbd_dev->header_rwsem); +if (!ret && mapping_size != rbd_dev->mapping.size) +rbd_dev_update_size (rbd_dev); + +return ret; +} +static ssize_t do_rbd_add (const char *buf,size_t count) {struct rbd_device *rbd_dev =NULL ;
Greg Kroah-Hartman
maintainerPATCH 316/321 rbd: decouple header read-in from updating rbd_dev->header
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit 510a7330c82a7754d5df0117a8589e8a539067c7 upstream.
Make rbd_dev_header_info() populate a passed struct rbd_image_header instead of rbd_dev->header and introduce rbd_dev_update_header() for updating mutable fields in rbd_dev->header upon refresh. The initial read-in of both mutable and immutable fields in rbd_dev_image_probe() passes in rbd_dev->header so no update step is required there.
rbd_init_layout() is now called directly from rbd_dev_image_probe() instead of individually in format 1 and format 2 implementations.
--- drivers/block/rbd.c | 206 ++++++++++++++++++++++++++++------------------------ 1 file changed, 114 insertions(+), 92 deletions(-)
drivers/block/rbd.c +114 -92
@@ -632,7 +632,8 @@ void rbd_warn(struct rbd_device *rbd_devstatic void rbd_dev_remove_parent (struct rbd_device *rbd_dev);static int rbd_dev_refresh (struct rbd_device *rbd_dev); -static int rbd_dev_v2_header_onetime (struct rbd_device *rbd_dev); +static int rbd_dev_v2_header_onetime (struct rbd_device *rbd_dev, +struct rbd_image_header *header);static const char *rbd_dev_v2_snap_name (struct rbd_device *rbd_dev,u64 snap_id); static int _rbd_dev_v2_snap_size(struct rbd_device *rbd_dev, u64 snap_id,
@@ -993,15 +994,24 @@ static void rbd_init_layout(struct rbd_dRCU_INIT_POINTER (rbd_dev->layout.pool_ns,NULL ); } +static void rbd_image_header_cleanup (struct rbd_image_header *header) +{ +kfree (header->object_prefix); +ceph_put_snap_context (header->snapc); +kfree (header->snap_sizes); +kfree (header->snap_names); + +memset (header,0 ,sizeof (*header)); +} +/* * Fill an rbd image header with information from the given format 1 * on-disk header. */ -static int rbd_header_from_disk (struct rbd_device *rbd_dev, -struct rbd_image_header_ondisk *ondisk) +static int rbd_header_from_disk (struct rbd_image_header *header, +struct rbd_image_header_ondisk *ondisk, +bool first_time) { -struct rbd_image_header *header = &rbd_dev->header; -bool first_time = header->object_prefix ==NULL ;struct ceph_snap_context *snapc;char *object_prefix =NULL ;char *snap_names =NULL ;
@@ -1068,11 +1078,6 @@ static int rbd_header_from_disk(struct rif (first_time) { header->object_prefix = object_prefix; header->obj_order = ondisk->options.order; -rbd_init_layout (rbd_dev); - }else { -ceph_put_snap_context (header->snapc); -kfree (header->snap_names); -kfree (header->snap_sizes); }/* The remaining fields always get updated (when we refresh) */
@@ -4857,7 +4862,9 @@ out_req:* return, the rbd_dev->header field will contain up-to-date * information about the image. */ -static int rbd_dev_v1_header_info (struct rbd_device *rbd_dev) +static int rbd_dev_v1_header_info (struct rbd_device *rbd_dev, +struct rbd_image_header *header, +bool first_time) {struct rbd_image_header_ondisk *ondisk =NULL ;u32 snap_count =0 ;
@@ -4905,7 +4912,7 @@ static int rbd_dev_v1_header_info(struct snap_count =le32_to_cpu (ondisk->snap_count); }while (snap_count != want_count); - ret =rbd_header_from_disk (rbd_dev, ondisk); + ret =rbd_header_from_disk (header, ondisk, first_time); out:kfree (ondisk);
@@ -5468,17 +5475,12 @@ static int _rbd_dev_v2_snap_size(structreturn 0 ; } -static int rbd_dev_v2_image_size (struct rbd_device *rbd_dev) -{ -return _rbd_dev_v2_snap_size (rbd_dev,CEPH_NOSNAP , - &rbd_dev->header.obj_order, - &rbd_dev->header.image_size); -} - -static int rbd_dev_v2_object_prefix (struct rbd_device *rbd_dev) +static int rbd_dev_v2_object_prefix (struct rbd_device *rbd_dev, +char **pobject_prefix) {size_t size;void *reply_buf; +char *object_prefix;int ret;void *p;
@@ -5496,16 +5498,16 @@ static int rbd_dev_v2_object_prefix(stru goto out; p = reply_buf; - rbd_dev->header.object_prefix =ceph_extract_encoded_string (&p, - p + ret,NULL ,GFP_NOIO ); + object_prefix =ceph_extract_encoded_string (&p, p + ret,NULL , +GFP_NOIO ); +if (IS_ERR (object_prefix)) { + ret =PTR_ERR (object_prefix); + goto out; + } ret =0 ; -if (IS_ERR (rbd_dev->header.object_prefix)) { - ret =PTR_ERR (rbd_dev->header.object_prefix); - rbd_dev->header.object_prefix =NULL ; - }else { -dout (" object_prefix = %s\n" , rbd_dev->header.object_prefix); - } + *pobject_prefix = object_prefix; +dout (" object_prefix = %s\n" , object_prefix); out:kfree (reply_buf);
@@ -5556,13 +5558,6 @@ static int _rbd_dev_v2_snap_features(strreturn 0 ; } -static int rbd_dev_v2_features (struct rbd_device *rbd_dev) -{ -return _rbd_dev_v2_snap_features (rbd_dev,CEPH_NOSNAP , -rbd_is_ro (rbd_dev), - &rbd_dev->header.features); -} -/* * These are generic image flags, but since they are used only for * object map, store them in rbd_dev->object_map_flags.
@@ -5837,14 +5832,14 @@ out_err:return ret; } -static int rbd_dev_v2_striping_info (struct rbd_device *rbd_dev) +static int rbd_dev_v2_striping_info (struct rbd_device *rbd_dev, +u64 *stripe_unit,u64 *stripe_count) {struct {__le64 stripe_unit;__le64 stripe_count; } __attribute__ ((packed)) striping_info_buf = {0 };size_t size =sizeof (striping_info_buf); -void *p;int ret; ret = rbd_obj_method_sync(rbd_dev, &rbd_dev->header_oid,
@@ -5856,27 +5851,33 @@ static int rbd_dev_v2_striping_info(struif (ret < size)return -ERANGE ; - p = &striping_info_buf; - rbd_dev->header.stripe_unit =ceph_decode_64 (&p); - rbd_dev->header.stripe_count =ceph_decode_64 (&p); + *stripe_unit =le64_to_cpu (striping_info_buf.stripe_unit); + *stripe_count =le64_to_cpu (striping_info_buf.stripe_count); +dout (" stripe_unit = %llu stripe_count = %llu\n" , *stripe_unit, + *stripe_count); +return 0 ; } -static int rbd_dev_v2_data_pool (struct rbd_device *rbd_dev) +static int rbd_dev_v2_data_pool (struct rbd_device *rbd_dev,s64 *data_pool_id) { -__le64 data_pool_id; +__le64 data_pool_buf;int ret; ret =rbd_obj_method_sync (rbd_dev, &rbd_dev->header_oid, &rbd_dev->header_oloc,"get_data_pool" , -NULL ,0 , &data_pool_id,sizeof (data_pool_id)); +NULL ,0 , &data_pool_buf, +sizeof (data_pool_buf)); +dout ("%s: rbd_obj_method_sync returned %d\n" , __func__, ret);if (ret <0 )return ret; -if (ret <sizeof (data_pool_id)) +if (ret <sizeof (data_pool_buf))return -EBADMSG ; - rbd_dev->header.data_pool_id =le64_to_cpu (data_pool_id); -WARN_ON (rbd_dev->header.data_pool_id ==CEPH_NOPOOL ); + *data_pool_id =le64_to_cpu (data_pool_buf); +dout (" data_pool_id = %lld\n" , *data_pool_id); +WARN_ON (*data_pool_id ==CEPH_NOPOOL ); +return 0 ; }
@@ -6068,7 +6069,8 @@ out_err:return ret; } -static int rbd_dev_v2_snap_context (struct rbd_device *rbd_dev) +static int rbd_dev_v2_snap_context (struct rbd_device *rbd_dev, +struct ceph_snap_context **psnapc) {size_t size;int ret;
@@ -6129,9 +6131,7 @@ static int rbd_dev_v2_snap_context(strucfor (i =0 ; i < snap_count; i++) snapc->snaps[i] =ceph_decode_64 (&p); -ceph_put_snap_context (rbd_dev->header.snapc); - rbd_dev->header.snapc = snapc; - + *psnapc = snapc;dout (" snap context seq = %llu, snap_count = %u\n" , (unsigned long long )seq, (unsigned int )snap_count); out:
@@ -6180,38 +6180,42 @@ out:return snap_name; } -static int rbd_dev_v2_header_info (struct rbd_device *rbd_dev) +static int rbd_dev_v2_header_info (struct rbd_device *rbd_dev, +struct rbd_image_header *header, +bool first_time) { -bool first_time = rbd_dev->header.object_prefix ==NULL ;int ret; - ret =rbd_dev_v2_image_size (rbd_dev); + ret =_rbd_dev_v2_snap_size (rbd_dev,CEPH_NOSNAP , + first_time ? &header->obj_order :NULL , + &header->image_size);if (ret)return ret;if (first_time) { - ret =rbd_dev_v2_header_onetime (rbd_dev); + ret =rbd_dev_v2_header_onetime (rbd_dev, header);if (ret)return ret; } - ret =rbd_dev_v2_snap_context (rbd_dev); -if (ret && first_time) { -kfree (rbd_dev->header.object_prefix); - rbd_dev->header.object_prefix =NULL ; - } + ret =rbd_dev_v2_snap_context (rbd_dev, &header->snapc); +if (ret) +return ret; -return ret; +return 0 ; } -static int rbd_dev_header_info (struct rbd_device *rbd_dev) +static int rbd_dev_header_info (struct rbd_device *rbd_dev, +struct rbd_image_header *header, +bool first_time) {rbd_assert (rbd_image_format_valid (rbd_dev->image_format)); +rbd_assert (!header->object_prefix && !header->snapc);if (rbd_dev->image_format ==1 ) -return rbd_dev_v1_header_info (rbd_dev); +return rbd_dev_v1_header_info (rbd_dev, header, first_time); -return rbd_dev_v2_header_info (rbd_dev); +return rbd_dev_v2_header_info (rbd_dev, header, first_time); }/*
@@ -6699,60 +6703,49 @@ out:*/ static void rbd_dev_unprobe (struct rbd_device *rbd_dev) { -struct rbd_image_header *header; -rbd_dev_parent_put (rbd_dev);rbd_object_map_free (rbd_dev);rbd_dev_mapping_clear (rbd_dev);/* Free dynamic fields from the header, then zero it out */ - header = &rbd_dev->header; -ceph_put_snap_context (header->snapc); -kfree (header->snap_sizes); -kfree (header->snap_names); -kfree (header->object_prefix); -memset (header,0 ,sizeof (*header)); +rbd_image_header_cleanup (&rbd_dev->header); } -static int rbd_dev_v2_header_onetime (struct rbd_device *rbd_dev) +static int rbd_dev_v2_header_onetime (struct rbd_device *rbd_dev, +struct rbd_image_header *header) {int ret; - ret =rbd_dev_v2_object_prefix (rbd_dev); + ret =rbd_dev_v2_object_prefix (rbd_dev, &header->object_prefix);if (ret) - goto out_err; +return ret;/* * Get the and check features for the image. Currently the * features are assumed to never change. */ - ret =rbd_dev_v2_features (rbd_dev); + ret =_rbd_dev_v2_snap_features (rbd_dev,CEPH_NOSNAP , +rbd_is_ro (rbd_dev), &header->features);if (ret) - goto out_err; +return ret;/* If the image supports fancy striping, get its parameters */ -if (rbd_dev->header.features &RBD_FEATURE_STRIPINGV2 ) { - ret =rbd_dev_v2_striping_info (rbd_dev); -if (ret <0 ) - goto out_err; +if (header->features &RBD_FEATURE_STRIPINGV2 ) { + ret =rbd_dev_v2_striping_info (rbd_dev, &header->stripe_unit, + &header->stripe_count); +if (ret) +return ret; } -if (rbd_dev->header.features &RBD_FEATURE_DATA_POOL ) { - ret =rbd_dev_v2_data_pool (rbd_dev); +if (header->features &RBD_FEATURE_DATA_POOL ) { + ret =rbd_dev_v2_data_pool (rbd_dev, &header->data_pool_id);if (ret) - goto out_err; +return ret; } -rbd_init_layout (rbd_dev);return 0 ; - -out_err: - rbd_dev->header.features =0 ; -kfree (rbd_dev->header.object_prefix); - rbd_dev->header.object_prefix =NULL ; -return ret; }/*
@@ -6947,13 +6940,15 @@ static int rbd_dev_image_probe(struct rbif (!depth)down_write (&rbd_dev->header_rwsem); - ret =rbd_dev_header_info (rbd_dev); + ret =rbd_dev_header_info (rbd_dev, &rbd_dev->header, true);if (ret) {if (ret == -ENOENT && !need_watch)rbd_print_dne (rbd_dev, false); goto err_out_probe; } +rbd_init_layout (rbd_dev); +/* * If this image is the one being mapped, we have pool name and * id, image name and id, and snap name - need to fill snap id.
@@ -7008,15 +7003,39 @@ err_out_format:return ret; } +static void rbd_dev_update_header (struct rbd_device *rbd_dev, +struct rbd_image_header *header) +{ +rbd_assert (rbd_image_format_valid (rbd_dev->image_format)); +rbd_assert (rbd_dev->header.object_prefix);/* !first_time */ + + rbd_dev->header.image_size = header->image_size; + +ceph_put_snap_context (rbd_dev->header.snapc); + rbd_dev->header.snapc = header->snapc; + header->snapc =NULL ; + +if (rbd_dev->image_format ==1 ) { +kfree (rbd_dev->header.snap_names); + rbd_dev->header.snap_names = header->snap_names; + header->snap_names =NULL ; + +kfree (rbd_dev->header.snap_sizes); + rbd_dev->header.snap_sizes = header->snap_sizes; + header->snap_sizes =NULL ; + } +} +static int rbd_dev_refresh (struct rbd_device *rbd_dev) { +struct rbd_image_header header = {0 };u64 mapping_size;int ret;down_write (&rbd_dev->header_rwsem); mapping_size = rbd_dev->mapping.size; - ret =rbd_dev_header_info (rbd_dev); + ret =rbd_dev_header_info (rbd_dev, &header, false);if (ret) goto out;
@@ -7030,6 +7049,8 @@ static int rbd_dev_refresh(struct rbd_de goto out; } +rbd_dev_update_header (rbd_dev, &header); +rbd_assert (!rbd_is_snap (rbd_dev)); rbd_dev->mapping.size = rbd_dev->header.image_size;
@@ -7038,6 +7059,7 @@ out:if (!ret && mapping_size != rbd_dev->mapping.size)rbd_dev_update_size (rbd_dev); +rbd_image_header_cleanup (&header);return ret; }
Greg Kroah-Hartman
maintainerPATCH 317/321 rbd: decouple parent info read-in from updating rbd_dev
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit c10311776f0a8ddea2276df96e255625b07045a8 upstream.
Unlike header read-in, parent info read-in is already decoupled in get_parent_info(), but it's buried in rbd_dev_v2_parent_info() along with the processing logic.
Separate the initial read-in and update read-in logic into rbd_dev_setup_parent() and rbd_dev_update_parent() respectively and have rbd_dev_v2_parent_info() just populate struct parent_image_info (i.e. what get_parent_info() did). Some existing QoI issues, like flatten of a standalone clone being disregarded on refresh, remain.
--- drivers/block/rbd.c | 144 +++++++++++++++++++++++++++++----------------------- 1 file changed, 81 insertions(+), 63 deletions(-)
drivers/block/rbd.c +81 -63
@@ -5594,6 +5594,14 @@ struct parent_image_info {u64 overlap; }; +static void rbd_parent_info_cleanup (struct parent_image_info *pii) +{ +kfree (pii->pool_ns); +kfree (pii->image_id); + +memset (pii,0 ,sizeof (*pii)); +} +/* * The caller is responsible for @pii. */
@@ -5663,6 +5671,9 @@ static int __get_parent_info(struct rbd_if (pii->has_overlap)ceph_decode_64_safe (&p, end, pii->overlap, e_inval); +dout ("%s pool_id %llu pool_ns %s image_id %s snap_id %llu has_overlap %d overlap %llu\n" , + __func__, pii->pool_id, pii->pool_ns, pii->image_id, pii->snap_id, + pii->has_overlap, pii->overlap);return 0 ; e_inval:
@@ -5701,14 +5712,17 @@ static int __get_parent_info_legacy(stru pii->has_overlap = true;ceph_decode_64_safe (&p, end, pii->overlap, e_inval); +dout ("%s pool_id %llu pool_ns %s image_id %s snap_id %llu has_overlap %d overlap %llu\n" , + __func__, pii->pool_id, pii->pool_ns, pii->image_id, pii->snap_id, + pii->has_overlap, pii->overlap);return 0 ; e_inval:return -EINVAL ; } -static int get_parent_info (struct rbd_device *rbd_dev, -struct parent_image_info *pii) +static int rbd_dev_v2_parent_info (struct rbd_device *rbd_dev, +struct parent_image_info *pii) {struct page *req_page, *reply_page;void *p;
@@ -5736,7 +5750,7 @@ static int get_parent_info(struct rbd_dereturn ret; } -static int rbd_dev_v2_parent_info (struct rbd_device *rbd_dev) +static int rbd_dev_setup_parent (struct rbd_device *rbd_dev) {struct rbd_spec *parent_spec;struct parent_image_info pii = {0 };
@@ -5746,37 +5760,12 @@ static int rbd_dev_v2_parent_info(structif (!parent_spec)return -ENOMEM ; - ret =get_parent_info (rbd_dev, &pii); + ret =rbd_dev_v2_parent_info (rbd_dev, &pii);if (ret) goto out_err; -dout ("%s pool_id %llu pool_ns %s image_id %s snap_id %llu has_overlap %d overlap %llu\n" , - __func__, pii.pool_id, pii.pool_ns, pii.image_id, pii.snap_id, - pii.has_overlap, pii.overlap); - -if (pii.pool_id ==CEPH_NOPOOL || !pii.has_overlap) { -/* -* Either the parent never existed, or we have -* record of it but the image got flattened so it no -* longer has a parent. When the parent of a -* layered image disappears we immediately set the -* overlap to 0. The effect of this is that all new -* requests will be treated as if the image had no -* parent. -* -* If !pii.has_overlap, the parent image spec is not -* applicable. It's there to avoid duplication in each -* snapshot record. -*/ -if (rbd_dev->parent_overlap) { - rbd_dev->parent_overlap =0 ; -rbd_dev_parent_put (rbd_dev); -pr_info ("%s: clone image has been flattened\n" , - rbd_dev->disk->disk_name); - } - +if (pii.pool_id ==CEPH_NOPOOL || !pii.has_overlap) goto out;/* No parent? No problem. */ - }/* The ceph file layout needs to fit pool id in 32 bits */
@@ -5788,46 +5777,34 @@ static int rbd_dev_v2_parent_info(struct }/* -* The parent won't change (except when the clone is -* flattened, already handled that). So we only need to -* record the parent spec we have not already done so. +* The parent won't change except when the clone is flattened, +* so we only need to record the parent image spec once. */ -if (!rbd_dev->parent_spec) { - parent_spec->pool_id = pii.pool_id; -if (pii.pool_ns && *pii.pool_ns) { - parent_spec->pool_ns = pii.pool_ns; - pii.pool_ns =NULL ; - } - parent_spec->image_id = pii.image_id; - pii.image_id =NULL ; - parent_spec->snap_id = pii.snap_id; - - rbd_dev->parent_spec = parent_spec; - parent_spec =NULL ;/* rbd_dev now owns this */ - } + parent_spec->pool_id = pii.pool_id; +if (pii.pool_ns && *pii.pool_ns) { + parent_spec->pool_ns = pii.pool_ns; + pii.pool_ns =NULL ; + } + parent_spec->image_id = pii.image_id; + pii.image_id =NULL ; + parent_spec->snap_id = pii.snap_id; + +rbd_assert (!rbd_dev->parent_spec); + rbd_dev->parent_spec = parent_spec; + parent_spec =NULL ;/* rbd_dev now owns this */ /* -* We always update the parent overlap. If it's zero we issue -* a warning, as we will proceed as if there was no parent. +* Record the parent overlap. If it's zero, issue a warning as +* we will proceed as if there is no parent. */ -if (!pii.overlap) { -if (parent_spec) { -/* refresh, careful to warn just once */ -if (rbd_dev->parent_overlap) -rbd_warn (rbd_dev, -"clone now standalone (overlap became 0)" ); - }else { -/* initial probe */ -rbd_warn (rbd_dev,"clone is standalone (overlap 0)" ); - } - } +if (!pii.overlap) +rbd_warn (rbd_dev,"clone is standalone (overlap 0)" ); rbd_dev->parent_overlap = pii.overlap; out: ret =0 ; out_err: -kfree (pii.pool_ns); -kfree (pii.image_id); +rbd_parent_info_cleanup (&pii);rbd_spec_put (parent_spec);return ret; }
@@ -6977,7 +6954,7 @@ static int rbd_dev_image_probe(struct rb }if (rbd_dev->header.features &RBD_FEATURE_LAYERING ) { - ret =rbd_dev_v2_parent_info (rbd_dev); + ret =rbd_dev_setup_parent (rbd_dev);if (ret) goto err_out_probe; }
@@ -7026,9 +7003,47 @@ static void rbd_dev_update_header(struct } } +static void rbd_dev_update_parent (struct rbd_device *rbd_dev, +struct parent_image_info *pii) +{ +if (pii->pool_id ==CEPH_NOPOOL || !pii->has_overlap) { +/* +* Either the parent never existed, or we have +* record of it but the image got flattened so it no +* longer has a parent. When the parent of a +* layered image disappears we immediately set the +* overlap to 0. The effect of this is that all new +* requests will be treated as if the image had no +* parent. +* +* If !pii.has_overlap, the parent image spec is not +* applicable. It's there to avoid duplication in each +* snapshot record. +*/ +if (rbd_dev->parent_overlap) { + rbd_dev->parent_overlap =0 ; +rbd_dev_parent_put (rbd_dev); +pr_info ("%s: clone has been flattened\n" , + rbd_dev->disk->disk_name); + } + }else { +rbd_assert (rbd_dev->parent_spec); + +/* +* Update the parent overlap. If it became zero, issue +* a warning as we will proceed as if there is no parent. +*/ +if (!pii->overlap && rbd_dev->parent_overlap) +rbd_warn (rbd_dev, +"clone has become standalone (overlap 0)" ); + rbd_dev->parent_overlap = pii->overlap; + } +} +static int rbd_dev_refresh (struct rbd_device *rbd_dev) {struct rbd_image_header header = {0 }; +struct parent_image_info pii = {0 };u64 mapping_size;int ret;
@@ -7044,12 +7059,14 @@ static int rbd_dev_refresh(struct rbd_de* mapped image getting flattened. */ if (rbd_dev->parent) { - ret =rbd_dev_v2_parent_info (rbd_dev); + ret =rbd_dev_v2_parent_info (rbd_dev, &pii);if (ret) goto out; }rbd_dev_update_header (rbd_dev, &header); +if (rbd_dev->parent) +rbd_dev_update_parent (rbd_dev, &pii);rbd_assert (!rbd_is_snap (rbd_dev)); rbd_dev->mapping.size = rbd_dev->header.image_size;
@@ -7059,6 +7076,7 @@ out:if (!ret && mapping_size != rbd_dev->mapping.size)rbd_dev_update_size (rbd_dev); +rbd_parent_info_cleanup (&pii);rbd_image_header_cleanup (&header);return ret; }
Greg Kroah-Hartman
maintainerPATCH 318/321 rbd: take header_rwsem in rbd_dev_refresh() only when updating
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit 0b207d02bd9ab8dcc31b262ca9f60dbc1822500d upstream.
rbd_dev_refresh() has been holding header_rwsem across header and parent info read-in unnecessarily for ages. With commit 870611e4877e ("rbd: get snapshot context after exclusive lock is ensured to be held"), the potential for deadlocks became much more real owning to
a) header_rwsem now nesting inside lock_rwsem and b) rw_semaphores not allowing new readers after a writer is registered.
For example, assuming that I/O request 1, I/O request 2 and header read-in request all target the same OSD:
1. I/O request 1 comes in and gets submitted
2. watch error occurs
3. rbd_watch_errcb() takes lock_rwsem for write, clears owner_cid and releases lock_rwsem
4. after reestablishing the watch, rbd_reregister_watch() calls rbd_dev_refresh() which takes header_rwsem for write and submits a header read-in request
5. I/O request 2 comes in: after taking lock_rwsem for read in __rbd_img_handle_request(), it blocks trying to take header_rwsem for read in rbd_img_object_requests()
6. another watch error occurs
7. rbd_watch_errcb() blocks trying to take lock_rwsem for write
8. I/O request 1 completion is received by the messenger but can't be processed because lock_rwsem won't be granted anymore
9. header read-in request completion can't be received, let alone processed, because the messenger is stranded
Change rbd_dev_refresh() to take header_rwsem only for actually updating rbd_dev->header. Header and parent info read-in don't need any locking.
--- drivers/block/rbd.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/block/rbd.c +11 -11
@@ -6986,7 +6986,14 @@ static void rbd_dev_update_header(structrbd_assert (rbd_image_format_valid (rbd_dev->image_format));rbd_assert (rbd_dev->header.object_prefix);/* !first_time */ - rbd_dev->header.image_size = header->image_size; +if (rbd_dev->header.image_size != header->image_size) { + rbd_dev->header.image_size = header->image_size; + +if (!rbd_is_snap (rbd_dev)) { + rbd_dev->mapping.size = header->image_size; +rbd_dev_update_size (rbd_dev); + } + }ceph_put_snap_context (rbd_dev->header.snapc); rbd_dev->header.snapc = header->snapc;
@@ -7044,11 +7051,9 @@ static int rbd_dev_refresh(struct rbd_de {struct rbd_image_header header = {0 };struct parent_image_info pii = {0 }; -u64 mapping_size;int ret; -down_write (&rbd_dev->header_rwsem); - mapping_size = rbd_dev->mapping.size; +dout ("%s rbd_dev %p\n" , __func__, rbd_dev); ret =rbd_dev_header_info (rbd_dev, &header, false);if (ret)
@@ -7064,18 +7069,13 @@ static int rbd_dev_refresh(struct rbd_de goto out; } +down_write (&rbd_dev->header_rwsem);rbd_dev_update_header (rbd_dev, &header);if (rbd_dev->parent)rbd_dev_update_parent (rbd_dev, &pii); - -rbd_assert (!rbd_is_snap (rbd_dev)); - rbd_dev->mapping.size = rbd_dev->header.image_size; - -out:up_write (&rbd_dev->header_rwsem); -if (!ret && mapping_size != rbd_dev->mapping.size) -rbd_dev_update_size (rbd_dev); +out:rbd_parent_info_cleanup (&pii);rbd_image_header_cleanup (&header);return ret;
Greg Kroah-Hartman
maintainerPATCH 319/321 memcg: drop kmem.limit_in_bytes
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Hocko <[email protected]>
commit 86327e8eb94c52eca4f93cfece2e29d1bf52acbf upstream.
kmem.limit_in_bytes (v1 way to limit kernel memory usage) has been deprecated since 58056f77502f ("memcg, kmem: further deprecate kmem.limit_in_bytes") merged in 5.16. We haven't heard about any serious users since then but it seems that the mere presence of the file is causing more harm thatn good. We (SUSE) have had several bug reports from customers where Docker based containers started to fail because a write to kmem.limit_in_bytes has failed.
This was unexpected because runc code only expects ENOENT (kmem disabled) or EBUSY (tasks already running within cgroup). So a new error code was unexpected and the whole container startup failed. This has been later addressed by
https://github.com/opencontainers/runc/commit/52390d68040637dfc77f9fda6bbe70952423d380
so current Docker runtimes do not suffer from the problem anymore. There are still older version of Docker in use and likely hard to get rid of completely.
Address this by wiping out the file completely and effectively get back to pre 4.5 era and CONFIG_MEMCG_KMEM=n configuration.
I would recommend backporting to stable trees which have picked up 58056f77502f ("memcg, kmem: further deprecate kmem.limit_in_bytes").
--- Documentation/admin-guide/cgroup-v1/memory.rst | 2 -- mm/memcontrol.c | 10 ---------- 2 files changed, 12 deletions(-)
Documentation/admin-guide/cgroup-v1/memory.rst +0 -2
@@ -92,8 +92,6 @@ Brief summary of control files. memory.oom_control set/show oom controls. memory.numa_stat show the number of memory usage per numa node - memory.kmem.limit_in_bytes This knob is deprecated and writing to - it will return -ENOTSUPP. memory.kmem.usage_in_bytes show current kernel memory allocation memory.kmem.failcnt show the number of kernel memory usage hits limits
mm/memcontrol.c +0 -10
@@ -3871,10 +3871,6 @@ static ssize_t mem_cgroup_write(struct kcase _MEMSWAP: ret =mem_cgroup_resize_max (memcg, nr_pages, true);break ; -case _KMEM: -/* kmem.limit_in_bytes is deprecated. */ - ret = -EOPNOTSUPP ; -break ;case _TCP: ret =memcg_update_tcp_max (memcg, nr_pages);break ;
@@ -5086,12 +5082,6 @@ static struct cftype mem_cgroup_legacy_f },#endif { - .name = "kmem.limit_in_bytes", - .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT), - .write = mem_cgroup_write, - .read_u64 = mem_cgroup_read_u64, - }, - { .name = "kmem.usage_in_bytes", .private = MEMFILE_PRIVATE(_KMEM, RES_USAGE), .read_u64 = mem_cgroup_read_u64,
Greg Kroah-Hartman
maintainerPATCH 320/321 mm, memcg: reconsider kmem.limit_in_bytes deprecation
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Hocko <[email protected]>
commit 4597648fddeadef5877610d693af11906aa666ac upstream.
This reverts commits 86327e8eb94c ("memcg: drop kmem.limit_in_bytes") and partially reverts 58056f77502f ("memcg, kmem: further deprecate kmem.limit_in_bytes") which have incrementally removed support for the kernel memory accounting hard limit. Unfortunately it has turned out that there is still userspace depending on the existence of memory.kmem.limit_in_bytes [1]. The underlying functionality is not really required but the non-existent file just confuses the userspace which fails in the result. The patch to fix this on the userspace side has been submitted but it is hard to predict how it will propagate through the maze of 3rd party consumers of the software.
Now, reverting alone 86327e8eb94c is not an option because there is another set of userspace which cannot cope with ENOTSUPP returned when writing to the file. Therefore we have to go and revisit 58056f77502f as well. There are two ways to go ahead. Either we give up on the deprecation and fully revert 58056f77502f as well or we can keep kmem.limit_in_bytes but make the write a noop and warn about the fact. This should work for both known breaking workloads which depend on the existence but do not depend on the hard limit enforcement.
Note to backporters to stable trees. a8c49af3be5f ("memcg: add per-memcg total kernel memory stat") introduced in 4.18 has added memcg_account_kmem so the accounting is not done by obj_cgroup_charge_pages directly for v1 anymore. Prior kernels need to add it explicitly (thanks to Johannes for pointing this out).
--- Documentation/admin-guide/cgroup-v1/memory.rst | 7 +++++++ mm/memcontrol.c | 13 +++++++++++++ 2 files changed, 20 insertions(+)
Documentation/admin-guide/cgroup-v1/memory.rst +7 -0
@@ -92,6 +92,13 @@ Brief summary of control files. memory.oom_control set/show oom controls. memory.numa_stat show the number of memory usage per numa node + memory.kmem.limit_in_bytes Deprecated knob to set and read the kernel + memory hard limit. Kernel hard limit is not + supported since 5.16. Writing any value to + do file will not have any effect same as if + nokmem kernel parameter was specified. + Kernel memory is still charged and reported + by memory.kmem.usage_in_bytes. memory.kmem.usage_in_bytes show current kernel memory allocation memory.kmem.failcnt show the number of kernel memory usage hits limits
mm/memcontrol.c +13 -0
@@ -3871,6 +3871,13 @@ static ssize_t mem_cgroup_write(struct kcase _MEMSWAP: ret =mem_cgroup_resize_max (memcg, nr_pages, true);break ; +case _KMEM: +pr_warn_once ("kmem.limit_in_bytes is deprecated and will be removed. " +"Writing any value to this file has no effect. " +"Please report your usecase to [email protected] if you " +"depend on this functionality.\n" ); + ret =0 ; +break ;case _TCP: ret =memcg_update_tcp_max (memcg, nr_pages);break ;
@@ -5082,6 +5089,12 @@ static struct cftype mem_cgroup_legacy_f },#endif { + .name = "kmem.limit_in_bytes", + .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT), + .write = mem_cgroup_write, + .read_u64 = mem_cgroup_read_u64, + }, + { .name = "kmem.usage_in_bytes", .private = MEMFILE_PRIVATE(_KMEM, RES_USAGE), .read_u64 = mem_cgroup_read_u64,
Greg Kroah-Hartman
maintainerPATCH 321/321 ASoC: amd: yc: Fix a non-functional mic on Lenovo 82TL
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit cfff2a7794d23b03a3ddedd318bf1df1876c598f upstream.
Lenovo 82TL has DMIC connected like 82V2 does. Also match 82TL.
--- sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+)
sound/soc/amd/yc/acp6x-mach.c +7 -0
@@ -217,6 +217,13 @@ static const struct dmi_system_id yc_acp .driver_data = &acp6x_card, .matches = {DMI_MATCH (DMI_BOARD_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_NAME, "82TL"), + } + }, + { + .driver_data = &acp6x_card, + .matches = { +DMI_MATCH (DMI_BOARD_VENDOR ,"LENOVO" ), DMI_MATCH(DMI_PRODUCT_NAME, "82QF"), } },
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Hello,
Quoted 5 lines · On Wed, 4 Oct 2023 19:52:25 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] 9327d0db36be ("Linux 6.5.6-rc1")
Thanks,
SJ
[...]
---
# the log is at '/home/sjpark/log'. [32m ok 1 selftests: damon: debugfs_attrs.sh ok 2 selftests: damon: debugfs_schemes.sh ok 3 selftests: damon: debugfs_target_ids.sh ok 4 selftests: damon: debugfs_empty_targets.sh ok 5 selftests: damon: debugfs_huge_count_read_write.sh ok 6 selftests: damon: debugfs_duplicate_context_creation.sh ok 7 selftests: damon: debugfs_rm_non_contexts.sh ok 8 selftests: damon: sysfs.sh ok 9 selftests: damon: sysfs_update_removed_scheme_dir.sh ok 10 selftests: damon: reclaim.sh ok 11 selftests: damon: lru_sort.sh ok 1 selftests: damon-tests: kunit.sh ok 2 selftests: damon-tests: huge_count_read_write.sh ok 3 selftests: damon-tests: buffer_overflow.sh ok 4 selftests: damon-tests: rm_contexts.sh ok 5 selftests: damon-tests: record_null_deref.sh ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh ok 8 selftests: damon-tests: damo_tests.sh ok 9 selftests: damon-tests: masim-record.sh ok 10 selftests: damon-tests: build_i386.sh ok 11 selftests: damon-tests: build_arm64.sh ok 12 selftests: damon-tests: build_i386_idle_flag.sh ok 13 selftests: damon-tests: build_i386_highpte.sh ok 14 selftests: damon-tests: build_nomemcg.sh [33m [92mPASS [39m _remote_run_corr.sh SUCCESS
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully compiled and installed bindeb-pkgs on my computer (Acer Aspire E15, Intel Core i3 Haswell). No noticeable regressions.
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
The following kernel warning was noticed on qemu-armv7 while booting with kselftest merge configs enabled build on stable-rc 6.5.6-rc1.
Quoted 2 lines
Hou Tao <[email protected]>
bpf: Ensureunit_sizeis matched with slab cache object size
bpf: Ensure unit_size is matched with slab cache object size [ Upstream commit c930472552022bd09aab3cd946ba3f243070d5c7 ]
[ 2.525383] ------------[ cut here ]------------ [ 2.525743] WARNING: CPU: 0 PID: 1 at kernel/bpf/memalloc.c:385 bpf_mem_alloc_init+0x3b0/0x3b4 [ 2.527241] bpf_mem_cache[0]: unexpected object size 128, expect 96 [ 2.527897] Modules linked in: [ 2.528721] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.6-rc1 #1 [ 2.529525] Hardware name: Generic DT based system [ 2.531279] unwind_backtrace from show_stack+0x10/0x14 [ 2.531684] show_stack from dump_stack_lvl+0x48/0x54 [ 2.532220] dump_stack_lvl from __warn+0xd4/0x200 [ 2.532878] __warn from warn_slowpath_fmt+0xb4/0x168 [ 2.533516] warn_slowpath_fmt from bpf_mem_alloc_init+0x3b0/0x3b4 [ 2.534133] bpf_mem_alloc_init from bpf_global_ma_init+0x18/0x30 [ 2.534911] bpf_global_ma_init from do_one_initcall+0x118/0x250 [ 2.535594] do_one_initcall from do_initcall_level+0xe8/0xf4 [ 2.536016] do_initcall_level from do_initcalls+0x50/0x80 [ 2.536618] do_initcalls from kernel_init_freeable+0x90/0xd8 [ 2.537220] kernel_init_freeable from kernel_init+0x14/0x1b4 [ 2.537634] kernel_init from ret_from_fork+0x14/0x28 [ 2.538271] Exception stack(0xf0825fb0 to 0xf0825ff8) [ 2.539230] 5fa0: 00000000 00000000 00000000 00000000 [ 2.539792] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.540497] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 2.541682] ---[ end trace 0000000000000000 ]---
Links:
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.5.y/build/v6.5.5-322-g9327d0db36be/testrun/20257234/suite/log-parser-boot/test/check-kernel-exception/log
- https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2WJGm4kyWj47rr0KEArH4BwqPCs
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.5.y/build/v6.5.5-322-g9327d0db36be/testrun/20257234/suite/log-parser-boot/tests/
--
Linaro LKFT
https://lkft.linaro.org
Quoted 31 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
The following kernel warning was noticed on qemu-armv7 while booting with kselftest merge configs enabled build on stable-rc 6.5.6-rc1.
Quoted 2 lines
Hou Tao <[email protected]>
bpf: Ensureunit_sizeis matched with slab cache object size
Quoted 7 lines
bpf: Ensure
unit_sizeis matched with slab cache object size [ Upstream commitc930472552022bd09aab3cd946ba3f243070d5c7][ 2.525383] ------------[ cut here ]------------ [ 2.525743] WARNING: CPU: 0 PID: 1 at kernel/bpf/memalloc.c:385 bpf_mem_alloc_init+0x3b0/0x3b4 [ 2.527241] bpf_mem_cache[0]: unexpected object size 128, expect 96
Anders investigated this report and picked up the following patches to solve the reported problem.
d52b59315bf5e bpf: Adjust size_index according to the value of KMALLOC_MIN_SIZE b1d53958b6931 bpf: Don't prefill for unused bpf_mem_cache c930472552022 bpf: Ensure unit_size is matched with slab cache object size
- Naresh
Greg Kroah-Hartman
maintainerQuoted 41 lines · Naresh Kamboju
Quoted 31 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
The following kernel warning was noticed on qemu-armv7 while booting with kselftest merge configs enabled build on stable-rc 6.5.6-rc1.
Quoted 2 lines
Hou Tao <[email protected]>
bpf: Ensureunit_sizeis matched with slab cache object sizeQuoted 7 lines
bpf: Ensure
unit_sizeis matched with slab cache object size [ Upstream commitc930472552022bd09aab3cd946ba3f243070d5c7][ 2.525383] ------------[ cut here ]------------ [ 2.525743] WARNING: CPU: 0 PID: 1 at kernel/bpf/memalloc.c:385 bpf_mem_alloc_init+0x3b0/0x3b4 [ 2.527241] bpf_mem_cache[0]: unexpected object size 128, expect 96
Quoted 6 lines
Anders investigated this report and picked up the following patches to solve the reported problem.
d52b59315bf5ebpf: Adjustsize_indexaccording to the value ofKMALLOC_MIN_SIZEb1d53958b6931bpf: Don't prefill for unusedbpf_mem_cachec930472552022bpf: Ensureunit_sizeis matched with slab cache object size
Those do not all apply cleanly to the tree, so I've dropped the one offending commit instead for 6.5.y and 6.1.y.
thanks,
greg k-h
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
While running kunit testing on qemu-armv7 following test failures noticed on stable rc 6.5.6-rc1.
# req_destroy works: EXPECTATION FAILED at net/handshake/handshake-test.c:477
Test log:
----------
<6>[ 1351.687335] KTAP version 1 <6>[ 1351.688300] # Subtest: Handshake API tests <6>[ 1351.688760] 1..11 <6>[ 1351.689362] KTAP version 1 <6>[ 1351.689985] # Subtest: req_alloc API fuzzing <6>[ 1351.694360] ok 1 handshake_req_alloc NULL proto <6>[ 1351.705855] ok 2 handshake_req_alloc CLASS_NONE <6>[ 1351.710878] ok 3 handshake_req_alloc CLASS_MAX <6>[ 1351.715435] ok 4 handshake_req_alloc no callbacks <6>[ 1351.722026] ok 5 handshake_req_alloc no done callback <6>[ 1351.726579] ok 6 handshake_req_alloc excessive privsize <6>[ 1351.732397] ok 7 handshake_req_alloc all good <6>[ 1351.732934] # req_alloc API fuzzing: pass:7 fail:0 skip:0 total:7 <6>[ 1351.733586] ok 1 req_alloc API fuzzing <6>[ 1351.741251] ok 2 req_submit NULL req arg <6>[ 1351.745979] ok 3 req_submit NULL sock arg <6>[ 1351.753307] ok 4 req_submit NULL sock->file <6>[ 1351.763090] ok 5 req_lookup works <6>[ 1351.770057] ok 6 req_submit max pending <6>[ 1351.774878] ok 7 req_submit multiple <6>[ 1351.782411] ok 8 req_cancel before accept <6>[ 1351.787423] ok 9 req_cancel after accept <6>[ 1351.795660] ok 10 req_cancel after done <3>[ 1351.799741] # req_destroy works: EXPECTATION FAILED at net/handshake/handshake-test.c:477 <3>[ 1351.799741] Expected handshake_req_destroy_test == req, but <3>[ 1351.799741] handshake_req_destroy_test == 00000000 <3>[ 1351.799741] req == cae22700 <6>[ 1351.803368] not ok 11 req_destroy works <6>[ 1351.804539] # Handshake API tests: pass:10 fail:1 skip:0 total:11 <6>[ 1351.805460] # Totals: pass:16 fail:1 skip:0 total:17 <6>[ 1351.806276] not ok 95 Handshake API tests
Links:
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.5.y/build/v6.5.5-322-g9327d0db36be/testrun/20257175/suite/kunit/test/req_alloc/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.5.y/build/v6.5.5-322-g9327d0db36be/testrun/20257175/suite/kunit/test/req_alloc/details/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/config
Steps to reproduce:
# To install tuxrun to your home directory at ~/.local/bin:
# pip3 install -U --user tuxrun==0.49.2 # # Or install a deb/rpm depending on the running distribution # See https://tuxmake.org/install-deb/ or # https://tuxmake.org/install-rpm/ # # See https://tuxrun.org/ for complete documentation. Link to reproducer, https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/tuxmake_reproducer.sh
or
tuxrun --runtime podman --device qemu-armv7 --boot-args rw --kernel
https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/zImage
--modules https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/modules.tar.xz
--rootfs https://storage.tuxboot.com/debian/bookworm/armhf/rootfs.ext4.xz
--parameters SKIPFILE=skipfile-lkft.yaml --image docker.io/linaro/tuxrun-dispatcher:v0.49.2 --tests kunit --timeouts
boot=30
--
Linaro LKFT
https://lkft.linaro.org
Jakub Kicinski
maintainerIt'd probably make sense to run the path to the test that's failing thru get_maintainer and throw the right people on the CC. Adding Chuck.
Quoted 96 lines · On Thu, 5 Oct 2023 11:25:24 +0530 Naresh Kamboju wrote:
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
While running kunit testing on qemu-armv7 following test failures noticed on stable rc 6.5.6-rc1.
# req_destroy works: EXPECTATION FAILED at net/handshake/handshake-test.c:477Test log:
----------<6>[ 1351.687335] KTAP version 1 <6>[ 1351.688300] # Subtest: Handshake API tests <6>[ 1351.688760] 1..11 <6>[ 1351.689362] KTAP version 1 <6>[ 1351.689985] # Subtest: req_alloc API fuzzing <6>[ 1351.694360] ok 1 handshake_req_alloc NULL proto <6>[ 1351.705855] ok 2 handshake_req_alloc CLASS_NONE <6>[ 1351.710878] ok 3 handshake_req_alloc CLASS_MAX <6>[ 1351.715435] ok 4 handshake_req_alloc no callbacks <6>[ 1351.722026] ok 5 handshake_req_alloc no done callback <6>[ 1351.726579] ok 6 handshake_req_alloc excessive privsize <6>[ 1351.732397] ok 7 handshake_req_alloc all good <6>[ 1351.732934] # req_alloc API fuzzing: pass:7 fail:0 skip:0 total:7 <6>[ 1351.733586] ok 1 req_alloc API fuzzing <6>[ 1351.741251] ok 2 req_submit NULL req arg <6>[ 1351.745979] ok 3 req_submit NULL sock arg <6>[ 1351.753307] ok 4 req_submit NULL sock->file <6>[ 1351.763090] ok 5 req_lookup works <6>[ 1351.770057] ok 6 req_submit max pending <6>[ 1351.774878] ok 7 req_submit multiple <6>[ 1351.782411] ok 8 req_cancel before accept <6>[ 1351.787423] ok 9 req_cancel after accept <6>[ 1351.795660] ok 10 req_cancel after done <3>[ 1351.799741] # req_destroy works: EXPECTATION FAILED at net/handshake/handshake-test.c:477 <3>[ 1351.799741] Expected handshake_req_destroy_test == req, but <3>[ 1351.799741] handshake_req_destroy_test == 00000000 <3>[ 1351.799741] req == cae22700 <6>[ 1351.803368] not ok 11 req_destroy works <6>[ 1351.804539] # Handshake API tests: pass:10 fail:1 skip:0 total:11 <6>[ 1351.805460] # Totals: pass:16 fail:1 skip:0 total:17 <6>[ 1351.806276] not ok 95 Handshake API testsLinks:
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.5.y/build/v6.5.5-322-g9327d0db36be/testrun/20257175/suite/kunit/test/req_alloc/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.5.y/build/v6.5.5-322-g9327d0db36be/testrun/20257175/suite/kunit/test/req_alloc/details/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/configSteps to reproduce:
# To install tuxrun to your home directory at ~/.local/bin:# pip3 install -U --user tuxrun==0.49.2 # # Or install a deb/rpm depending on the running distribution # See https://tuxmake.org/install-deb/ or # https://tuxmake.org/install-rpm/ # # See https://tuxrun.org/ for complete documentation. Link to reproducer, https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/tuxmake_reproducer.shor
tuxrun --runtime podman --device qemu-armv7 --boot-args rw --kernel
https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/zImage
--modules https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJGlCUgDzR8asQbd2BxMssFcEc/modules.tar.xz
--rootfs https://storage.tuxboot.com/debian/bookworm/armhf/rootfs.ext4.xz
--parameters SKIPFILE=skipfile-lkft.yaml --image docker.io/linaro/tuxrun-dispatcher:v0.49.2 --tests kunit --timeouts
boot=30--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
On RISC-V RV64. Bisecting now.
[ 13.215905] ------------[ cut here ]------------
[ 13.220246] bpf_mem_cache[0]: unexpected object size 128, expect 96
[ 13.226554] WARNING: CPU: 0 PID: 1 at kernel/bpf/memalloc.c:384 bpf_mem_alloc_init+0x2f0/0x2f8 [ 13.226581] Modules linked in:
[ 13.226590] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.6-rc1 #2
[ 13.226597] Hardware name: SiFive HiFive Unmatched A00 (DT)
[ 13.226600] epc : bpf_mem_alloc_init+0x2f0/0x2f8
[ 13.226607] ra : bpf_mem_alloc_init+0x2f0/0x2f8
[ 13.226614] epc : ffffffff801d6f68 ra : ffffffff801d6f68 sp : ffffffd88023fd50 [ 13.226619] gp : ffffffff81c48f90 tp : ffffffd880218000 t0 : ffffffff80c58e60 [ 13.226623] t1 : 0000000000000000 t2 : 635f6d656d5f6670 s0 : ffffffd88023fdd0 [ 13.226628] s1 : ffffffff81223bda a0 : 0000000000000000 a1 : 0000000000000000 [ 13.226632] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 13.226636] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000 [ 13.226640] s2 : 0000000000000000 s3 : 0000000000000000 s4 : 0000000000000000 [ 13.226643] s5 : 000000000000000b s6 : ffffffff81cb5110 s7 : ffffffff81c4c238 [ 13.226648] s8 : ffffffff81cb8028 s9 : fffffffb82320370 s10: 00000000ffffffff [ 13.226652] s11: ffffffd7fff82370 t3 : 0000000000000000 t4 : ffffffd880155f00 [ 13.226656] t5 : ffffffd880155000 t6 : ffffffd88023fb48
[ 13.226660] status: 0000000200000120 badaddr: ffffffd7fff82370 cause: 0000000000000003 [ 13.226665] [<ffffffff801d6f68>] bpf_mem_alloc_init+0x2f0/0x2f8
[ 13.226675] [<ffffffff80e16256>] bpf_global_ma_init+0x24/0x40
[ 13.226689] [<ffffffff800029e6>] do_one_initcall+0x5e/0x208
[ 13.226698] [<ffffffff80e016fa>] kernel_init_freeable+0x26c/0x2e6
[ 13.226715] [<ffffffff80c6992c>] kernel_init+0x34/0x180
[ 13.226721] [<ffffffff80003e86>] ret_from_fork+0xe/0x20
[ 13.226729] ---[ end trace 0000000000000000 ]---
Quoted 15 lines · Ron Economos
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.5.y and the diffstat can be found below.
Quoted 5 lines
Quoted 4 lines
thanks,
greg k-h
On RISC-V RV64. Bisecting now.
Naresh already reported that they have tracked down missing commits, see:
https://lore.kernel.org/r/CA+G9fYvHPnba-0=uGS70EjcPgHht13j3s-_fmd2=srL0xyPjNg@mail.gmail.com
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
Build results:
total: 157 pass: 157 fail: 0 Qemu test results: total: 530 pass: 530 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.6 release. There are 321 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
We have one test failure for Tegra, but this is expected at the moment [0].
Test results for stable-v6.5:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 115 pass, 1 failLinux version: 6.5.6-rc1-g9327d0db36be
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Test failures: tegra186-p2771-0000: tegra-audio-dmic-capture.sh
The fixes are now in the mainline, so would be good to pull these when possible.
e765886249c5 ASoC: tegra: Fix redundant PLLA and PLLA_OUT0 updates f101583fa9f8 ASoC: soc-utils: Export snd_soc_dai_is_dummy() symbol
Otherwise ...
Thanks
Jon
[0] https://lore.kernel.org/lkml/[email protected]/
Signature · 1 line
nvpublic