* [PATCH 4.19 01/39] fs: prevent out-of-bounds array speculation when closing a file descriptor
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 02/39] x86/CPU/AMD: Disable XSAVES on AMD family 0x17 Greg Kroah-Hartman
` (42 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Theodore Tso, Al Viro
From: Theodore Ts'o <tytso@mit.edu>
commit 609d54441493c99f21c1823dfd66fa7f4c512ff4 upstream.
Google-Bug-Id: 114199369
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/file.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/file.c
+++ b/fs/file.c
@@ -627,6 +627,7 @@ int __close_fd(struct files_struct *file
fdt = files_fdtable(files);
if (fd >= fdt->max_fds)
goto out_unlock;
+ fd = array_index_nospec(fd, fdt->max_fds);
file = fdt->fd[fd];
if (!file)
goto out_unlock;
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 02/39] x86/CPU/AMD: Disable XSAVES on AMD family 0x17
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 01/39] fs: prevent out-of-bounds array speculation when closing a file descriptor Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 03/39] ext4: fix RENAME_WHITEOUT handling for inline directories Greg Kroah-Hartman
` (41 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Tavis Ormandy, Andrew Cooper,
Borislav Petkov (AMD),
stable
From: Andrew Cooper <andrew.cooper3@citrix.com>
commit b0563468eeac88ebc70559d52a0b66efc37e4e9d upstream.
AMD Erratum 1386 is summarised as:
XSAVES Instruction May Fail to Save XMM Registers to the Provided
State Save Area
This piece of accidental chronomancy causes the %xmm registers to
occasionally reset back to an older value.
Ignore the XSAVES feature on all AMD Zen1/2 hardware. The XSAVEC
instruction (which works fine) is equivalent on affected parts.
[ bp: Typos, move it into the F17h-specific function. ]
Reported-by: Tavis Ormandy <taviso@gmail.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/20230307174643.1240184-1-andrew.cooper3@citrix.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/amd.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -199,6 +199,15 @@ static void init_amd_k6(struct cpuinfo_x
return;
}
#endif
+ /*
+ * Work around Erratum 1386. The XSAVES instruction malfunctions in
+ * certain circumstances on Zen1/2 uarch, and not all parts have had
+ * updated microcode at the time of writing (March 2023).
+ *
+ * Affected parts all have no supervisor XSAVE states, meaning that
+ * the XSAVEC instruction (which works fine) is equivalent.
+ */
+ clear_cpu_cap(c, X86_FEATURE_XSAVES);
}
static void init_amd_k7(struct cpuinfo_x86 *c)
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 03/39] ext4: fix RENAME_WHITEOUT handling for inline directories
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 01/39] fs: prevent out-of-bounds array speculation when closing a file descriptor Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 02/39] x86/CPU/AMD: Disable XSAVES on AMD family 0x17 Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 04/39] ext4: fix another off-by-one fsmap error on 1k block filesystems Greg Kroah-Hartman
` (40 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Eric Whitney, Jan Kara,
Theodore Tso
From: Eric Whitney <enwlinux@gmail.com>
commit c9f62c8b2dbf7240536c0cc9a4529397bb8bf38e upstream.
A significant number of xfstests can cause ext4 to log one or more
warning messages when they are run on a test file system where the
inline_data feature has been enabled. An example:
"EXT4-fs warning (device vdc): ext4_dirblock_csum_set:425: inode
#16385: comm fsstress: No space for directory leaf checksum. Please
run e2fsck -D."
The xfstests include: ext4/057, 058, and 307; generic/013, 051, 068,
070, 076, 078, 083, 232, 269, 270, 390, 461, 475, 476, 482, 579, 585,
589, 626, 631, and 650.
In this situation, the warning message indicates a bug in the code that
performs the RENAME_WHITEOUT operation on a directory entry that has
been stored inline. It doesn't detect that the directory is stored
inline, and incorrectly attempts to compute a dirent block checksum on
the whiteout inode when creating it. This attempt fails as a result
of the integrity checking in get_dirent_tail (usually due to a failure
to match the EXT4_FT_DIR_CSUM magic cookie), and the warning message
is then emitted.
Fix this by simply collecting the inlined data state at the time the
search for the source directory entry is performed. Existing code
handles the rest, and this is sufficient to eliminate all spurious
warning messages produced by the tests above. Go one step further
and do the same in the code that resets the source directory entry in
the event of failure. The inlined state should be present in the
"old" struct, but given the possibility of a race there's no harm
in taking a conservative approach and getting that information again
since the directory entry is being reread anyway.
Fixes: b7ff91fd030d ("ext4: find old entry again if failed to rename whiteout")
Cc: stable@kernel.org
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20230210173244.679890-1-enwlinux@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/namei.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1419,11 +1419,10 @@ static struct buffer_head *__ext4_find_e
int has_inline_data = 1;
ret = ext4_find_inline_entry(dir, fname, res_dir,
&has_inline_data);
- if (has_inline_data) {
- if (inlined)
- *inlined = 1;
+ if (inlined)
+ *inlined = has_inline_data;
+ if (has_inline_data)
goto cleanup_and_exit;
- }
}
if ((namelen <= 2) && (name[0] == '.') &&
@@ -3515,7 +3514,8 @@ static void ext4_resetent(handle_t *hand
* so the old->de may no longer valid and need to find it again
* before reset old inode info.
*/
- old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, NULL);
+ old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de,
+ &old.inlined);
if (IS_ERR(old.bh))
retval = PTR_ERR(old.bh);
if (!old.bh)
@@ -3677,7 +3677,8 @@ static int ext4_rename(struct inode *old
return retval;
}
- old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, NULL);
+ old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de,
+ &old.inlined);
if (IS_ERR(old.bh))
return PTR_ERR(old.bh);
/*
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 04/39] ext4: fix another off-by-one fsmap error on 1k block filesystems
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 03/39] ext4: fix RENAME_WHITEOUT handling for inline directories Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 05/39] ext4: move where set the MAY_INLINE_DATA flag is set Greg Kroah-Hartman
` (39 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, syzbot+6be2b977c89f79b6b153,
Darrick J. Wong, Theodore Tso
From: Darrick J. Wong <djwong@kernel.org>
commit c993799baf9c5861f8df91beb80e1611b12efcbd upstream.
Apparently syzbot figured out that issuing this FSMAP call:
struct fsmap_head cmd = {
.fmh_count = ...;
.fmh_keys = {
{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
},
...
};
ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);
Produces this crash if the underlying filesystem is a 1k-block ext4
filesystem:
kernel BUG at fs/ext4/ext4.h:3331!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]
RSP: 0018:ffffc90007c03998 EFLAGS: 00010246
RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000
RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11
RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400
R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001
R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398
FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0
Call Trace:
<TASK>
ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
__ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
__x64_sys_ioctl+0x82/0xa0
do_syscall_64+0x2b/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7fdf20558aff
RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff
RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003
RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010
R13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000
For GETFSMAP calls, the caller selects a physical block device by
writing its block number into fsmap_head.fmh_keys[01].fmr_device.
To query mappings for a subrange of the device, the starting byte of the
range is written to fsmap_head.fmh_keys[0].fmr_physical and the last
byte of the range goes in fsmap_head.fmh_keys[1].fmr_physical.
IOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you'd
set the inputs as follows:
fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3},
fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14},
Which would return you whatever is mapped in the 12 bytes starting at
physical offset 3.
The crash is due to insufficient range validation of keys[1] in
ext4_getfsmap_datadev. On 1k-block filesystems, block 0 is not part of
the filesystem, which means that s_first_data_block is nonzero.
ext4_get_group_no_and_offset subtracts this quantity from the blocknr
argument before cracking it into a group number and a block number
within a group. IOWs, block group 0 spans blocks 1-8192 (1-based)
instead of 0-8191 (0-based) like what happens with larger blocksizes.
The net result of this encoding is that blocknr < s_first_data_block is
not a valid input to this function. The end_fsb variable is set from
the keys that are copied from userspace, which means that in the above
example, its value is zero. That leads to an underflow here:
blocknr = blocknr - le32_to_cpu(es->s_first_data_block);
The division then operates on -1:
offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >>
EXT4_SB(sb)->s_cluster_bits;
Leaving an impossibly large group number (2^32-1) in blocknr.
ext4_getfsmap_check_keys checked that keys[0].fmr_physical and
keys[1].fmr_physical are in increasing order, but
ext4_getfsmap_datadev adjusts keys[0].fmr_physical to be at least
s_first_data_block. This implies that we have to check it again after
the adjustment, which is the piece that I forgot.
Reported-by: syzbot+6be2b977c89f79b6b153@syzkaller.appspotmail.com
Fixes: 4a4956249dac ("ext4: fix off-by-one fsmap error on 1k block filesystems")
Link: https://syzkaller.appspot.com/bug?id=79d5768e9bfe362911ac1a5057a36fc6b5c30002
Cc: stable@vger.kernel.org
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Link: https://lore.kernel.org/r/Y+58NPTH7VNGgzdd@magnolia
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/fsmap.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/ext4/fsmap.c
+++ b/fs/ext4/fsmap.c
@@ -486,6 +486,8 @@ static int ext4_getfsmap_datadev(struct
keys[0].fmr_physical = bofs;
if (keys[1].fmr_physical >= eofs)
keys[1].fmr_physical = eofs - 1;
+ if (keys[1].fmr_physical < keys[0].fmr_physical)
+ return 0;
start_fsb = keys[0].fmr_physical;
end_fsb = keys[1].fmr_physical;
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 05/39] ext4: move where set the MAY_INLINE_DATA flag is set
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 04/39] ext4: fix another off-by-one fsmap error on 1k block filesystems Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 06/39] ext4: fix WARNING in ext4_update_inline_data Greg Kroah-Hartman
` (38 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ye Bin, stable, Jan Kara, Theodore Tso
From: Ye Bin <yebin10@huawei.com>
commit 1dcdce5919115a471bf4921a57f20050c545a236 upstream.
The only caller of ext4_find_inline_data_nolock() that needs setting of
EXT4_STATE_MAY_INLINE_DATA flag is ext4_iget_extra_inode(). In
ext4_write_inline_data_end() we just need to update inode->i_inline_off.
Since we are going to add one more caller that does not need to set
EXT4_STATE_MAY_INLINE_DATA, just move setting of EXT4_STATE_MAY_INLINE_DATA
out to ext4_iget_extra_inode().
Signed-off-by: Ye Bin <yebin10@huawei.com>
Cc: stable@kernel.org
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20230307015253.2232062-2-yebin@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/inline.c | 1 -
fs/ext4/inode.c | 7 ++++++-
2 files changed, 6 insertions(+), 2 deletions(-)
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -157,7 +157,6 @@ int ext4_find_inline_data_nolock(struct
(void *)ext4_raw_inode(&is.iloc));
EXT4_I(inode)->i_inline_size = EXT4_MIN_INLINE_DATA_SIZE +
le32_to_cpu(is.s.here->e_value_size);
- ext4_set_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA);
}
out:
brelse(is.iloc.bh);
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4865,8 +4865,13 @@ static inline int ext4_iget_extra_inode(
if (EXT4_INODE_HAS_XATTR_SPACE(inode) &&
*magic == cpu_to_le32(EXT4_XATTR_MAGIC)) {
+ int err;
+
ext4_set_inode_state(inode, EXT4_STATE_XATTR);
- return ext4_find_inline_data_nolock(inode);
+ err = ext4_find_inline_data_nolock(inode);
+ if (!err && ext4_has_inline_data(inode))
+ ext4_set_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA);
+ return err;
} else
EXT4_I(inode)->i_inline_off = 0;
return 0;
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 06/39] ext4: fix WARNING in ext4_update_inline_data
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 05/39] ext4: move where set the MAY_INLINE_DATA flag is set Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 07/39] ext4: zero i_disksize when initializing the bootloader inode Greg Kroah-Hartman
` (37 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, syzbot+d30838395804afc2fa6f, stable,
Ye Bin, Jan Kara, Theodore Tso
From: Ye Bin <yebin10@huawei.com>
commit 2b96b4a5d9443ca4cad58b0040be455803c05a42 upstream.
Syzbot found the following issue:
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
Modules linked in:
CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246
RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000
RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248
RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220
R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40
R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c
FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__alloc_pages_node include/linux/gfp.h:237 [inline]
alloc_pages_node include/linux/gfp.h:260 [inline]
__kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113
__do_kmalloc_node mm/slab_common.c:956 [inline]
__kmalloc+0xfe/0x190 mm/slab_common.c:981
kmalloc include/linux/slab.h:584 [inline]
kzalloc include/linux/slab.h:720 [inline]
ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346
ext4_update_inline_dir fs/ext4/inline.c:1115 [inline]
ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307
ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385
ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772
ext4_create+0x36c/0x560 fs/ext4/namei.c:2817
lookup_open fs/namei.c:3413 [inline]
open_last_lookups fs/namei.c:3481 [inline]
path_openat+0x12ac/0x2dd0 fs/namei.c:3711
do_filp_open+0x264/0x4f0 fs/namei.c:3741
do_sys_openat2+0x124/0x4e0 fs/open.c:1310
do_sys_open fs/open.c:1326 [inline]
__do_sys_openat fs/open.c:1342 [inline]
__se_sys_openat fs/open.c:1337 [inline]
__x64_sys_openat+0x243/0x290 fs/open.c:1337
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Above issue happens as follows:
ext4_iget
ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60
ext4_try_add_inline_entry
__ext4_mark_inode_dirty
ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44
ext4_xattr_shift_entries
->after shift i_inline_off is incorrect, actually is change to 176
ext4_try_add_inline_entry
ext4_update_inline_dir
get_max_inline_xattr_value_size
if (EXT4_I(inode)->i_inline_off)
entry = (struct ext4_xattr_entry *)((void *)raw_inode +
EXT4_I(inode)->i_inline_off);
free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size));
->As entry is incorrect, then 'free' may be negative
ext4_update_inline_data
value = kzalloc(len, GFP_NOFS);
-> len is unsigned int, maybe very large, then trigger warning when
'kzalloc()'
To resolve the above issue we need to update 'i_inline_off' after
'ext4_xattr_shift_entries()'. We do not need to set
EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty()
already sets this flag if needed. Setting EXT4_STATE_MAY_INLINE_DATA
when it is needed may trigger a BUG_ON in ext4_writepages().
Reported-by: syzbot+d30838395804afc2fa6f@syzkaller.appspotmail.com
Cc: stable@kernel.org
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20230307015253.2232062-3-yebin@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/xattr.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -2823,6 +2823,9 @@ shift:
(void *)header, total_ino);
EXT4_I(inode)->i_extra_isize = new_extra_isize;
+ if (ext4_has_inline_data(inode))
+ error = ext4_find_inline_data_nolock(inode);
+
cleanup:
if (error && (mnt_count != le16_to_cpu(sbi->s_es->s_mnt_count))) {
ext4_warning(inode->i_sb, "Unable to expand inode %lu. Delete some EAs or run e2fsck.",
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 07/39] ext4: zero i_disksize when initializing the bootloader inode
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 06/39] ext4: fix WARNING in ext4_update_inline_data Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 08/39] nfc: change order inside nfc_se_io error path Greg Kroah-Hartman
` (36 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, stable, Zhihao Cheng, Theodore Tso
From: Zhihao Cheng <chengzhihao1@huawei.com>
commit f5361da1e60d54ec81346aee8e3d8baf1be0b762 upstream.
If the boot loader inode has never been used before, the
EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the
i_size to 0. However, if the "never before used" boot loader has a
non-zero i_size, then i_disksize will be non-zero, and the
inconsistency between i_size and i_disksize can trigger a kernel
warning:
WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa
RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
Call Trace:
vfs_write+0x3b1/0x5c0
ksys_write+0x77/0x160
__x64_sys_write+0x22/0x30
do_syscall_64+0x39/0x80
Reproducer:
1. create corrupted image and mount it:
mke2fs -t ext4 /tmp/foo.img 200
debugfs -wR "sif <5> size 25700" /tmp/foo.img
mount -t ext4 /tmp/foo.img /mnt
cd /mnt
echo 123 > file
2. Run the reproducer program:
posix_memalign(&buf, 1024, 1024)
fd = open("file", O_RDWR | O_DIRECT);
ioctl(fd, EXT4_IOC_SWAP_BOOT);
write(fd, buf, 1024);
Fix this by setting i_disksize as well as i_size to zero when
initiaizing the boot loader inode.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159
Cc: stable@kernel.org
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/ioctl.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -178,6 +178,7 @@ static long swap_inode_boot_loader(struc
ei_bl->i_flags = 0;
inode_set_iversion(inode_bl, 1);
i_size_write(inode_bl, 0);
+ EXT4_I(inode_bl)->i_disksize = inode_bl->i_size;
inode_bl->i_mode = S_IFREG;
if (ext4_has_feature_extents(sb)) {
ext4_set_inode_flag(inode_bl, EXT4_INODE_EXTENTS);
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 08/39] nfc: change order inside nfc_se_io error path
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 07/39] ext4: zero i_disksize when initializing the bootloader inode Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 09/39] udf: Explain handling of load_nls() failure Greg Kroah-Hartman
` (35 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Fedor Pchelkin,
Jakub Kicinski
From: Fedor Pchelkin <pchelkin@ispras.ru>
commit 7d834b4d1ab66c48e8c0810fdeadaabb80fa2c81 upstream.
cb_context should be freed on the error path in nfc_se_io as stated by
commit 25ff6f8a5a3b ("nfc: fix memory leak of se_io context in
nfc_genl_se_io").
Make the error path in nfc_se_io unwind everything in reverse order, i.e.
free the cb_context after unlocking the device.
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230306212650.230322-1-pchelkin@ispras.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/nfc/netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -1464,8 +1464,8 @@ static int nfc_se_io(struct nfc_dev *dev
return rc;
error:
- kfree(cb_context);
device_unlock(&dev->dev);
+ kfree(cb_context);
return rc;
}
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 09/39] udf: Explain handling of load_nls() failure
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 08/39] nfc: change order inside nfc_se_io error path Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 10/39] udf: reduce leakage of blocks related to named streams Greg Kroah-Hartman
` (34 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jan Kara, Sasha Levin
From: Jan Kara <jack@suse.cz>
[ Upstream commit a768a9abc625d554f7b6428517089c193fcb5962 ]
Add comment explaining that load_nls() failure gets handled back in
udf_fill_super() to avoid false impression that it is unhandled.
Signed-off-by: Jan Kara <jack@suse.cz>
Stable-dep-of: fc8033a34a3c ("udf: Preserve link count of system files")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/udf/super.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index b7fb7cd35d89a..5d179616578cf 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -572,6 +572,11 @@ static int udf_parse_options(char *options, struct udf_options *uopt,
if (!remount) {
if (uopt->nls_map)
unload_nls(uopt->nls_map);
+ /*
+ * load_nls() failure is handled later in
+ * udf_fill_super() after all options are
+ * parsed.
+ */
uopt->nls_map = load_nls(args[0].from);
uopt->flags |= (1 << UDF_FLAG_NLS_MAP);
}
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 10/39] udf: reduce leakage of blocks related to named streams
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 09/39] udf: Explain handling of load_nls() failure Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 11/39] udf: Remove pointless union in udf_inode_info Greg Kroah-Hartman
` (33 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Steven J. Magnani, Jan Kara, Sasha Levin
From: Steven J. Magnani <steve.magnani@digidescorp.com>
[ Upstream commit ab9a3a737284b3d9e1d2ba43a0ef31b3ef2e2417 ]
Windows is capable of creating UDF files having named streams.
One example is the "Zone.Identifier" stream attached automatically
to files downloaded from a network. See:
https://msdn.microsoft.com/en-us/library/dn392609.aspx
Modification of a file having one or more named streams in Linux causes
the stream directory to become detached from the file, essentially leaking
all blocks pertaining to the file's streams.
Fix by saving off information about an inode's streams when reading it,
for later use when its on-disk data is updated.
Link: https://lore.kernel.org/r/20190814125002.10869-1-steve@digidescorp.com
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Stable-dep-of: fc8033a34a3c ("udf: Preserve link count of system files")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/udf/inode.c | 24 +++++++++++++++++++++++-
fs/udf/super.c | 2 ++
fs/udf/udf_i.h | 5 ++++-
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index af1180104e560..99d297b667ce1 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1470,6 +1470,8 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode)
iinfo->i_lenEAttr = le32_to_cpu(fe->lengthExtendedAttr);
iinfo->i_lenAlloc = le32_to_cpu(fe->lengthAllocDescs);
iinfo->i_checkpoint = le32_to_cpu(fe->checkpoint);
+ iinfo->i_streamdir = 0;
+ iinfo->i_lenStreams = 0;
} else {
inode->i_blocks = le64_to_cpu(efe->logicalBlocksRecorded) <<
(inode->i_sb->s_blocksize_bits - 9);
@@ -1483,6 +1485,16 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode)
iinfo->i_lenEAttr = le32_to_cpu(efe->lengthExtendedAttr);
iinfo->i_lenAlloc = le32_to_cpu(efe->lengthAllocDescs);
iinfo->i_checkpoint = le32_to_cpu(efe->checkpoint);
+
+ /* Named streams */
+ iinfo->i_streamdir = (efe->streamDirectoryICB.extLength != 0);
+ iinfo->i_locStreamdir =
+ lelb_to_cpu(efe->streamDirectoryICB.extLocation);
+ iinfo->i_lenStreams = le64_to_cpu(efe->objectSize);
+ if (iinfo->i_lenStreams >= inode->i_size)
+ iinfo->i_lenStreams -= inode->i_size;
+ else
+ iinfo->i_lenStreams = 0;
}
inode->i_generation = iinfo->i_unique;
@@ -1745,9 +1757,19 @@ static int udf_update_inode(struct inode *inode, int do_sync)
iinfo->i_ext.i_data,
inode->i_sb->s_blocksize -
sizeof(struct extendedFileEntry));
- efe->objectSize = cpu_to_le64(inode->i_size);
+ efe->objectSize =
+ cpu_to_le64(inode->i_size + iinfo->i_lenStreams);
efe->logicalBlocksRecorded = cpu_to_le64(lb_recorded);
+ if (iinfo->i_streamdir) {
+ struct long_ad *icb_lad = &efe->streamDirectoryICB;
+
+ icb_lad->extLocation =
+ cpu_to_lelb(iinfo->i_locStreamdir);
+ icb_lad->extLength =
+ cpu_to_le32(inode->i_sb->s_blocksize);
+ }
+
udf_adjust_time(iinfo, inode->i_atime);
udf_adjust_time(iinfo, inode->i_mtime);
udf_adjust_time(iinfo, inode->i_ctime);
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 5d179616578cf..ec082b27e9fba 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -146,9 +146,11 @@ static struct inode *udf_alloc_inode(struct super_block *sb)
ei->i_unique = 0;
ei->i_lenExtents = 0;
+ ei->i_lenStreams = 0;
ei->i_next_alloc_block = 0;
ei->i_next_alloc_goal = 0;
ei->i_strat4096 = 0;
+ ei->i_streamdir = 0;
init_rwsem(&ei->i_data_sem);
ei->cached_extent.lstart = -1;
spin_lock_init(&ei->i_extent_cache_lock);
diff --git a/fs/udf/udf_i.h b/fs/udf/udf_i.h
index 2ef0e212f08a3..00d773d1b7cf0 100644
--- a/fs/udf/udf_i.h
+++ b/fs/udf/udf_i.h
@@ -42,12 +42,15 @@ struct udf_inode_info {
unsigned i_efe : 1; /* extendedFileEntry */
unsigned i_use : 1; /* unallocSpaceEntry */
unsigned i_strat4096 : 1;
- unsigned reserved : 26;
+ unsigned i_streamdir : 1;
+ unsigned reserved : 25;
union {
struct short_ad *i_sad;
struct long_ad *i_lad;
__u8 *i_data;
} i_ext;
+ struct kernel_lb_addr i_locStreamdir;
+ __u64 i_lenStreams;
struct rw_semaphore i_data_sem;
struct udf_ext_cache cached_extent;
/* Spinlock for protecting extent cache */
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 11/39] udf: Remove pointless union in udf_inode_info
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 10/39] udf: reduce leakage of blocks related to named streams Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 12/39] udf: Preserve link count of system files Greg Kroah-Hartman
` (32 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jan Kara, Sasha Levin
From: Jan Kara <jack@suse.cz>
[ Upstream commit 382a2287bf9cd283206764572f66ab12657218aa ]
We use only a single member out of the i_ext union in udf_inode_info.
Just remove the pointless union.
Signed-off-by: Jan Kara <jack@suse.cz>
Stable-dep-of: fc8033a34a3c ("udf: Preserve link count of system files")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/udf/directory.c | 2 +-
fs/udf/file.c | 7 +++----
fs/udf/ialloc.c | 14 +++++++-------
fs/udf/inode.c | 36 +++++++++++++++++-------------------
fs/udf/misc.c | 6 +++---
fs/udf/namei.c | 7 +++----
fs/udf/partition.c | 2 +-
fs/udf/super.c | 4 ++--
fs/udf/symlink.c | 2 +-
fs/udf/udf_i.h | 6 +-----
10 files changed, 39 insertions(+), 47 deletions(-)
diff --git a/fs/udf/directory.c b/fs/udf/directory.c
index d9523013096f9..73720320f0ab7 100644
--- a/fs/udf/directory.c
+++ b/fs/udf/directory.c
@@ -34,7 +34,7 @@ struct fileIdentDesc *udf_fileident_read(struct inode *dir, loff_t *nf_pos,
fibh->soffset = fibh->eoffset;
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
- fi = udf_get_fileident(iinfo->i_ext.i_data -
+ fi = udf_get_fileident(iinfo->i_data -
(iinfo->i_efe ?
sizeof(struct extendedFileEntry) :
sizeof(struct fileEntry)),
diff --git a/fs/udf/file.c b/fs/udf/file.c
index 88b7fb8e9998c..8fff7ffc33a81 100644
--- a/fs/udf/file.c
+++ b/fs/udf/file.c
@@ -50,7 +50,7 @@ static void __udf_adinicb_readpage(struct page *page)
* So just sample it once and use the same value everywhere.
*/
kaddr = kmap_atomic(page);
- memcpy(kaddr, iinfo->i_ext.i_data + iinfo->i_lenEAttr, isize);
+ memcpy(kaddr, iinfo->i_data + iinfo->i_lenEAttr, isize);
memset(kaddr + isize, 0, PAGE_SIZE - isize);
flush_dcache_page(page);
SetPageUptodate(page);
@@ -76,8 +76,7 @@ static int udf_adinicb_writepage(struct page *page,
BUG_ON(!PageLocked(page));
kaddr = kmap_atomic(page);
- memcpy(iinfo->i_ext.i_data + iinfo->i_lenEAttr, kaddr,
- i_size_read(inode));
+ memcpy(iinfo->i_data + iinfo->i_lenEAttr, kaddr, i_size_read(inode));
SetPageUptodate(page);
kunmap_atomic(kaddr);
mark_inode_dirty(inode);
@@ -213,7 +212,7 @@ long udf_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
return put_user(UDF_I(inode)->i_lenEAttr, (int __user *)arg);
case UDF_GETEABLOCK:
return copy_to_user((char __user *)arg,
- UDF_I(inode)->i_ext.i_data,
+ UDF_I(inode)->i_data,
UDF_I(inode)->i_lenEAttr) ? -EFAULT : 0;
default:
return -ENOIOCTLCMD;
diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
index f8e5872f7cc27..cdaa86e077b29 100644
--- a/fs/udf/ialloc.c
+++ b/fs/udf/ialloc.c
@@ -67,16 +67,16 @@ struct inode *udf_new_inode(struct inode *dir, umode_t mode)
iinfo->i_efe = 1;
if (UDF_VERS_USE_EXTENDED_FE > sbi->s_udfrev)
sbi->s_udfrev = UDF_VERS_USE_EXTENDED_FE;
- iinfo->i_ext.i_data = kzalloc(inode->i_sb->s_blocksize -
- sizeof(struct extendedFileEntry),
- GFP_KERNEL);
+ iinfo->i_data = kzalloc(inode->i_sb->s_blocksize -
+ sizeof(struct extendedFileEntry),
+ GFP_KERNEL);
} else {
iinfo->i_efe = 0;
- iinfo->i_ext.i_data = kzalloc(inode->i_sb->s_blocksize -
- sizeof(struct fileEntry),
- GFP_KERNEL);
+ iinfo->i_data = kzalloc(inode->i_sb->s_blocksize -
+ sizeof(struct fileEntry),
+ GFP_KERNEL);
}
- if (!iinfo->i_ext.i_data) {
+ if (!iinfo->i_data) {
iput(inode);
return ERR_PTR(-ENOMEM);
}
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 99d297b667ce1..415f1186d250f 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -150,8 +150,8 @@ void udf_evict_inode(struct inode *inode)
truncate_inode_pages_final(&inode->i_data);
invalidate_inode_buffers(inode);
clear_inode(inode);
- kfree(iinfo->i_ext.i_data);
- iinfo->i_ext.i_data = NULL;
+ kfree(iinfo->i_data);
+ iinfo->i_data = NULL;
udf_clear_extent_cache(inode);
if (want_delete) {
udf_free_inode(inode);
@@ -278,14 +278,14 @@ int udf_expand_file_adinicb(struct inode *inode)
kaddr = kmap_atomic(page);
memset(kaddr + iinfo->i_lenAlloc, 0x00,
PAGE_SIZE - iinfo->i_lenAlloc);
- memcpy(kaddr, iinfo->i_ext.i_data + iinfo->i_lenEAttr,
+ memcpy(kaddr, iinfo->i_data + iinfo->i_lenEAttr,
iinfo->i_lenAlloc);
flush_dcache_page(page);
SetPageUptodate(page);
kunmap_atomic(kaddr);
}
down_write(&iinfo->i_data_sem);
- memset(iinfo->i_ext.i_data + iinfo->i_lenEAttr, 0x00,
+ memset(iinfo->i_data + iinfo->i_lenEAttr, 0x00,
iinfo->i_lenAlloc);
iinfo->i_lenAlloc = 0;
if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_USE_SHORT_AD))
@@ -303,8 +303,7 @@ int udf_expand_file_adinicb(struct inode *inode)
lock_page(page);
down_write(&iinfo->i_data_sem);
kaddr = kmap_atomic(page);
- memcpy(iinfo->i_ext.i_data + iinfo->i_lenEAttr, kaddr,
- inode->i_size);
+ memcpy(iinfo->i_data + iinfo->i_lenEAttr, kaddr, inode->i_size);
kunmap_atomic(kaddr);
unlock_page(page);
iinfo->i_alloc_type = ICBTAG_FLAG_AD_IN_ICB;
@@ -392,8 +391,7 @@ struct buffer_head *udf_expand_dir_adinicb(struct inode *inode,
}
mark_buffer_dirty_inode(dbh, inode);
- memset(iinfo->i_ext.i_data + iinfo->i_lenEAttr, 0,
- iinfo->i_lenAlloc);
+ memset(iinfo->i_data + iinfo->i_lenEAttr, 0, iinfo->i_lenAlloc);
iinfo->i_lenAlloc = 0;
eloc.logicalBlockNum = *block;
eloc.partitionReferenceNum =
@@ -1241,7 +1239,7 @@ int udf_setsize(struct inode *inode, loff_t newsize)
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
down_write(&iinfo->i_data_sem);
udf_clear_extent_cache(inode);
- memset(iinfo->i_ext.i_data + iinfo->i_lenEAttr + newsize,
+ memset(iinfo->i_data + iinfo->i_lenEAttr + newsize,
0x00, bsize - newsize -
udf_file_entry_alloc_offset(inode));
iinfo->i_lenAlloc = newsize;
@@ -1390,7 +1388,7 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode)
sizeof(struct extendedFileEntry));
if (ret)
goto out;
- memcpy(iinfo->i_ext.i_data,
+ memcpy(iinfo->i_data,
bh->b_data + sizeof(struct extendedFileEntry),
bs - sizeof(struct extendedFileEntry));
} else if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_FE)) {
@@ -1399,7 +1397,7 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode)
ret = udf_alloc_i_data(inode, bs - sizeof(struct fileEntry));
if (ret)
goto out;
- memcpy(iinfo->i_ext.i_data,
+ memcpy(iinfo->i_data,
bh->b_data + sizeof(struct fileEntry),
bs - sizeof(struct fileEntry));
} else if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_USE)) {
@@ -1412,7 +1410,7 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode)
sizeof(struct unallocSpaceEntry));
if (ret)
goto out;
- memcpy(iinfo->i_ext.i_data,
+ memcpy(iinfo->i_data,
bh->b_data + sizeof(struct unallocSpaceEntry),
bs - sizeof(struct unallocSpaceEntry));
return 0;
@@ -1591,8 +1589,8 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode)
static int udf_alloc_i_data(struct inode *inode, size_t size)
{
struct udf_inode_info *iinfo = UDF_I(inode);
- iinfo->i_ext.i_data = kmalloc(size, GFP_KERNEL);
- if (!iinfo->i_ext.i_data)
+ iinfo->i_data = kmalloc(size, GFP_KERNEL);
+ if (!iinfo->i_data)
return -ENOMEM;
return 0;
}
@@ -1666,7 +1664,7 @@ static int udf_update_inode(struct inode *inode, int do_sync)
use->lengthAllocDescs = cpu_to_le32(iinfo->i_lenAlloc);
memcpy(bh->b_data + sizeof(struct unallocSpaceEntry),
- iinfo->i_ext.i_data, inode->i_sb->s_blocksize -
+ iinfo->i_data, inode->i_sb->s_blocksize -
sizeof(struct unallocSpaceEntry));
use->descTag.tagIdent = cpu_to_le16(TAG_IDENT_USE);
crclen = sizeof(struct unallocSpaceEntry);
@@ -1735,7 +1733,7 @@ static int udf_update_inode(struct inode *inode, int do_sync)
if (iinfo->i_efe == 0) {
memcpy(bh->b_data + sizeof(struct fileEntry),
- iinfo->i_ext.i_data,
+ iinfo->i_data,
inode->i_sb->s_blocksize - sizeof(struct fileEntry));
fe->logicalBlocksRecorded = cpu_to_le64(lb_recorded);
@@ -1754,7 +1752,7 @@ static int udf_update_inode(struct inode *inode, int do_sync)
crclen = sizeof(struct fileEntry);
} else {
memcpy(bh->b_data + sizeof(struct extendedFileEntry),
- iinfo->i_ext.i_data,
+ iinfo->i_data,
inode->i_sb->s_blocksize -
sizeof(struct extendedFileEntry));
efe->objectSize =
@@ -2050,7 +2048,7 @@ void udf_write_aext(struct inode *inode, struct extent_position *epos,
struct udf_inode_info *iinfo = UDF_I(inode);
if (!epos->bh)
- ptr = iinfo->i_ext.i_data + epos->offset -
+ ptr = iinfo->i_data + epos->offset -
udf_file_entry_alloc_offset(inode) +
iinfo->i_lenEAttr;
else
@@ -2142,7 +2140,7 @@ int8_t udf_current_aext(struct inode *inode, struct extent_position *epos,
if (!epos->bh) {
if (!epos->offset)
epos->offset = udf_file_entry_alloc_offset(inode);
- ptr = iinfo->i_ext.i_data + epos->offset -
+ ptr = iinfo->i_data + epos->offset -
udf_file_entry_alloc_offset(inode) +
iinfo->i_lenEAttr;
alen = udf_file_entry_alloc_offset(inode) +
diff --git a/fs/udf/misc.c b/fs/udf/misc.c
index 853bcff51043f..1614d308d0f06 100644
--- a/fs/udf/misc.c
+++ b/fs/udf/misc.c
@@ -52,9 +52,9 @@ struct genericFormat *udf_add_extendedattr(struct inode *inode, uint32_t size,
uint16_t crclen;
struct udf_inode_info *iinfo = UDF_I(inode);
- ea = iinfo->i_ext.i_data;
+ ea = iinfo->i_data;
if (iinfo->i_lenEAttr) {
- ad = iinfo->i_ext.i_data + iinfo->i_lenEAttr;
+ ad = iinfo->i_data + iinfo->i_lenEAttr;
} else {
ad = ea;
size += sizeof(struct extendedAttrHeaderDesc);
@@ -153,7 +153,7 @@ struct genericFormat *udf_get_extendedattr(struct inode *inode, uint32_t type,
uint32_t offset;
struct udf_inode_info *iinfo = UDF_I(inode);
- ea = iinfo->i_ext.i_data;
+ ea = iinfo->i_data;
if (iinfo->i_lenEAttr) {
struct extendedAttrHeaderDesc *eahd;
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index ef251622da137..05dd1f45ba90b 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -478,8 +478,7 @@ static struct fileIdentDesc *udf_add_entry(struct inode *dir,
if (dinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
block = dinfo->i_location.logicalBlockNum;
fi = (struct fileIdentDesc *)
- (dinfo->i_ext.i_data +
- fibh->soffset -
+ (dinfo->i_data + fibh->soffset -
udf_ext0_offset(dir) +
dinfo->i_lenEAttr);
} else {
@@ -962,7 +961,7 @@ static int udf_symlink(struct inode *dir, struct dentry *dentry,
mark_buffer_dirty_inode(epos.bh, inode);
ea = epos.bh->b_data + udf_ext0_offset(inode);
} else
- ea = iinfo->i_ext.i_data + iinfo->i_lenEAttr;
+ ea = iinfo->i_data + iinfo->i_lenEAttr;
eoffset = sb->s_blocksize - udf_ext0_offset(inode);
pc = (struct pathComponent *)ea;
@@ -1142,7 +1141,7 @@ static int udf_rename(struct inode *old_dir, struct dentry *old_dentry,
retval = -EIO;
if (old_iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
dir_fi = udf_get_fileident(
- old_iinfo->i_ext.i_data -
+ old_iinfo->i_data -
(old_iinfo->i_efe ?
sizeof(struct extendedFileEntry) :
sizeof(struct fileEntry)),
diff --git a/fs/udf/partition.c b/fs/udf/partition.c
index 090baff83990a..4cbf40575965e 100644
--- a/fs/udf/partition.c
+++ b/fs/udf/partition.c
@@ -65,7 +65,7 @@ uint32_t udf_get_pblock_virt15(struct super_block *sb, uint32_t block,
}
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
- loc = le32_to_cpu(((__le32 *)(iinfo->i_ext.i_data +
+ loc = le32_to_cpu(((__le32 *)(iinfo->i_data +
vdata->s_start_offset))[block]);
goto translate;
}
diff --git a/fs/udf/super.c b/fs/udf/super.c
index ec082b27e9fba..cdaef406f3899 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -174,7 +174,7 @@ static void init_once(void *foo)
{
struct udf_inode_info *ei = (struct udf_inode_info *)foo;
- ei->i_ext.i_data = NULL;
+ ei->i_data = NULL;
inode_init_once(&ei->vfs_inode);
}
@@ -1207,7 +1207,7 @@ static int udf_load_vat(struct super_block *sb, int p_index, int type1_index)
vat20 = (struct virtualAllocationTable20 *)bh->b_data;
} else {
vat20 = (struct virtualAllocationTable20 *)
- vati->i_ext.i_data;
+ vati->i_data;
}
map->s_type_specific.s_virtual.s_start_offset =
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index 6023c97c6da2f..aef3e4d9014d2 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -122,7 +122,7 @@ static int udf_symlink_filler(struct file *file, struct page *page)
down_read(&iinfo->i_data_sem);
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
- symlink = iinfo->i_ext.i_data + iinfo->i_lenEAttr;
+ symlink = iinfo->i_data + iinfo->i_lenEAttr;
} else {
bh = sb_bread(inode->i_sb, pos);
diff --git a/fs/udf/udf_i.h b/fs/udf/udf_i.h
index 00d773d1b7cf0..2a4731314d51f 100644
--- a/fs/udf/udf_i.h
+++ b/fs/udf/udf_i.h
@@ -44,11 +44,7 @@ struct udf_inode_info {
unsigned i_strat4096 : 1;
unsigned i_streamdir : 1;
unsigned reserved : 25;
- union {
- struct short_ad *i_sad;
- struct long_ad *i_lad;
- __u8 *i_data;
- } i_ext;
+ __u8 *i_data;
struct kernel_lb_addr i_locStreamdir;
__u64 i_lenStreams;
struct rw_semaphore i_data_sem;
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 12/39] udf: Preserve link count of system files
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 11/39] udf: Remove pointless union in udf_inode_info Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 13/39] udf: Detect system inodes linked into directory hierarchy Greg Kroah-Hartman
` (31 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jan Kara, Sasha Levin
From: Jan Kara <jack@suse.cz>
[ Upstream commit fc8033a34a3ca7d23353e645e6dde5d364ac5f12 ]
System files in UDF filesystem have link count 0. To not confuse VFS we
fudge the link count to be 1 when reading such inodes however we forget
to restore the link count of 0 when writing such inodes. Fix that.
CC: stable@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/udf/inode.c | 9 +++++++--
fs/udf/super.c | 1 +
fs/udf/udf_i.h | 3 ++-
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 415f1186d250f..7436337914b19 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1375,6 +1375,7 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode)
ret = -EIO;
goto out;
}
+ iinfo->i_hidden = hidden_inode;
iinfo->i_unique = 0;
iinfo->i_lenEAttr = 0;
iinfo->i_lenExtents = 0;
@@ -1694,8 +1695,12 @@ static int udf_update_inode(struct inode *inode, int do_sync)
if (S_ISDIR(inode->i_mode) && inode->i_nlink > 0)
fe->fileLinkCount = cpu_to_le16(inode->i_nlink - 1);
- else
- fe->fileLinkCount = cpu_to_le16(inode->i_nlink);
+ else {
+ if (iinfo->i_hidden)
+ fe->fileLinkCount = cpu_to_le16(0);
+ else
+ fe->fileLinkCount = cpu_to_le16(inode->i_nlink);
+ }
fe->informationLength = cpu_to_le64(inode->i_size);
diff --git a/fs/udf/super.c b/fs/udf/super.c
index cdaef406f3899..bce48a07790cb 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -151,6 +151,7 @@ static struct inode *udf_alloc_inode(struct super_block *sb)
ei->i_next_alloc_goal = 0;
ei->i_strat4096 = 0;
ei->i_streamdir = 0;
+ ei->i_hidden = 0;
init_rwsem(&ei->i_data_sem);
ei->cached_extent.lstart = -1;
spin_lock_init(&ei->i_extent_cache_lock);
diff --git a/fs/udf/udf_i.h b/fs/udf/udf_i.h
index 2a4731314d51f..b77bf713a1b68 100644
--- a/fs/udf/udf_i.h
+++ b/fs/udf/udf_i.h
@@ -43,7 +43,8 @@ struct udf_inode_info {
unsigned i_use : 1; /* unallocSpaceEntry */
unsigned i_strat4096 : 1;
unsigned i_streamdir : 1;
- unsigned reserved : 25;
+ unsigned i_hidden : 1; /* hidden system inode */
+ unsigned reserved : 24;
__u8 *i_data;
struct kernel_lb_addr i_locStreamdir;
__u64 i_lenStreams;
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 13/39] udf: Detect system inodes linked into directory hierarchy
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 12/39] udf: Preserve link count of system files Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 14/39] ARM: dts: exynos: Fix language typo and indentation Greg Kroah-Hartman
` (30 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, syzbot+38695a20b8addcbc1084,
Jan Kara, Sasha Levin
From: Jan Kara <jack@suse.cz>
[ Upstream commit 85a37983ec69cc9fcd188bc37c4de15ee326355a ]
When UDF filesystem is corrupted, hidden system inodes can be linked
into directory hierarchy which is an avenue for further serious
corruption of the filesystem and kernel confusion as noticed by syzbot
fuzzed images. Refuse to access system inodes linked into directory
hierarchy and vice versa.
CC: stable@vger.kernel.org
Reported-by: syzbot+38695a20b8addcbc1084@syzkaller.appspotmail.com
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/udf/inode.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 7436337914b19..77421e65623a1 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1871,8 +1871,13 @@ struct inode *__udf_iget(struct super_block *sb, struct kernel_lb_addr *ino,
if (!inode)
return ERR_PTR(-ENOMEM);
- if (!(inode->i_state & I_NEW))
+ if (!(inode->i_state & I_NEW)) {
+ if (UDF_I(inode)->i_hidden != hidden_inode) {
+ iput(inode);
+ return ERR_PTR(-EFSCORRUPTED);
+ }
return inode;
+ }
memcpy(&UDF_I(inode)->i_location, ino, sizeof(struct kernel_lb_addr));
err = udf_read_inode(inode, hidden_inode);
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 14/39] ARM: dts: exynos: Fix language typo and indentation
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 13/39] udf: Detect system inodes linked into directory hierarchy Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 15/39] ARM: dts: exynos: Override thermal by label in Exynos4210 Greg Kroah-Hartman
` (29 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Sasha Levin
From: Krzysztof Kozlowski <krzk@kernel.org>
[ Upstream commit c31b11c3eb4d41df4038b0441b15f3f0b2fca5d4 ]
Correct language typo and wrong indentation.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Stable-dep-of: 408ab6786dbf ("ARM: dts: exynos: correct TMU phandle in Exynos4210")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos4210.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index b6091c27f155d..0ed9ef75075bc 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -8,7 +8,7 @@
* www.linaro.org
*
* Samsung's Exynos4210 SoC device nodes are listed in this file. Exynos4210
- * based board files can include this file and provide values for board specfic
+ * based board files can include this file and provide values for board specific
* bindings.
*
* Note: This file does not include device nodes for all the controllers in
@@ -379,13 +379,13 @@
trips {
cpu_alert0: cpu-alert-0 {
- temperature = <85000>; /* millicelsius */
+ temperature = <85000>; /* millicelsius */
};
cpu_alert1: cpu-alert-1 {
- temperature = <100000>; /* millicelsius */
+ temperature = <100000>; /* millicelsius */
};
cpu_alert2: cpu-alert-2 {
- temperature = <110000>; /* millicelsius */
+ temperature = <110000>; /* millicelsius */
};
};
};
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 15/39] ARM: dts: exynos: Override thermal by label in Exynos4210
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 14/39] ARM: dts: exynos: Fix language typo and indentation Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 16/39] ARM: dts: exynos: correct TMU phandle " Greg Kroah-Hartman
` (28 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Sasha Levin
From: Krzysztof Kozlowski <krzk@kernel.org>
[ Upstream commit 1708f56081e239a29ed8646aa7fde6853235d93f ]
Using full paths to extend or override a device tree node is error prone
since if there was a typo error, a new node will be created instead of
extending the node as it was desired. This will lead to run-time errors
that could be hard to detect.
A mistyped label on the other hand, will cause a dtc compile error
(during build time).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200830135200.24304-16-krzk@kernel.org
Stable-dep-of: 408ab6786dbf ("ARM: dts: exynos: correct TMU phandle in Exynos4210")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos4210.dtsi | 36 +++++++++++++++----------------
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 0ed9ef75075bc..2ec6c01550564 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -370,26 +370,24 @@
};
};
};
+};
- thermal-zones {
- cpu_thermal: cpu-thermal {
- polling-delay-passive = <0>;
- polling-delay = <0>;
- thermal-sensors = <&tmu 0>;
-
- trips {
- cpu_alert0: cpu-alert-0 {
- temperature = <85000>; /* millicelsius */
- };
- cpu_alert1: cpu-alert-1 {
- temperature = <100000>; /* millicelsius */
- };
- cpu_alert2: cpu-alert-2 {
- temperature = <110000>; /* millicelsius */
- };
- };
- };
- };
+&cpu_alert0 {
+ temperature = <85000>; /* millicelsius */
+};
+
+&cpu_alert1 {
+ temperature = <100000>; /* millicelsius */
+};
+
+&cpu_alert2 {
+ temperature = <110000>; /* millicelsius */
+};
+
+&cpu_thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&tmu 0>;
};
&gic {
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 16/39] ARM: dts: exynos: correct TMU phandle in Exynos4210
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 15/39] ARM: dts: exynos: Override thermal by label in Exynos4210 Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 17/39] ARM: dts: exynos: Add all CPUs in cooling maps Greg Kroah-Hartman
` (27 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Sasha Levin
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
[ Upstream commit 408ab6786dbf6dd696488054c9559681112ef994 ]
TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
it must not have an argument to phandle. Since thermal-sensors property is
already defined in included exynos4-cpu-thermal.dtsi, drop it from
exynos4210.dtsi to fix the error and remoev redundancy.
Fixes: 9843a2236003 ("ARM: dts: Provide dt bindings identical for Exynos TMU")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230209105841.779596-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos4210.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 2ec6c01550564..24bea84034af2 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -387,7 +387,6 @@
&cpu_thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
- thermal-sensors = <&tmu 0>;
};
&gic {
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 17/39] ARM: dts: exynos: Add all CPUs in cooling maps
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 16/39] ARM: dts: exynos: correct TMU phandle " Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 18/39] ARM: dts: exynos: Move pmu and timer nodes out of soc Greg Kroah-Hartman
` (26 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Viresh Kumar, Krzysztof Kozlowski,
Sasha Levin
From: Viresh Kumar <viresh.kumar@linaro.org>
[ Upstream commit 670734f5581023a2e695e82ea662e4d603fd3e8a ]
Each CPU can (and does) participate in cooling down the system but the
DT only captures a handful of them, normally CPU0, in the cooling maps.
Things work by chance currently as under normal circumstances its the
first CPU of each cluster which is used by the operating systems to
probe the cooling devices. But as soon as this CPU ordering changes and
any other CPU is used to bring up the cooling device, we will start
seeing failures.
Also the DT is rather incomplete when we list only one CPU in the
cooling maps, as the hardware doesn't have any such limitations.
Update cooling maps to include all devices affected by individual trip
points.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Stable-dep-of: 33e2c595e2e4 ("ARM: dts: exynos: correct TMU phandle in Exynos5250")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos3250-artik5.dtsi | 6 +-
arch/arm/boot/dts/exynos3250-monk.dts | 6 +-
arch/arm/boot/dts/exynos3250-rinato.dts | 6 +-
arch/arm/boot/dts/exynos4210-trats.dts | 4 +-
arch/arm/boot/dts/exynos4210.dtsi | 2 +-
.../boot/dts/exynos4412-itop-scp-core.dtsi | 8 +-
arch/arm/boot/dts/exynos4412-midas.dtsi | 8 +-
.../boot/dts/exynos4412-odroid-common.dtsi | 8 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 18 ++-
arch/arm/boot/dts/exynos4412.dtsi | 6 +-
arch/arm/boot/dts/exynos5250.dtsi | 7 +-
arch/arm/boot/dts/exynos5422-odroidhc1.dts | 106 +++++++++++-------
.../boot/dts/exynos5422-odroidxu3-common.dtsi | 106 +++++++++++-------
13 files changed, 178 insertions(+), 113 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-artik5.dtsi b/arch/arm/boot/dts/exynos3250-artik5.dtsi
index 6e30db644c83a..86aa0956b2d3b 100644
--- a/arch/arm/boot/dts/exynos3250-artik5.dtsi
+++ b/arch/arm/boot/dts/exynos3250-artik5.dtsi
@@ -36,11 +36,13 @@
cooling-maps {
map0 {
/* Corresponds to 500MHz */
- cooling-device = <&cpu0 5 5>;
+ cooling-device = <&cpu0 5 5>,
+ <&cpu1 5 5>;
};
map1 {
/* Corresponds to 200MHz */
- cooling-device = <&cpu0 8 8>;
+ cooling-device = <&cpu0 8 8>,
+ <&cpu1 8 8>;
};
};
};
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts b/arch/arm/boot/dts/exynos3250-monk.dts
index d343dc13ceecd..c9b6fb65d6861 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -121,11 +121,13 @@
cooling-maps {
map0 {
/* Correspond to 500MHz at freq_table */
- cooling-device = <&cpu0 5 5>;
+ cooling-device = <&cpu0 5 5>,
+ <&cpu1 5 5>;
};
map1 {
/* Correspond to 200MHz at freq_table */
- cooling-device = <&cpu0 8 8>;
+ cooling-device = <&cpu0 8 8>,
+ <&cpu1 8 8>;
};
};
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts b/arch/arm/boot/dts/exynos3250-rinato.dts
index e398604b2ce0f..4eb5f79b1c3b2 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -116,11 +116,13 @@
cooling-maps {
map0 {
/* Corresponds to 500MHz */
- cooling-device = <&cpu0 5 5>;
+ cooling-device = <&cpu0 5 5>,
+ <&cpu1 5 5>;
};
map1 {
/* Corresponds to 200MHz */
- cooling-device = <&cpu0 8 8>;
+ cooling-device = <&cpu0 8 8>,
+ <&cpu1 8 8>;
};
};
};
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
index 6f1d76cb79515..230969556e1ce 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -138,11 +138,11 @@
cooling-maps {
map0 {
/* Corresponds to 800MHz at freq_table */
- cooling-device = <&cpu0 2 2>;
+ cooling-device = <&cpu0 2 2>, <&cpu1 2 2>;
};
map1 {
/* Corresponds to 200MHz at freq_table */
- cooling-device = <&cpu0 4 4>;
+ cooling-device = <&cpu0 4 4>, <&cpu1 4 4>;
};
};
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 24bea84034af2..b7b6edbc0499e 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -51,7 +51,7 @@
#cooling-cells = <2>; /* min followed by max */
};
- cpu@901 {
+ cpu1: cpu@901 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0x901>;
diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
index ab7affab7f1c0..4ca05599ee2ac 100644
--- a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
+++ b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
@@ -45,11 +45,15 @@
cooling-maps {
map0 {
/* Corresponds to 800MHz at freq_table */
- cooling-device = <&cpu0 7 7>;
+ cooling-device = <&cpu0 7 7>, <&cpu1 7 7>,
+ <&cpu2 7 7>, <&cpu3 7 7>;
};
map1 {
/* Corresponds to 200MHz at freq_table */
- cooling-device = <&cpu0 13 13>;
+ cooling-device = <&cpu0 13 13>,
+ <&cpu1 13 13>,
+ <&cpu2 13 13>,
+ <&cpu3 13 13>;
};
};
};
diff --git a/arch/arm/boot/dts/exynos4412-midas.dtsi b/arch/arm/boot/dts/exynos4412-midas.dtsi
index 93c8918e599bd..047240a32097a 100644
--- a/arch/arm/boot/dts/exynos4412-midas.dtsi
+++ b/arch/arm/boot/dts/exynos4412-midas.dtsi
@@ -267,11 +267,15 @@
cooling-maps {
map0 {
/* Corresponds to 800MHz at freq_table */
- cooling-device = <&cpu0 7 7>;
+ cooling-device = <&cpu0 7 7>, <&cpu1 7 7>,
+ <&cpu2 7 7>, <&cpu3 7 7>;
};
map1 {
/* Corresponds to 200MHz at freq_table */
- cooling-device = <&cpu0 13 13>;
+ cooling-device = <&cpu0 13 13>,
+ <&cpu1 13 13>,
+ <&cpu2 13 13>,
+ <&cpu3 13 13>;
};
};
};
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index dbca8eeefae13..e269818668bb1 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -72,11 +72,15 @@
cooling-maps {
cooling_map0: map0 {
/* Corresponds to 800MHz at freq_table */
- cooling-device = <&cpu0 7 7>;
+ cooling-device = <&cpu0 7 7>, <&cpu1 7 7>,
+ <&cpu2 7 7>, <&cpu3 7 7>;
};
cooling_map1: map1 {
/* Corresponds to 200MHz at freq_table */
- cooling-device = <&cpu0 13 13>;
+ cooling-device = <&cpu0 13 13>,
+ <&cpu1 13 13>,
+ <&cpu2 13 13>,
+ <&cpu3 13 13>;
};
};
};
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 459919b65df81..2bdf899df4366 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -45,24 +45,22 @@
cooling-maps {
map0 {
trip = <&cpu_alert1>;
- cooling-device = <&cpu0 9 9>;
+ cooling-device = <&cpu0 9 9>, <&cpu1 9 9>,
+ <&cpu2 9 9>, <&cpu3 9 9>,
+ <&fan0 1 2>;
};
map1 {
trip = <&cpu_alert2>;
- cooling-device = <&cpu0 15 15>;
+ cooling-device = <&cpu0 15 15>,
+ <&cpu1 15 15>,
+ <&cpu2 15 15>,
+ <&cpu3 15 15>,
+ <&fan0 2 3>;
};
map2 {
trip = <&cpu_alert0>;
cooling-device = <&fan0 0 1>;
};
- map3 {
- trip = <&cpu_alert1>;
- cooling-device = <&fan0 1 2>;
- };
- map4 {
- trip = <&cpu_alert2>;
- cooling-device = <&fan0 2 3>;
- };
};
};
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 51f72f0327e52..cd04bb4aea5f8 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -45,7 +45,7 @@
#cooling-cells = <2>; /* min followed by max */
};
- cpu@a01 {
+ cpu1: cpu@a01 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA01>;
@@ -55,7 +55,7 @@
#cooling-cells = <2>; /* min followed by max */
};
- cpu@a02 {
+ cpu2: cpu@a02 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA02>;
@@ -65,7 +65,7 @@
#cooling-cells = <2>; /* min followed by max */
};
- cpu@a03 {
+ cpu3: cpu@a03 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA03>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index b85527faa6ea4..e6b1a8a9b832c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -59,7 +59,7 @@
operating-points-v2 = <&cpu0_opp_table>;
#cooling-cells = <2>; /* min followed by max */
};
- cpu@1 {
+ cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <1>;
@@ -1066,11 +1066,12 @@
cooling-maps {
map0 {
/* Corresponds to 800MHz at freq_table */
- cooling-device = <&cpu0 9 9>;
+ cooling-device = <&cpu0 9 9>, <&cpu1 9 9>;
};
map1 {
/* Corresponds to 200MHz at freq_table */
- cooling-device = <&cpu0 15 15>;
+ cooling-device = <&cpu0 15 15>,
+ <&cpu1 15 15>;
};
};
};
diff --git a/arch/arm/boot/dts/exynos5422-odroidhc1.dts b/arch/arm/boot/dts/exynos5422-odroidhc1.dts
index abc6fb7d27259..fce5a4579693e 100644
--- a/arch/arm/boot/dts/exynos5422-odroidhc1.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidhc1.dts
@@ -56,24 +56,30 @@
*/
map0 {
trip = <&cpu0_alert0>;
- cooling-device = <&cpu0 0 2>;
- };
- map1 {
- trip = <&cpu0_alert0>;
- cooling-device = <&cpu4 0 2>;
+ cooling-device = <&cpu0 0 2>,
+ <&cpu1 0 2>,
+ <&cpu2 0 2>,
+ <&cpu3 0 2>,
+ <&cpu4 0 2>,
+ <&cpu5 0 2>,
+ <&cpu6 0 2>,
+ <&cpu7 0 2>;
};
/*
* When reaching cpu0_alert1, reduce CPU
* further, down to 600 MHz (12 steps for big,
* 7 steps for LITTLE).
*/
- map2 {
- trip = <&cpu0_alert1>;
- cooling-device = <&cpu0 3 7>;
- };
- map3 {
+ map1 {
trip = <&cpu0_alert1>;
- cooling-device = <&cpu4 3 12>;
+ cooling-device = <&cpu0 3 7>,
+ <&cpu1 3 7>,
+ <&cpu2 3 7>,
+ <&cpu3 3 7>,
+ <&cpu4 3 12>,
+ <&cpu5 3 12>,
+ <&cpu6 3 12>,
+ <&cpu7 3 12>;
};
};
};
@@ -99,19 +105,25 @@
cooling-maps {
map0 {
trip = <&cpu1_alert0>;
- cooling-device = <&cpu0 0 2>;
+ cooling-device = <&cpu0 0 2>,
+ <&cpu1 0 2>,
+ <&cpu2 0 2>,
+ <&cpu3 0 2>,
+ <&cpu4 0 2>,
+ <&cpu5 0 2>,
+ <&cpu6 0 2>,
+ <&cpu7 0 2>;
};
map1 {
- trip = <&cpu1_alert0>;
- cooling-device = <&cpu4 0 2>;
- };
- map2 {
- trip = <&cpu1_alert1>;
- cooling-device = <&cpu0 3 7>;
- };
- map3 {
trip = <&cpu1_alert1>;
- cooling-device = <&cpu4 3 12>;
+ cooling-device = <&cpu0 3 7>,
+ <&cpu1 3 7>,
+ <&cpu2 3 7>,
+ <&cpu3 3 7>,
+ <&cpu4 3 12>,
+ <&cpu5 3 12>,
+ <&cpu6 3 12>,
+ <&cpu7 3 12>;
};
};
};
@@ -137,19 +149,25 @@
cooling-maps {
map0 {
trip = <&cpu2_alert0>;
- cooling-device = <&cpu0 0 2>;
+ cooling-device = <&cpu0 0 2>,
+ <&cpu1 0 2>,
+ <&cpu2 0 2>,
+ <&cpu3 0 2>,
+ <&cpu4 0 2>,
+ <&cpu5 0 2>,
+ <&cpu6 0 2>,
+ <&cpu7 0 2>;
};
map1 {
- trip = <&cpu2_alert0>;
- cooling-device = <&cpu4 0 2>;
- };
- map2 {
- trip = <&cpu2_alert1>;
- cooling-device = <&cpu0 3 7>;
- };
- map3 {
trip = <&cpu2_alert1>;
- cooling-device = <&cpu4 3 12>;
+ cooling-device = <&cpu0 3 7>,
+ <&cpu1 3 7>,
+ <&cpu2 3 7>,
+ <&cpu3 3 7>,
+ <&cpu4 3 12>,
+ <&cpu5 3 12>,
+ <&cpu6 3 12>,
+ <&cpu7 3 12>;
};
};
};
@@ -175,19 +193,25 @@
cooling-maps {
map0 {
trip = <&cpu3_alert0>;
- cooling-device = <&cpu0 0 2>;
+ cooling-device = <&cpu0 0 2>,
+ <&cpu1 0 2>,
+ <&cpu2 0 2>,
+ <&cpu3 0 2>,
+ <&cpu4 0 2>,
+ <&cpu5 0 2>,
+ <&cpu6 0 2>,
+ <&cpu7 0 2>;
};
map1 {
- trip = <&cpu3_alert0>;
- cooling-device = <&cpu4 0 2>;
- };
- map2 {
- trip = <&cpu3_alert1>;
- cooling-device = <&cpu0 3 7>;
- };
- map3 {
trip = <&cpu3_alert1>;
- cooling-device = <&cpu4 3 12>;
+ cooling-device = <&cpu0 3 7>,
+ <&cpu1 3 7>,
+ <&cpu2 3 7>,
+ <&cpu3 3 7>,
+ <&cpu4 3 12>,
+ <&cpu5 3 12>,
+ <&cpu6 3 12>,
+ <&cpu7 3 12>;
};
};
};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 96e281c0a118a..264651141d688 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -113,24 +113,30 @@
*/
map3 {
trip = <&cpu0_alert3>;
- cooling-device = <&cpu0 0 2>;
- };
- map4 {
- trip = <&cpu0_alert3>;
- cooling-device = <&cpu4 0 2>;
+ cooling-device = <&cpu0 0 2>,
+ <&cpu1 0 2>,
+ <&cpu2 0 2>,
+ <&cpu3 0 2>,
+ <&cpu4 0 2>,
+ <&cpu5 0 2>,
+ <&cpu6 0 2>,
+ <&cpu7 0 2>;
};
/*
* When reaching cpu0_alert4, reduce CPU
* further, down to 600 MHz (12 steps for big,
* 7 steps for LITTLE).
*/
- map5 {
- trip = <&cpu0_alert4>;
- cooling-device = <&cpu0 3 7>;
- };
- map6 {
+ map4 {
trip = <&cpu0_alert4>;
- cooling-device = <&cpu4 3 12>;
+ cooling-device = <&cpu0 3 7>,
+ <&cpu1 3 7>,
+ <&cpu2 3 7>,
+ <&cpu3 3 7>,
+ <&cpu4 3 12>,
+ <&cpu5 3 12>,
+ <&cpu6 3 12>,
+ <&cpu7 3 12>;
};
};
};
@@ -185,19 +191,25 @@
};
map3 {
trip = <&cpu1_alert3>;
- cooling-device = <&cpu0 0 2>;
+ cooling-device = <&cpu0 0 2>,
+ <&cpu1 0 2>,
+ <&cpu2 0 2>,
+ <&cpu3 0 2>,
+ <&cpu4 0 2>,
+ <&cpu5 0 2>,
+ <&cpu6 0 2>,
+ <&cpu7 0 2>;
};
map4 {
- trip = <&cpu1_alert3>;
- cooling-device = <&cpu4 0 2>;
- };
- map5 {
- trip = <&cpu1_alert4>;
- cooling-device = <&cpu0 3 7>;
- };
- map6 {
trip = <&cpu1_alert4>;
- cooling-device = <&cpu4 3 12>;
+ cooling-device = <&cpu0 3 7>,
+ <&cpu1 3 7>,
+ <&cpu2 3 7>,
+ <&cpu3 3 7>,
+ <&cpu4 3 12>,
+ <&cpu5 3 12>,
+ <&cpu6 3 12>,
+ <&cpu7 3 12>;
};
};
};
@@ -252,19 +264,25 @@
};
map3 {
trip = <&cpu2_alert3>;
- cooling-device = <&cpu0 0 2>;
+ cooling-device = <&cpu0 0 2>,
+ <&cpu1 0 2>,
+ <&cpu2 0 2>,
+ <&cpu3 0 2>,
+ <&cpu4 0 2>,
+ <&cpu5 0 2>,
+ <&cpu6 0 2>,
+ <&cpu7 0 2>;
};
map4 {
- trip = <&cpu2_alert3>;
- cooling-device = <&cpu4 0 2>;
- };
- map5 {
- trip = <&cpu2_alert4>;
- cooling-device = <&cpu0 3 7>;
- };
- map6 {
trip = <&cpu2_alert4>;
- cooling-device = <&cpu4 3 12>;
+ cooling-device = <&cpu0 3 7>,
+ <&cpu1 3 7>,
+ <&cpu2 3 7>,
+ <&cpu3 3 7>,
+ <&cpu4 3 12>,
+ <&cpu5 3 12>,
+ <&cpu6 3 12>,
+ <&cpu7 3 12>;
};
};
};
@@ -319,19 +337,25 @@
};
map3 {
trip = <&cpu3_alert3>;
- cooling-device = <&cpu0 0 2>;
+ cooling-device = <&cpu0 0 2>,
+ <&cpu1 0 2>,
+ <&cpu2 0 2>,
+ <&cpu3 0 2>,
+ <&cpu4 0 2>,
+ <&cpu5 0 2>,
+ <&cpu6 0 2>,
+ <&cpu7 0 2>;
};
map4 {
- trip = <&cpu3_alert3>;
- cooling-device = <&cpu4 0 2>;
- };
- map5 {
- trip = <&cpu3_alert4>;
- cooling-device = <&cpu0 3 7>;
- };
- map6 {
trip = <&cpu3_alert4>;
- cooling-device = <&cpu4 3 12>;
+ cooling-device = <&cpu0 3 7>,
+ <&cpu1 3 7>,
+ <&cpu2 3 7>,
+ <&cpu3 3 7>,
+ <&cpu4 3 12>,
+ <&cpu5 3 12>,
+ <&cpu6 3 12>,
+ <&cpu7 3 12>;
};
};
};
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 18/39] ARM: dts: exynos: Move pmu and timer nodes out of soc
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 17/39] ARM: dts: exynos: Add all CPUs in cooling maps Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 19/39] ARM: dts: exynos: Override thermal by label in Exynos5250 Greg Kroah-Hartman
` (25 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski,
Marek Szyprowski, Sasha Levin
From: Krzysztof Kozlowski <krzk@kernel.org>
[ Upstream commit be00300147ae3c0b2fa4dbc5f00d4332a8d00fac ]
The ARM PMU and ARM architected timer nodes are part of ARM CPU design
therefore they should not be inside the soc node. This also fixes DTC
W=1 warnings like:
arch/arm/boot/dts/exynos3250.dtsi:106.21-135.5:
Warning (simple_bus_reg): /soc/fixed-rate-clocks: missing or empty reg/ranges property
arch/arm/boot/dts/exynos3250.dtsi:676.7-680.5:
Warning (simple_bus_reg): /soc/pmu: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Stable-dep-of: 33e2c595e2e4 ("ARM: dts: exynos: correct TMU phandle in Exynos5250")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos3250.dtsi | 12 +++++-----
arch/arm/boot/dts/exynos4.dtsi | 12 +++++-----
arch/arm/boot/dts/exynos5250.dtsi | 40 +++++++++++++++----------------
arch/arm/boot/dts/exynos54xx.dtsi | 38 ++++++++++++++---------------
4 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 5892a9f7622fa..af54b306204b8 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -97,6 +97,12 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
soc: soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -673,12 +679,6 @@
status = "disabled";
};
- pmu {
- compatible = "arm,cortex-a7-pmu";
- interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
- };
-
ppmu_dmc0: ppmu_dmc0@106a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106a0000 0x2000>;
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f7488833745d..33eb2810cdaa2 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -51,6 +51,12 @@
serial3 = &serial_3;
};
+ pmu: pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 2>, <3 2>;
+ };
+
soc: soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -169,12 +175,6 @@
reg = <0x10440000 0x1000>;
};
- pmu: pmu {
- compatible = "arm,cortex-a9-pmu";
- interrupt-parent = <&combiner>;
- interrupts = <2 2>, <3 2>;
- };
-
sys_reg: syscon@10010000 {
compatible = "samsung,exynos4-sysreg", "syscon";
reg = <0x10010000 0x400>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index e6b1a8a9b832c..59e5f0016b862 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -157,6 +157,12 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <1 2>, <22 4>;
+ };
+
soc: soc {
sysram@2020000 {
compatible = "mmio-sram";
@@ -227,20 +233,6 @@
power-domains = <&pd_mau>;
};
- timer {
- compatible = "arm,armv7-timer";
- interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
- /*
- * Unfortunately we need this since some versions
- * of U-Boot on Exynos don't set the CNTFRQ register,
- * so we need the value from DT.
- */
- clock-frequency = <24000000>;
- };
-
mct@101c0000 {
compatible = "samsung,exynos4210-mct";
reg = <0x101C0000 0x800>;
@@ -265,12 +257,6 @@
};
};
- pmu {
- compatible = "arm,cortex-a15-pmu";
- interrupt-parent = <&combiner>;
- interrupts = <1 2>, <22 4>;
- };
-
pinctrl_0: pinctrl@11400000 {
compatible = "samsung,exynos5250-pinctrl";
reg = <0x11400000 0x1000>;
@@ -1076,6 +1062,20 @@
};
};
};
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ /*
+ * Unfortunately we need this since some versions
+ * of U-Boot on Exynos don't set the CNTFRQ register,
+ * so we need the value from DT.
+ */
+ clock-frequency = <24000000>;
+ };
};
&dp {
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi
index de26e5ee0d2de..ae866bcc30c4e 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -25,27 +25,27 @@
usbdrdphy1 = &usbdrd_phy1;
};
- soc: soc {
- arm_a7_pmu: arm-a7-pmu {
- compatible = "arm,cortex-a7-pmu";
- interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
+ arm_a7_pmu: arm-a7-pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
- arm_a15_pmu: arm-a15-pmu {
- compatible = "arm,cortex-a15-pmu";
- interrupt-parent = <&combiner>;
- interrupts = <1 2>,
- <7 0>,
- <16 6>,
- <19 2>;
- status = "disabled";
- };
+ arm_a15_pmu: arm-a15-pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <1 2>,
+ <7 0>,
+ <16 6>,
+ <19 2>;
+ status = "disabled";
+ };
+ soc: soc {
sysram@2020000 {
compatible = "mmio-sram";
reg = <0x02020000 0x54000>;
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 19/39] ARM: dts: exynos: Override thermal by label in Exynos5250
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 18/39] ARM: dts: exynos: Move pmu and timer nodes out of soc Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 20/39] ARM: dts: exynos: correct TMU phandle " Greg Kroah-Hartman
` (24 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Sasha Levin
From: Krzysztof Kozlowski <krzk@kernel.org>
[ Upstream commit 7e86ef5cc89609cbad8b9dd2f476789c638dbb92 ]
Using full paths to extend or override a device tree node is error prone
since if there was a typo error, a new node will be created instead of
extending the node as it was desired. This will lead to run-time errors
that could be hard to detect.
A mistyped label on the other hand, will cause a dtc compile error
(during build time).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200901075417.22481-8-krzk@kernel.org
Stable-dep-of: 33e2c595e2e4 ("ARM: dts: exynos: correct TMU phandle in Exynos5250")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos5250.dtsi | 38 +++++++++++++++----------------
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 59e5f0016b862..1883b8c2cd7b9 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -1043,26 +1043,6 @@
};
};
- thermal-zones {
- cpu_thermal: cpu-thermal {
- polling-delay-passive = <0>;
- polling-delay = <0>;
- thermal-sensors = <&tmu 0>;
-
- cooling-maps {
- map0 {
- /* Corresponds to 800MHz at freq_table */
- cooling-device = <&cpu0 9 9>, <&cpu1 9 9>;
- };
- map1 {
- /* Corresponds to 200MHz at freq_table */
- cooling-device = <&cpu0 15 15>,
- <&cpu1 15 15>;
- };
- };
- };
- };
-
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
@@ -1078,6 +1058,24 @@
};
};
+&cpu_thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&tmu 0>;
+
+ cooling-maps {
+ map0 {
+ /* Corresponds to 800MHz at freq_table */
+ cooling-device = <&cpu0 9 9>, <&cpu1 9 9>;
+ };
+ map1 {
+ /* Corresponds to 200MHz at freq_table */
+ cooling-device = <&cpu0 15 15>,
+ <&cpu1 15 15>;
+ };
+ };
+};
+
&dp {
power-domains = <&pd_disp1>;
clocks = <&clock CLK_DP>;
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 20/39] ARM: dts: exynos: correct TMU phandle in Exynos5250
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 19/39] ARM: dts: exynos: Override thermal by label in Exynos5250 Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 21/39] kbuild: fix false-positive need-builtin calculation Greg Kroah-Hartman
` (23 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Sasha Levin
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
[ Upstream commit 33e2c595e2e4016991ead44933a29d1ef93d5f26 ]
TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
it must not have an argument to phandle.
Cc: <stable@vger.kernel.org>
Fixes: 9843a2236003 ("ARM: dts: Provide dt bindings identical for Exynos TMU")
Link: https://lore.kernel.org/r/20230209105841.779596-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos5250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 1883b8c2cd7b9..c6b0e6413c683 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -1061,7 +1061,7 @@
&cpu_thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
- thermal-sensors = <&tmu 0>;
+ thermal-sensors = <&tmu>;
cooling-maps {
map0 {
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 21/39] kbuild: fix false-positive need-builtin calculation
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 20/39] ARM: dts: exynos: correct TMU phandle " Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 22/39] kbuild: generate modules.order only in directories visited by obj-y/m Greg Kroah-Hartman
` (22 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Masahiro Yamada, Sasha Levin
From: Masahiro Yamada <yamada.masahiro@socionext.com>
[ Upstream commit d9f78edfd81b9e484423534360350ef7253cc888 ]
The current implementation of need-builtin is false-positive,
for example, in the following Makefile:
obj-m := foo/
obj-y := foo/bar/
..., where foo/built-in.a is not required.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Stable-dep-of: 2e3d0e20d845 ("ARM: dts: exynos: correct TMU phandle in Odroid HC1")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
scripts/Makefile.build | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 64fac0ad32d6b..7635cc05fcfa3 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -541,7 +541,8 @@ targets += $(call intermediate_targets, .asn1.o, .asn1.c .asn1.h) \
PHONY += $(subdir-ym)
$(subdir-ym):
- $(Q)$(MAKE) $(build)=$@ need-builtin=$(if $(findstring $@,$(subdir-obj-y)),1)
+ $(Q)$(MAKE) $(build)=$@ \
+ need-builtin=$(if $(filter $@/built-in.a, $(subdir-obj-y)),1)
# Add FORCE to the prequisites of a target to force it to be always rebuilt.
# ---------------------------------------------------------------------------
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 22/39] kbuild: generate modules.order only in directories visited by obj-y/m
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 21/39] kbuild: fix false-positive need-builtin calculation Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 23/39] ARM: dts: exynos: Add GPU thermal zone cooling maps for Odroid XU3/XU4/HC1 Greg Kroah-Hartman
` (21 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Masahiro Yamada, Sasha Levin
From: Masahiro Yamada <yamada.masahiro@socionext.com>
[ Upstream commit 4f2c8f3089f538f556c86f26603a062865e4aa94 ]
The modules.order files in directories visited by the chain of obj-y
or obj-m are merged to the upper-level ones, and become parts of the
top-level modules.order. On the other hand, there is no need to
generate modules.order in directories visited by subdir-y or subdir-m
since they would become orphan anyway.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Stable-dep-of: 2e3d0e20d845 ("ARM: dts: exynos: correct TMU phandle in Odroid HC1")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
scripts/Makefile.build | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 7635cc05fcfa3..97f59fa3e0ed9 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -542,7 +542,8 @@ targets += $(call intermediate_targets, .asn1.o, .asn1.c .asn1.h) \
PHONY += $(subdir-ym)
$(subdir-ym):
$(Q)$(MAKE) $(build)=$@ \
- need-builtin=$(if $(filter $@/built-in.a, $(subdir-obj-y)),1)
+ need-builtin=$(if $(filter $@/built-in.a, $(subdir-obj-y)),1) \
+ need-modorder=$(if $(need-modorder),$(if $(filter $@/modules.order, $(modorder)),1))
# Add FORCE to the prequisites of a target to force it to be always rebuilt.
# ---------------------------------------------------------------------------
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 23/39] ARM: dts: exynos: Add GPU thermal zone cooling maps for Odroid XU3/XU4/HC1
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 22/39] kbuild: generate modules.order only in directories visited by obj-y/m Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 24/39] ARM: dts: exynos: correct TMU phandle in Odroid HC1 Greg Kroah-Hartman
` (20 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Marek Szyprowski,
Krzysztof Kozlowski, Sasha Levin
From: Marek Szyprowski <m.szyprowski@samsung.com>
[ Upstream commit 1c651356f482ff08f6acef197a362f2e71d55a98 ]
Add trip points and cooling maps for GPU thermal zone for Odroid
XU3/XU4/HC1 boards. Trip points are based on the CPU thermal zone for the
those boards.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Stable-dep-of: 2e3d0e20d845 ("ARM: dts: exynos: correct TMU phandle in Odroid HC1")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos5422-odroidhc1.dts | 30 ++++++++++
.../boot/dts/exynos5422-odroidxu3-common.dtsi | 59 +++++++++++++++++++
2 files changed, 89 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidhc1.dts b/arch/arm/boot/dts/exynos5422-odroidhc1.dts
index fce5a4579693e..3235d7a27e042 100644
--- a/arch/arm/boot/dts/exynos5422-odroidhc1.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidhc1.dts
@@ -215,6 +215,36 @@
};
};
};
+ gpu_thermal: gpu-thermal {
+ thermal-sensors = <&tmu_gpu 0>;
+ trips {
+ gpu_alert0: gpu-alert-0 {
+ temperature = <70000>;
+ hysteresis = <10000>;
+ type = "active";
+ };
+ gpu_alert1: gpu-alert-1 {
+ temperature = <85000>;
+ hysteresis = <10000>;
+ type = "active";
+ };
+ gpu_crit0: gpu-crit-0 {
+ temperature = <120000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ cooling-maps {
+ map0 {
+ trip = <&gpu_alert0>;
+ cooling-device = <&gpu 0 2>;
+ };
+ map1 {
+ trip = <&gpu_alert1>;
+ cooling-device = <&gpu 3 6>;
+ };
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 264651141d688..402d69877fd97 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -359,6 +359,65 @@
};
};
};
+ gpu_thermal: gpu-thermal {
+ thermal-sensors = <&tmu_gpu 0>;
+ polling-delay-passive = <250>;
+ polling-delay = <0>;
+ trips {
+ gpu_alert0: gpu-alert-0 {
+ temperature = <50000>;
+ hysteresis = <5000>;
+ type = "active";
+ };
+ gpu_alert1: gpu-alert-1 {
+ temperature = <60000>;
+ hysteresis = <5000>;
+ type = "active";
+ };
+ gpu_alert2: gpu-alert-2 {
+ temperature = <70000>;
+ hysteresis = <5000>;
+ type = "active";
+ };
+ gpu_crit0: gpu-crit-0 {
+ temperature = <120000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ gpu_alert3: gpu-alert-3 {
+ temperature = <70000>;
+ hysteresis = <10000>;
+ type = "passive";
+ };
+ gpu_alert4: gpu-alert-4 {
+ temperature = <85000>;
+ hysteresis = <10000>;
+ type = "passive";
+ };
+ };
+ cooling-maps {
+ map0 {
+ trip = <&gpu_alert0>;
+ cooling-device = <&fan0 0 1>;
+ };
+ map1 {
+ trip = <&gpu_alert1>;
+ cooling-device = <&fan0 1 2>;
+ };
+ map2 {
+ trip = <&gpu_alert2>;
+ cooling-device = <&fan0 2 3>;
+ };
+ map3 {
+ trip = <&gpu_alert3>;
+ cooling-device = <&gpu 0 2>;
+ };
+ map4 {
+ trip = <&gpu_alert4>;
+ cooling-device = <&gpu 3 6>;
+ };
+ };
+ };
};
};
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 24/39] ARM: dts: exynos: correct TMU phandle in Odroid HC1
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 23/39] ARM: dts: exynos: Add GPU thermal zone cooling maps for Odroid XU3/XU4/HC1 Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 25/39] ARM: dts: exynos: correct TMU phandle in Odroid XU3 family Greg Kroah-Hartman
` (19 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Sasha Levin
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
[ Upstream commit 2e3d0e20d8456f876607a8af61fdb83dfbf98cb6 ]
TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
it must not have an argument to phandle. This was not critical before,
but since rework of thermal Devicetree initialization in the
commit 3fd6d6e2b4e8 ("thermal/of: Rework the thermal device tree
initialization"), this leads to errors registering thermal zones other
than first one:
thermal_sys: cpu0-thermal: Failed to read thermal-sensors cells: -2
thermal_sys: Failed to find thermal zone for tmu id=0
exynos-tmu 10064000.tmu: Failed to register sensor: -2
exynos-tmu: probe of 10064000.tmu failed with error -2
Fixes: 1ac49427b566 ("ARM: dts: exynos: Add support for Hardkernel's Odroid HC1 board")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230209105841.779596-5-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos5422-odroidhc1.dts | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidhc1.dts b/arch/arm/boot/dts/exynos5422-odroidhc1.dts
index 3235d7a27e042..b423cea4c0e99 100644
--- a/arch/arm/boot/dts/exynos5422-odroidhc1.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidhc1.dts
@@ -29,7 +29,7 @@
thermal-zones {
cpu0_thermal: cpu0-thermal {
- thermal-sensors = <&tmu_cpu0 0>;
+ thermal-sensors = <&tmu_cpu0>;
trips {
cpu0_alert0: cpu-alert-0 {
temperature = <70000>; /* millicelsius */
@@ -84,7 +84,7 @@
};
};
cpu1_thermal: cpu1-thermal {
- thermal-sensors = <&tmu_cpu1 0>;
+ thermal-sensors = <&tmu_cpu1>;
trips {
cpu1_alert0: cpu-alert-0 {
temperature = <70000>;
@@ -128,7 +128,7 @@
};
};
cpu2_thermal: cpu2-thermal {
- thermal-sensors = <&tmu_cpu2 0>;
+ thermal-sensors = <&tmu_cpu2>;
trips {
cpu2_alert0: cpu-alert-0 {
temperature = <70000>;
@@ -172,7 +172,7 @@
};
};
cpu3_thermal: cpu3-thermal {
- thermal-sensors = <&tmu_cpu3 0>;
+ thermal-sensors = <&tmu_cpu3>;
trips {
cpu3_alert0: cpu-alert-0 {
temperature = <70000>;
@@ -216,7 +216,7 @@
};
};
gpu_thermal: gpu-thermal {
- thermal-sensors = <&tmu_gpu 0>;
+ thermal-sensors = <&tmu_gpu>;
trips {
gpu_alert0: gpu-alert-0 {
temperature = <70000>;
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 25/39] ARM: dts: exynos: correct TMU phandle in Odroid XU3 family
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 24/39] ARM: dts: exynos: correct TMU phandle in Odroid HC1 Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 26/39] scsi: core: Remove the /proc/scsi/${proc_name} directory earlier Greg Kroah-Hartman
` (18 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Sasha Levin
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
[ Upstream commit a3583e92d188ec6c58c7f603ac5e72dd8a11c21a ]
TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
it must not have an argument to phandle. This was not critical before,
but since rework of thermal Devicetree initialization in the
commit 3fd6d6e2b4e8 ("thermal/of: Rework the thermal device tree
initialization"), this leads to errors registering thermal zones other
than first one:
thermal_sys: cpu0-thermal: Failed to read thermal-sensors cells: -2
thermal_sys: Failed to find thermal zone for tmu id=0
exynos-tmu 10064000.tmu: Failed to register sensor: -2
exynos-tmu: probe of 10064000.tmu failed with error -2
Fixes: f1722d7dd8b8 ("ARM: dts: Define default thermal-zones for exynos5422")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230209105841.779596-6-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 402d69877fd97..86f64db15a3dd 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -52,7 +52,7 @@
thermal-zones {
cpu0_thermal: cpu0-thermal {
- thermal-sensors = <&tmu_cpu0 0>;
+ thermal-sensors = <&tmu_cpu0>;
polling-delay-passive = <250>;
polling-delay = <0>;
trips {
@@ -141,7 +141,7 @@
};
};
cpu1_thermal: cpu1-thermal {
- thermal-sensors = <&tmu_cpu1 0>;
+ thermal-sensors = <&tmu_cpu1>;
polling-delay-passive = <250>;
polling-delay = <0>;
trips {
@@ -214,7 +214,7 @@
};
};
cpu2_thermal: cpu2-thermal {
- thermal-sensors = <&tmu_cpu2 0>;
+ thermal-sensors = <&tmu_cpu2>;
polling-delay-passive = <250>;
polling-delay = <0>;
trips {
@@ -287,7 +287,7 @@
};
};
cpu3_thermal: cpu3-thermal {
- thermal-sensors = <&tmu_cpu3 0>;
+ thermal-sensors = <&tmu_cpu3>;
polling-delay-passive = <250>;
polling-delay = <0>;
trips {
@@ -360,7 +360,7 @@
};
};
gpu_thermal: gpu-thermal {
- thermal-sensors = <&tmu_gpu 0>;
+ thermal-sensors = <&tmu_gpu>;
polling-delay-passive = <250>;
polling-delay = <0>;
trips {
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 26/39] scsi: core: Remove the /proc/scsi/${proc_name} directory earlier
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 25/39] ARM: dts: exynos: correct TMU phandle in Odroid XU3 family Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 27/39] Revert "spi: mt7621: Fix an error message in mt7621_spi_probe()" Greg Kroah-Hartman
` (17 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Alan Stern, Yi Zhang,
Bart Van Assche, Martin K. Petersen, Sasha Levin
From: Bart Van Assche <bvanassche@acm.org>
[ Upstream commit fc663711b94468f4e1427ebe289c9f05669699c9 ]
Remove the /proc/scsi/${proc_name} directory earlier to fix a race
condition between unloading and reloading kernel modules. This fixes a bug
introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in
the SCSI core").
Fix the following kernel warning:
proc_dir_entry 'scsi/scsi_debug' already registered
WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0
Call Trace:
proc_mkdir+0xb5/0xe0
scsi_proc_hostdir_add+0xb5/0x170
scsi_host_alloc+0x683/0x6c0
sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]
really_probe+0x159/0x540
__driver_probe_device+0xdc/0x230
driver_probe_device+0x4f/0x120
__device_attach_driver+0xef/0x180
bus_for_each_drv+0xe5/0x130
__device_attach+0x127/0x290
device_initial_probe+0x17/0x20
bus_probe_device+0x110/0x130
device_add+0x673/0xc80
device_register+0x1e/0x30
sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]
scsi_debug_init+0x64f/0x1000 [scsi_debug]
do_one_initcall+0xd7/0x470
do_init_module+0xe7/0x330
load_module+0x122a/0x12c0
__do_sys_finit_module+0x124/0x1a0
__x64_sys_finit_module+0x46/0x50
do_syscall_64+0x38/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Link: https://lore.kernel.org/r/20230210205200.36973-3-bvanassche@acm.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Yi Zhang <yi.zhang@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 77c019768f06 ("[SCSI] fix /proc memory leak in the SCSI core")
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/hosts.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index b3d6ea92b4f7c..2ffc2e15d822b 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -178,6 +178,7 @@ void scsi_remove_host(struct Scsi_Host *shost)
scsi_forget_host(shost);
mutex_unlock(&shost->scan_mutex);
scsi_proc_host_rm(shost);
+ scsi_proc_hostdir_rm(shost->hostt);
spin_lock_irqsave(shost->host_lock, flags);
if (scsi_host_set_state(shost, SHOST_DEL))
@@ -329,6 +330,7 @@ static void scsi_host_dev_release(struct device *dev)
struct Scsi_Host *shost = dev_to_shost(dev);
struct device *parent = dev->parent;
+ /* In case scsi_remove_host() has not been called. */
scsi_proc_hostdir_rm(shost->hostt);
/* Wait for functions invoked through call_rcu(&shost->rcu, ...) */
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 27/39] Revert "spi: mt7621: Fix an error message in mt7621_spi_probe()"
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 26/39] scsi: core: Remove the /proc/scsi/${proc_name} directory earlier Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 28/39] clk: qcom: mmcc-apq8084: remove spdm clocks Greg Kroah-Hartman
` (16 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Nobuhiro Iwamatsu (CIP)
From: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
This reverts commit 269f650a0b26067092873308117e0bf0c6ec8289 which is
commit 2b2bf6b7faa9010fae10dc7de76627a3fdb525b3 upstream.
dev_err_probe() does not suppot in 4.19.y. So this driver will fail to
build.
```
CC drivers/staging/mt7621-spi/spi-mt7621.o
drivers/staging/mt7621-spi/spi-mt7621.c: In function 'mt7621_spi_probe':
drivers/staging/mt7621-spi/spi-mt7621.c:446:24: error: implicit declaration of function 'dev_err_probe'; did you mean 'device_reprobe'? [-Werror=implicit-function-declaration]
446 | return dev_err_probe(&pdev->dev, PTR_ERR(clk),
| ^~~~~~~~~~~~~
| device_reprobe
```
Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/mt7621-spi/spi-mt7621.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/staging/mt7621-spi/spi-mt7621.c
+++ b/drivers/staging/mt7621-spi/spi-mt7621.c
@@ -442,9 +442,11 @@ static int mt7621_spi_probe(struct platf
return PTR_ERR(base);
clk = devm_clk_get(&pdev->dev, NULL);
- if (IS_ERR(clk))
- return dev_err_probe(&pdev->dev, PTR_ERR(clk),
- "unable to get SYS clock\n");
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "unable to get SYS clock, err=%d\n",
+ status);
+ return PTR_ERR(clk);
+ }
status = clk_prepare_enable(clk);
if (status)
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 28/39] clk: qcom: mmcc-apq8084: remove spdm clocks
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 27/39] Revert "spi: mt7621: Fix an error message in mt7621_spi_probe()" Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 29/39] MIPS: Fix a compilation issue Greg Kroah-Hartman
` (15 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Stephen Boyd, Georgi Djakov,
Konrad Dybcio, Dmitry Baryshkov, Bjorn Andersson, Sasha Levin
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
[ Upstream commit 7b347f4b677b6d84687e67d82b6b17c6f55ea2b4 ]
SPDM is used for debug/profiling and does not have any other
functionality. These clocks can safely be removed.
Suggested-by: Stephen Boyd <sboyd@kernel.org>
Suggested-by: Georgi Djakov <djakov@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230111060402.1168726-11-dmitry.baryshkov@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/clk/qcom/mmcc-apq8084.c | 271 --------------------------------
1 file changed, 271 deletions(-)
diff --git a/drivers/clk/qcom/mmcc-apq8084.c b/drivers/clk/qcom/mmcc-apq8084.c
index 4ce1d7c88377f..e0fd37cb3eb50 100644
--- a/drivers/clk/qcom/mmcc-apq8084.c
+++ b/drivers/clk/qcom/mmcc-apq8084.c
@@ -2371,262 +2371,6 @@ static struct clk_branch mmss_rbcpr_clk = {
},
};
-static struct clk_branch mmss_spdm_ahb_clk = {
- .halt_reg = 0x0230,
- .clkr = {
- .enable_reg = 0x0230,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_ahb_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_ahb_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_axi_clk = {
- .halt_reg = 0x0210,
- .clkr = {
- .enable_reg = 0x0210,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_axi_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_axi_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_csi0_clk = {
- .halt_reg = 0x023c,
- .clkr = {
- .enable_reg = 0x023c,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_csi0_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_csi0_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_gfx3d_clk = {
- .halt_reg = 0x022c,
- .clkr = {
- .enable_reg = 0x022c,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_gfx3d_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_gfx3d_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_jpeg0_clk = {
- .halt_reg = 0x0204,
- .clkr = {
- .enable_reg = 0x0204,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_jpeg0_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_jpeg0_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_jpeg1_clk = {
- .halt_reg = 0x0208,
- .clkr = {
- .enable_reg = 0x0208,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_jpeg1_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_jpeg1_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_jpeg2_clk = {
- .halt_reg = 0x0224,
- .clkr = {
- .enable_reg = 0x0224,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_jpeg2_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_jpeg2_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_mdp_clk = {
- .halt_reg = 0x020c,
- .clkr = {
- .enable_reg = 0x020c,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_mdp_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_mdp_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_pclk0_clk = {
- .halt_reg = 0x0234,
- .clkr = {
- .enable_reg = 0x0234,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_pclk0_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_pclk0_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_pclk1_clk = {
- .halt_reg = 0x0228,
- .clkr = {
- .enable_reg = 0x0228,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_pclk1_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_pclk1_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_vcodec0_clk = {
- .halt_reg = 0x0214,
- .clkr = {
- .enable_reg = 0x0214,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_vcodec0_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_vcodec0_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_vfe0_clk = {
- .halt_reg = 0x0218,
- .clkr = {
- .enable_reg = 0x0218,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_vfe0_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_vfe0_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_vfe1_clk = {
- .halt_reg = 0x021c,
- .clkr = {
- .enable_reg = 0x021c,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_vfe1_clk",
- .parent_names = (const char *[]){
- "mmss_spdm_vfe1_div_clk",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_rm_axi_clk = {
- .halt_reg = 0x0304,
- .clkr = {
- .enable_reg = 0x0304,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_rm_axi_clk",
- .parent_names = (const char *[]){
- "mmss_axi_clk_src",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-static struct clk_branch mmss_spdm_rm_ocmemnoc_clk = {
- .halt_reg = 0x0308,
- .clkr = {
- .enable_reg = 0x0308,
- .enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data){
- .name = "mmss_spdm_rm_ocmemnoc_clk",
- .parent_names = (const char *[]){
- "ocmemnoc_clk_src",
- },
- .num_parents = 1,
- .flags = CLK_SET_RATE_PARENT,
- .ops = &clk_branch2_ops,
- },
- },
-};
-
-
static struct clk_branch mmss_misc_ahb_clk = {
.halt_reg = 0x502c,
.clkr = {
@@ -3259,21 +3003,6 @@ static struct clk_regmap *mmcc_apq8084_clocks[] = {
[MDSS_VSYNC_CLK] = &mdss_vsync_clk.clkr,
[MMSS_RBCPR_AHB_CLK] = &mmss_rbcpr_ahb_clk.clkr,
[MMSS_RBCPR_CLK] = &mmss_rbcpr_clk.clkr,
- [MMSS_SPDM_AHB_CLK] = &mmss_spdm_ahb_clk.clkr,
- [MMSS_SPDM_AXI_CLK] = &mmss_spdm_axi_clk.clkr,
- [MMSS_SPDM_CSI0_CLK] = &mmss_spdm_csi0_clk.clkr,
- [MMSS_SPDM_GFX3D_CLK] = &mmss_spdm_gfx3d_clk.clkr,
- [MMSS_SPDM_JPEG0_CLK] = &mmss_spdm_jpeg0_clk.clkr,
- [MMSS_SPDM_JPEG1_CLK] = &mmss_spdm_jpeg1_clk.clkr,
- [MMSS_SPDM_JPEG2_CLK] = &mmss_spdm_jpeg2_clk.clkr,
- [MMSS_SPDM_MDP_CLK] = &mmss_spdm_mdp_clk.clkr,
- [MMSS_SPDM_PCLK0_CLK] = &mmss_spdm_pclk0_clk.clkr,
- [MMSS_SPDM_PCLK1_CLK] = &mmss_spdm_pclk1_clk.clkr,
- [MMSS_SPDM_VCODEC0_CLK] = &mmss_spdm_vcodec0_clk.clkr,
- [MMSS_SPDM_VFE0_CLK] = &mmss_spdm_vfe0_clk.clkr,
- [MMSS_SPDM_VFE1_CLK] = &mmss_spdm_vfe1_clk.clkr,
- [MMSS_SPDM_RM_AXI_CLK] = &mmss_spdm_rm_axi_clk.clkr,
- [MMSS_SPDM_RM_OCMEMNOC_CLK] = &mmss_spdm_rm_ocmemnoc_clk.clkr,
[MMSS_MISC_AHB_CLK] = &mmss_misc_ahb_clk.clkr,
[MMSS_MMSSNOC_AHB_CLK] = &mmss_mmssnoc_ahb_clk.clkr,
[MMSS_MMSSNOC_BTO_AHB_CLK] = &mmss_mmssnoc_bto_ahb_clk.clkr,
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 29/39] MIPS: Fix a compilation issue
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 28/39] clk: qcom: mmcc-apq8084: remove spdm clocks Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 30/39] alpha: fix R_ALPHA_LITERAL reloc for large modules Greg Kroah-Hartman
` (14 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, xurui, Thomas Bogendoerfer, Sasha Levin
From: xurui <xurui@kylinos.cn>
[ Upstream commit 109d587a4b4d7ccca2200ab1f808f43ae23e2585 ]
arch/mips/include/asm/mach-rc32434/pci.h:377:
cc1: error: result of ‘-117440512 << 16’ requires 44 bits to represent, but ‘int’ only has 32 bits [-Werror=shift-overflow=]
All bits in KORINA_STAT are already at the correct position, so there is
no addtional shift needed.
Signed-off-by: xurui <xurui@kylinos.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/mips/include/asm/mach-rc32434/pci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/mach-rc32434/pci.h b/arch/mips/include/asm/mach-rc32434/pci.h
index 6f40d1515580b..1ff8a987025c8 100644
--- a/arch/mips/include/asm/mach-rc32434/pci.h
+++ b/arch/mips/include/asm/mach-rc32434/pci.h
@@ -377,7 +377,7 @@ struct pci_msu {
PCI_CFG04_STAT_SSE | \
PCI_CFG04_STAT_PE)
-#define KORINA_CNFG1 ((KORINA_STAT<<16)|KORINA_CMD)
+#define KORINA_CNFG1 (KORINA_STAT | KORINA_CMD)
#define KORINA_REVID 0
#define KORINA_CLASS_CODE 0
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 30/39] alpha: fix R_ALPHA_LITERAL reloc for large modules
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 29/39] MIPS: Fix a compilation issue Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 31/39] macintosh: windfarm: Use unsigned type for 1-bit bitfields Greg Kroah-Hartman
` (13 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Edward Humes, Matt Turner, Sasha Levin
From: Edward Humes <aurxenon@lunos.org>
[ Upstream commit b6b17a8b3ecd878d98d5472a9023ede9e669ca72 ]
Previously, R_ALPHA_LITERAL relocations would overflow for large kernel
modules.
This was because the Alpha's apply_relocate_add was relying on the kernel's
module loader to have sorted the GOT towards the very end of the module as it
was mapped into memory in order to correctly assign the global pointer. While
this behavior would mostly work fine for small kernel modules, this approach
would overflow on kernel modules with large GOT's since the global pointer
would be very far away from the GOT, and thus, certain entries would be out of
range.
This patch fixes this by instead using the Tru64 behavior of assigning the
global pointer to be 32KB away from the start of the GOT. The change made
in this patch won't work for multi-GOT kernel modules as it makes the
assumption the module only has one GOT located at the beginning of .got,
although for the vast majority kernel modules, this should be fine. Of the
kernel modules that would previously result in a relocation error, none of
them, even modules like nouveau, have even come close to filling up a single
GOT, and they've all worked fine under this patch.
Signed-off-by: Edward Humes <aurxenon@lunos.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/alpha/kernel/module.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/alpha/kernel/module.c b/arch/alpha/kernel/module.c
index 47632fa8c24e0..b169dc9a9ac17 100644
--- a/arch/alpha/kernel/module.c
+++ b/arch/alpha/kernel/module.c
@@ -158,10 +158,8 @@ apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
base = (void *)sechdrs[sechdrs[relsec].sh_info].sh_addr;
symtab = (Elf64_Sym *)sechdrs[symindex].sh_addr;
- /* The small sections were sorted to the end of the segment.
- The following should definitely cover them. */
- gp = (u64)me->core_layout.base + me->core_layout.size - 0x8000;
got = sechdrs[me->arch.gotsecindex].sh_addr;
+ gp = got + 0x8000;
for (i = 0; i < n; i++) {
unsigned long r_sym = ELF64_R_SYM (rela[i].r_info);
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 31/39] macintosh: windfarm: Use unsigned type for 1-bit bitfields
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 30/39] alpha: fix R_ALPHA_LITERAL reloc for large modules Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 32/39] PCI: Add SolidRun vendor ID Greg Kroah-Hartman
` (12 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Nathan Chancellor, Michael Ellerman,
Sasha Levin
From: Nathan Chancellor <nathan@kernel.org>
[ Upstream commit 748ea32d2dbd813d3bd958117bde5191182f909a ]
Clang warns:
drivers/macintosh/windfarm_lm75_sensor.c:63:14: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
lm->inited = 1;
^ ~
drivers/macintosh/windfarm_smu_sensors.c:356:19: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
pow->fake_volts = 1;
^ ~
drivers/macintosh/windfarm_smu_sensors.c:368:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
pow->quadratic = 1;
^ ~
There is no bug here since no code checks the actual value of these
fields, just whether or not they are zero (boolean context), but this
can be easily fixed by switching to an unsigned type.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230215-windfarm-wsingle-bit-bitfield-constant-conversion-v1-1-26415072e855@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/macintosh/windfarm_lm75_sensor.c | 4 ++--
drivers/macintosh/windfarm_smu_sensors.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c b/drivers/macintosh/windfarm_lm75_sensor.c
index f48ad2445ed60..f5b1ac8347db7 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -35,8 +35,8 @@
#endif
struct wf_lm75_sensor {
- int ds1775 : 1;
- int inited : 1;
+ unsigned int ds1775 : 1;
+ unsigned int inited : 1;
struct i2c_client *i2c;
struct wf_sensor sens;
};
diff --git a/drivers/macintosh/windfarm_smu_sensors.c b/drivers/macintosh/windfarm_smu_sensors.c
index 172fd267dcf60..0f4017a8189e5 100644
--- a/drivers/macintosh/windfarm_smu_sensors.c
+++ b/drivers/macintosh/windfarm_smu_sensors.c
@@ -275,8 +275,8 @@ struct smu_cpu_power_sensor {
struct list_head link;
struct wf_sensor *volts;
struct wf_sensor *amps;
- int fake_volts : 1;
- int quadratic : 1;
+ unsigned int fake_volts : 1;
+ unsigned int quadratic : 1;
struct wf_sensor sens;
};
#define to_smu_cpu_power(c) container_of(c, struct smu_cpu_power_sensor, sens)
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 32/39] PCI: Add SolidRun vendor ID
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 31/39] macintosh: windfarm: Use unsigned type for 1-bit bitfields Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 33/39] PCI: Avoid FLR for SolidRun SNET DPU rev 1 Greg Kroah-Hartman
` (11 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Alvaro Karsz, Bjorn Helgaas,
Michael S. Tsirkin, Sasha Levin
From: Alvaro Karsz <alvaro.karsz@solid-run.com>
[ Upstream commit db6c4dee4c104f50ed163af71c53bfdb878a8318 ]
Add SolidRun vendor ID to pci_ids.h
The vendor ID is used in 2 different source files, the SNET vDPA driver
and PCI quirks.
Signed-off-by: Alvaro Karsz <alvaro.karsz@solid-run.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Message-Id: <20230110165638.123745-2-alvaro.karsz@solid-run.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/pci_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 1658e9f8d8032..78c1cd4dfdc07 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -3097,6 +3097,8 @@
#define PCI_VENDOR_ID_3COM_2 0xa727
+#define PCI_VENDOR_ID_SOLIDRUN 0xd063
+
#define PCI_VENDOR_ID_DIGIUM 0xd161
#define PCI_DEVICE_ID_DIGIUM_HFC4S 0xb410
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 33/39] PCI: Avoid FLR for SolidRun SNET DPU rev 1
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (31 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 32/39] PCI: Add SolidRun vendor ID Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 34/39] media: ov5640: Fix analogue gain control Greg Kroah-Hartman
` (10 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Alvaro Karsz, Bjorn Helgaas,
Michael S. Tsirkin, Sasha Levin
From: Alvaro Karsz <alvaro.karsz@solid-run.com>
[ Upstream commit d089d69cc1f824936eeaa4fa172f8fa1a0949eaa ]
This patch fixes a FLR bug on the SNET DPU rev 1 by setting the
PCI_DEV_FLAGS_NO_FLR_RESET flag.
As there is a quirk to avoid FLR (quirk_no_flr), I added a new quirk
to check the rev ID before calling to quirk_no_flr.
Without this patch, a SNET DPU rev 1 may hang when FLR is applied.
Signed-off-by: Alvaro Karsz <alvaro.karsz@solid-run.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Message-Id: <20230110165638.123745-3-alvaro.karsz@solid-run.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pci/quirks.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index afa6acb58eec8..db2faa483d253 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5157,6 +5157,14 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x7901, quirk_no_flr);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_no_flr);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_no_flr);
+/* FLR may cause the SolidRun SNET DPU (rev 0x1) to hang */
+static void quirk_no_flr_snet(struct pci_dev *dev)
+{
+ if (dev->revision == 0x1)
+ quirk_no_flr(dev);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SOLIDRUN, 0x1000, quirk_no_flr_snet);
+
static void quirk_no_ext_tags(struct pci_dev *pdev)
{
struct pci_host_bridge *bridge = pci_find_host_bridge(pdev->bus);
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 34/39] media: ov5640: Fix analogue gain control
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (32 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 33/39] PCI: Avoid FLR for SolidRun SNET DPU rev 1 Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 35/39] tipc: improve function tipc_wait_for_cond() Greg Kroah-Hartman
` (9 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Paul Elder, Laurent Pinchart,
Jacopo Mondi, Jai Luthra, Sakari Ailus, Mauro Carvalho Chehab,
Sasha Levin
From: Paul Elder <paul.elder@ideasonboard.com>
[ Upstream commit afa4805799c1d332980ad23339fdb07b5e0cf7e0 ]
Gain control is badly documented in publicly available (including
leaked) documentation.
There is an AGC pre-gain in register 0x3a13, expressed as a 6-bit value
(plus an enable bit in bit 6). The driver hardcodes it to 0x43, which
one application note states is equal to x1.047. The documentation also
states that 0x40 is equel to x1.000. The pre-gain thus seems to be
expressed as in 1/64 increments, and thus ranges from x1.00 to x1.984.
What the pre-gain does is however unspecified.
There is then an AGC gain limit, in registers 0x3a18 and 0x3a19,
expressed as a 10-bit "real gain format" value. One application note
sets it to 0x00f8 and states it is equal to x15.5, so it appears to be
expressed in 1/16 increments, up to x63.9375.
The manual gain is stored in registers 0x350a and 0x350b, also as a
10-bit "real gain format" value. It is documented in the application
note as a Q6.4 values, up to x63.9375.
One version of the datasheet indicates that the sensor supports a
digital gain:
The OV5640 supports 1/2/4 digital gain. Normally, the gain is
controlled automatically by the automatic gain control (AGC) block.
It isn't clear how that would be controlled manually.
There appears to be no indication regarding whether the gain controlled
through registers 0x350a and 0x350b is an analogue gain only or also
includes digital gain. The words "real gain" don't necessarily mean
"combined analogue and digital gains". Some OmniVision sensors (such as
the OV8858) are documented as supoprting different formats for the gain
values, selectable through a register bit, and they are called "real
gain format" and "sensor gain format". For that sensor, we have (one of)
the gain registers documented as
0x3503[2]=0, gain[7:0] is real gain format, where low 4 bits are
fraction bits, for example, 0x10 is 1x gain, 0x28 is 2.5x gain
If 0x3503[2]=1, gain[7:0] is sensor gain format, gain[7:4] is coarse
gain, 00000: 1x, 00001: 2x, 00011: 4x, 00111: 8x, gain[7] is 1,
gain[3:0] is fine gain. For example, 0x10 is 1x gain, 0x30 is 2x gain,
0x70 is 4x gain
(The second part of the text makes little sense)
"Real gain" may thus refer to the combination of the coarse and fine
analogue gains as a single value.
The OV5640 0x350a and 0x350b registers thus appear to control analogue
gain. The driver incorrectly uses V4L2_CID_GAIN as V4L2 has a specific
control for analogue gain, V4L2_CID_ANALOGUE_GAIN. Use it.
If registers 0x350a and 0x350b are later found to control digital gain
as well, the driver could then restrict the range of the analogue gain
control value to lower than x64 and add a separate digital gain control.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Jai Luthra <j-luthra@ti.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/i2c/ov5640.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index aa9c0b7ee7a22..31b26b18e5251 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2447,7 +2447,7 @@ static int ov5640_init_controls(struct ov5640_dev *sensor)
/* Auto/manual gain */
ctrls->auto_gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_AUTOGAIN,
0, 1, 1, 1);
- ctrls->gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAIN,
+ ctrls->gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_ANALOGUE_GAIN,
0, 1023, 1, 0);
ctrls->saturation = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_SATURATION,
--
2.39.2
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 4.19 35/39] tipc: improve function tipc_wait_for_cond()
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (33 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 34/39] media: ov5640: Fix analogue gain control Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [Intel-gfx] " Greg Kroah-Hartman
` (8 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ying Xue, Jon Maloy, Tung Nguyen,
David S. Miller, Lee Jones
From: Tung Nguyen <tung.q.nguyen@dektech.com.au>
commit 223b7329ec6a0dae1b7f7db7b770e93f4a069ef9 upstream.
Commit 844cf763fba6 ("tipc: make macro tipc_wait_for_cond() smp safe")
replaced finish_wait() with remove_wait_queue() but still used
prepare_to_wait(). This causes unnecessary conditional
checking before adding to wait queue in prepare_to_wait().
This commit replaces prepare_to_wait() with add_wait_queue()
as the pair function with remove_wait_queue().
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Lee Jones <lee@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/tipc/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -388,7 +388,7 @@ static int tipc_sk_sock_err(struct socke
rc_ = tipc_sk_sock_err((sock_), timeo_); \
if (rc_) \
break; \
- prepare_to_wait(sk_sleep(sk_), &wait_, TASK_INTERRUPTIBLE); \
+ add_wait_queue(sk_sleep(sk_), &wait_); \
release_sock(sk_); \
*(timeo_) = wait_woken(&wait_, TASK_INTERRUPTIBLE, *(timeo_)); \
sched_annotate_sleep(); \
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 36/39] drm/i915: Dont use BAR mappings for ring buffers with LLC
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 02/39] x86/CPU/AMD: Disable XSAVES on AMD family 0x17 Greg Kroah-Hartman
` (42 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, John Harrison, Chris Wilson,
Joonas Lahtinen, Jani Nikula, Rodrigo Vivi, Tvrtko Ursulin,
intel-gfx, Jouni Högander, Daniele Ceraolo Spurio,
Jani Nikula
From: John Harrison <John.C.Harrison@Intel.com>
commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.9+
Tested-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1083,7 +1083,7 @@ int intel_ring_pin(struct intel_ring *ri
if (unlikely(ret))
return ret;
- if (i915_vma_is_map_and_fenceable(vma))
+ if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
addr = (void __force *)i915_vma_pin_iomap(vma);
else
addr = i915_gem_object_pin_map(vma->obj, map);
@@ -1118,7 +1118,7 @@ void intel_ring_unpin(struct intel_ring
/* Discard any unused bytes beyond that submitted to hw. */
intel_ring_reset(ring, ring->tail);
- if (i915_vma_is_map_and_fenceable(ring->vma))
+ if (i915_vma_is_map_and_fenceable(ring->vma) && !HAS_LLC(ring->vma->vm->i915))
i915_vma_unpin_iomap(ring->vma);
else
i915_gem_object_unpin_map(ring->vma->obj);
^ permalink raw reply [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH 4.19 36/39] drm/i915: Dont use BAR mappings for ring buffers with LLC
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
0 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Jani Nikula, Greg Kroah-Hartman, intel-gfx, patches,
Chris Wilson, Rodrigo Vivi
From: John Harrison <John.C.Harrison@Intel.com>
commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.9+
Tested-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-John.C.Harrison@Intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1083,7 +1083,7 @@ int intel_ring_pin(struct intel_ring *ri
if (unlikely(ret))
return ret;
- if (i915_vma_is_map_and_fenceable(vma))
+ if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
addr = (void __force *)i915_vma_pin_iomap(vma);
else
addr = i915_gem_object_pin_map(vma->obj, map);
@@ -1118,7 +1118,7 @@ void intel_ring_unpin(struct intel_ring
/* Discard any unused bytes beyond that submitted to hw. */
intel_ring_reset(ring, ring->tail);
- if (i915_vma_is_map_and_fenceable(ring->vma))
+ if (i915_vma_is_map_and_fenceable(ring->vma) && !HAS_LLC(ring->vma->vm->i915))
i915_vma_unpin_iomap(ring->vma);
else
i915_gem_object_unpin_map(ring->vma->obj);
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH 4.19 37/39] cgroup/cpuset: Change cpuset_rwsem and hotplug lock order
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (35 preceding siblings ...)
2023-03-15 12:12 ` [Intel-gfx] " Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 38/39] cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock Greg Kroah-Hartman
` (6 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dietmar Eggemann, Juri Lelli,
Peter Zijlstra (Intel),
Linus Torvalds, Thomas Gleixner, bristot, claudio, lizefan,
longman, luca.abeni, mathieu.poirier, rostedt, tj,
tommaso.cucinotta, Ingo Molnar, Cai Xinchen
From: Juri Lelli <juri.lelli@redhat.com>
commit d74b27d63a8bebe2fe634944e4ebdc7b10db7a39 upstream.
cpuset_rwsem is going to be acquired from sched_setscheduler() with a
following patch. There are however paths (e.g., spawn_ksoftirqd) in
which sched_scheduler() is eventually called while holding hotplug lock;
this creates a dependecy between hotplug lock (to be always acquired
first) and cpuset_rwsem (to be always acquired after hotplug lock).
Fix paths which currently take the two locks in the wrong order (after
a following patch is applied).
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bristot@redhat.com
Cc: claudio@evidence.eu.com
Cc: lizefan@huawei.com
Cc: longman@redhat.com
Cc: luca.abeni@santannapisa.it
Cc: mathieu.poirier@linaro.org
Cc: rostedt@goodmis.org
Cc: tj@kernel.org
Cc: tommaso.cucinotta@santannapisa.it
Link: https://lkml.kernel.org/r/20190719140000.31694-7-juri.lelli@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/cpuset.h | 8 ++++----
kernel/cgroup/cpuset.c | 18 ++++++++++++++----
2 files changed, 18 insertions(+), 8 deletions(-)
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -40,14 +40,14 @@ static inline bool cpusets_enabled(void)
static inline void cpuset_inc(void)
{
- static_branch_inc(&cpusets_pre_enable_key);
- static_branch_inc(&cpusets_enabled_key);
+ static_branch_inc_cpuslocked(&cpusets_pre_enable_key);
+ static_branch_inc_cpuslocked(&cpusets_enabled_key);
}
static inline void cpuset_dec(void)
{
- static_branch_dec(&cpusets_enabled_key);
- static_branch_dec(&cpusets_pre_enable_key);
+ static_branch_dec_cpuslocked(&cpusets_enabled_key);
+ static_branch_dec_cpuslocked(&cpusets_pre_enable_key);
}
extern int cpuset_init(void);
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -830,8 +830,8 @@ static void rebuild_sched_domains_locked
cpumask_var_t *doms;
int ndoms;
+ lockdep_assert_cpus_held();
lockdep_assert_held(&cpuset_mutex);
- get_online_cpus();
/*
* We have raced with CPU hotplug. Don't do anything to avoid
@@ -839,15 +839,13 @@ static void rebuild_sched_domains_locked
* Anyways, hotplug work item will rebuild sched domains.
*/
if (!cpumask_equal(top_cpuset.effective_cpus, cpu_active_mask))
- goto out;
+ return;
/* Generate domain masks and attrs */
ndoms = generate_sched_domains(&doms, &attr);
/* Have scheduler rebuild the domains */
partition_sched_domains(ndoms, doms, attr);
-out:
- put_online_cpus();
}
#else /* !CONFIG_SMP */
static void rebuild_sched_domains_locked(void)
@@ -857,9 +855,11 @@ static void rebuild_sched_domains_locked
void rebuild_sched_domains(void)
{
+ get_online_cpus();
mutex_lock(&cpuset_mutex);
rebuild_sched_domains_locked();
mutex_unlock(&cpuset_mutex);
+ put_online_cpus();
}
/**
@@ -1617,6 +1617,7 @@ static int cpuset_write_u64(struct cgrou
cpuset_filetype_t type = cft->private;
int retval = 0;
+ get_online_cpus();
mutex_lock(&cpuset_mutex);
if (!is_cpuset_online(cs)) {
retval = -ENODEV;
@@ -1654,6 +1655,7 @@ static int cpuset_write_u64(struct cgrou
}
out_unlock:
mutex_unlock(&cpuset_mutex);
+ put_online_cpus();
return retval;
}
@@ -1664,6 +1666,7 @@ static int cpuset_write_s64(struct cgrou
cpuset_filetype_t type = cft->private;
int retval = -ENODEV;
+ get_online_cpus();
mutex_lock(&cpuset_mutex);
if (!is_cpuset_online(cs))
goto out_unlock;
@@ -1678,6 +1681,7 @@ static int cpuset_write_s64(struct cgrou
}
out_unlock:
mutex_unlock(&cpuset_mutex);
+ put_online_cpus();
return retval;
}
@@ -1716,6 +1720,7 @@ static ssize_t cpuset_write_resmask(stru
kernfs_break_active_protection(of->kn);
flush_work(&cpuset_hotplug_work);
+ get_online_cpus();
mutex_lock(&cpuset_mutex);
if (!is_cpuset_online(cs))
goto out_unlock;
@@ -1741,6 +1746,7 @@ static ssize_t cpuset_write_resmask(stru
free_trial_cpuset(trialcs);
out_unlock:
mutex_unlock(&cpuset_mutex);
+ put_online_cpus();
kernfs_unbreak_active_protection(of->kn);
css_put(&cs->css);
flush_workqueue(cpuset_migrate_mm_wq);
@@ -1985,6 +1991,7 @@ static int cpuset_css_online(struct cgro
if (!parent)
return 0;
+ get_online_cpus();
mutex_lock(&cpuset_mutex);
set_bit(CS_ONLINE, &cs->flags);
@@ -2035,6 +2042,7 @@ static int cpuset_css_online(struct cgro
spin_unlock_irq(&callback_lock);
out_unlock:
mutex_unlock(&cpuset_mutex);
+ put_online_cpus();
return 0;
}
@@ -2048,6 +2056,7 @@ static void cpuset_css_offline(struct cg
{
struct cpuset *cs = css_cs(css);
+ get_online_cpus();
mutex_lock(&cpuset_mutex);
if (is_sched_load_balance(cs))
@@ -2057,6 +2066,7 @@ static void cpuset_css_offline(struct cg
clear_bit(CS_ONLINE, &cs->flags);
mutex_unlock(&cpuset_mutex);
+ put_online_cpus();
}
static void cpuset_css_free(struct cgroup_subsys_state *css)
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 38/39] cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (36 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 37/39] cgroup/cpuset: Change cpuset_rwsem and hotplug lock order Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.19 39/39] cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all() Greg Kroah-Hartman
` (5 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Tejun Heo, Cai Xinchen, Imran Khan,
Xuewen Yan
From: Tejun Heo <tj@kernel.org>
commit 4f7e7236435ca0abe005c674ebd6892c6e83aeb3 upstream.
Bringing up a CPU may involve creating and destroying tasks which requires
read-locking threadgroup_rwsem, so threadgroup_rwsem nests inside
cpus_read_lock(). However, cpuset's ->attach(), which may be called with
thredagroup_rwsem write-locked, also wants to disable CPU hotplug and
acquires cpus_read_lock(), leading to a deadlock.
Fix it by guaranteeing that ->attach() is always called with CPU hotplug
disabled and removing cpus_read_lock() call from cpuset_attach().
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-and-tested-by: Imran Khan <imran.f.khan@oracle.com>
Reported-and-tested-by: Xuewen Yan <xuewen.yan@unisoc.com>
Fixes: 05c7b7a92cc8 ("cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug")
Cc: stable@vger.kernel.org # v5.17+
Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup/cgroup.c | 49 ++++++++++++++++++++++++++++++++++++++++++++-----
kernel/cgroup/cpuset.c | 7 +------
2 files changed, 45 insertions(+), 11 deletions(-)
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -2210,6 +2210,45 @@ int task_cgroup_path(struct task_struct
EXPORT_SYMBOL_GPL(task_cgroup_path);
/**
+ * cgroup_attach_lock - Lock for ->attach()
+ * @lock_threadgroup: whether to down_write cgroup_threadgroup_rwsem
+ *
+ * cgroup migration sometimes needs to stabilize threadgroups against forks and
+ * exits by write-locking cgroup_threadgroup_rwsem. However, some ->attach()
+ * implementations (e.g. cpuset), also need to disable CPU hotplug.
+ * Unfortunately, letting ->attach() operations acquire cpus_read_lock() can
+ * lead to deadlocks.
+ *
+ * Bringing up a CPU may involve creating and destroying tasks which requires
+ * read-locking threadgroup_rwsem, so threadgroup_rwsem nests inside
+ * cpus_read_lock(). If we call an ->attach() which acquires the cpus lock while
+ * write-locking threadgroup_rwsem, the locking order is reversed and we end up
+ * waiting for an on-going CPU hotplug operation which in turn is waiting for
+ * the threadgroup_rwsem to be released to create new tasks. For more details:
+ *
+ * http://lkml.kernel.org/r/20220711174629.uehfmqegcwn2lqzu@wubuntu
+ *
+ * Resolve the situation by always acquiring cpus_read_lock() before optionally
+ * write-locking cgroup_threadgroup_rwsem. This allows ->attach() to assume that
+ * CPU hotplug is disabled on entry.
+ */
+static void cgroup_attach_lock(void)
+{
+ get_online_cpus();
+ percpu_down_write(&cgroup_threadgroup_rwsem);
+}
+
+/**
+ * cgroup_attach_unlock - Undo cgroup_attach_lock()
+ * @lock_threadgroup: whether to up_write cgroup_threadgroup_rwsem
+ */
+static void cgroup_attach_unlock(void)
+{
+ percpu_up_write(&cgroup_threadgroup_rwsem);
+ put_online_cpus();
+}
+
+/**
* cgroup_migrate_add_task - add a migration target task to a migration context
* @task: target task
* @mgctx: target migration context
@@ -2694,7 +2733,7 @@ struct task_struct *cgroup_procs_write_s
if (kstrtoint(strstrip(buf), 0, &pid) || pid < 0)
return ERR_PTR(-EINVAL);
- percpu_down_write(&cgroup_threadgroup_rwsem);
+ cgroup_attach_lock();
rcu_read_lock();
if (pid) {
@@ -2725,7 +2764,7 @@ struct task_struct *cgroup_procs_write_s
goto out_unlock_rcu;
out_unlock_threadgroup:
- percpu_up_write(&cgroup_threadgroup_rwsem);
+ cgroup_attach_unlock();
out_unlock_rcu:
rcu_read_unlock();
return tsk;
@@ -2740,7 +2779,7 @@ void cgroup_procs_write_finish(struct ta
/* release reference from cgroup_procs_write_start() */
put_task_struct(task);
- percpu_up_write(&cgroup_threadgroup_rwsem);
+ cgroup_attach_unlock();
for_each_subsys(ss, ssid)
if (ss->post_attach)
ss->post_attach();
@@ -2799,7 +2838,7 @@ static int cgroup_update_dfl_csses(struc
lockdep_assert_held(&cgroup_mutex);
- percpu_down_write(&cgroup_threadgroup_rwsem);
+ cgroup_attach_lock();
/* look up all csses currently attached to @cgrp's subtree */
spin_lock_irq(&css_set_lock);
@@ -2830,7 +2869,7 @@ static int cgroup_update_dfl_csses(struc
ret = cgroup_migrate_execute(&mgctx);
out_finish:
cgroup_migrate_finish(&mgctx);
- percpu_up_write(&cgroup_threadgroup_rwsem);
+ cgroup_attach_unlock();
return ret;
}
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -1528,13 +1528,9 @@ static void cpuset_attach(struct cgroup_
cgroup_taskset_first(tset, &css);
cs = css_cs(css);
+ lockdep_assert_cpus_held(); /* see cgroup_attach_lock() */
mutex_lock(&cpuset_mutex);
- /*
- * It should hold cpus lock because a cpu offline event can
- * cause set_cpus_allowed_ptr() failed.
- */
- get_online_cpus();
/* prepare for attach */
if (cs == &top_cpuset)
cpumask_copy(cpus_attach, cpu_possible_mask);
@@ -1553,7 +1549,6 @@ static void cpuset_attach(struct cgroup_
cpuset_change_task_nodemask(task, &cpuset_attach_nodemask_to);
cpuset_update_task_spread_flag(cs, task);
}
- put_online_cpus();
/*
* Change mm for all threadgroup leaders. This is expensive and may
^ permalink raw reply [flat|nested] 54+ messages in thread* [PATCH 4.19 39/39] cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (37 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 38/39] cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock Greg Kroah-Hartman
@ 2023-03-15 12:12 ` Greg Kroah-Hartman
2023-03-15 14:12 ` [PATCH 4.19 00/39] 4.19.278-rc1 review Chris Paterson
` (4 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 12:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, syzbot, Tetsuo Handa, Tejun Heo,
Cai Xinchen
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
commit 43626dade36fa74d3329046f4ae2d7fdefe401c6 upstream.
syzbot is hitting percpu_rwsem_assert_held(&cpu_hotplug_lock) warning at
cpuset_attach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix
threadgroup_rwsem <-> cpus_read_lock() deadlock") missed that
cpuset_attach() is also called from cgroup_attach_task_all().
Add cpus_read_lock() like what cgroup_procs_write_start() does.
Link: https://syzkaller.appspot.com/bug?extid=29d3a3b4d86c8136ad9e [1]
Reported-by: syzbot <syzbot+29d3a3b4d86c8136ad9e@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: 4f7e7236435ca0ab ("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock")
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup/cgroup-v1.c | 3 +++
1 file changed, 3 insertions(+)
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -13,6 +13,7 @@
#include <linux/delayacct.h>
#include <linux/pid_namespace.h>
#include <linux/cgroupstats.h>
+#include <linux/cpu.h>
#include <trace/events/cgroup.h>
@@ -55,6 +56,7 @@ int cgroup_attach_task_all(struct task_s
int retval = 0;
mutex_lock(&cgroup_mutex);
+ get_online_cpus();
percpu_down_write(&cgroup_threadgroup_rwsem);
for_each_root(root) {
struct cgroup *from_cgrp;
@@ -71,6 +73,7 @@ int cgroup_attach_task_all(struct task_s
break;
}
percpu_up_write(&cgroup_threadgroup_rwsem);
+ put_online_cpus();
mutex_unlock(&cgroup_mutex);
return retval;
^ permalink raw reply [flat|nested] 54+ messages in thread* RE: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (38 preceding siblings ...)
2023-03-15 12:12 ` [PATCH 4.19 39/39] cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all() Greg Kroah-Hartman
@ 2023-03-15 14:12 ` Chris Paterson
2023-03-15 14:24 ` Chris Paterson
2023-03-16 7:48 ` Greg Kroah-Hartman
2023-03-15 14:32 ` Guenter Roeck
` (3 subsequent siblings)
43 siblings, 2 replies; 54+ messages in thread
From: Chris Paterson @ 2023-03-15 14:12 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
Hello Greg,
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Sent: 15 March 2023 12:12
>
> This is the start of the stable review cycle for the 4.19.278 release.
> There are 39 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, 17 Mar 2023 11:57:10 +0000.
> Anything received after that time might be too late.
Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
CI Pipeline: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/807195668
We (CIP) are seeing some build issues with Linux 4.19.278-rc1 (7cfb8ee7c98e).
1)
In various arm, arm64 and x86 configurations we see:
kernel/cgroup/cgroup.c: In function 'cgroup_attach_lock':
kernel/cgroup/cgroup.c:2237:2: error: implicit declaration of function 'get_online_cpus'; did you mean 'get_online_mems'? [-Werror=implicit-function-declaration]
get_online_cpus();
^~~~~~~~~~~~~~~
get_online_mems
kernel/cgroup/cgroup.c: In function 'cgroup_attach_unlock':
kernel/cgroup/cgroup.c:2248:2: error: implicit declaration of function 'put_online_cpus'; did you mean 'num_online_cpus'? [-Werror=implicit-function-declaration]
put_online_cpus();
^~~~~~~~~~~~~~~
num_online_cpus
For example: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/3938632173#L1274
Presumably this issue is caused by "cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock", but I haven't had a chance to revert and re-test.
2)
For arm_multiconfig_v7 builds we're seeing a some errors when building the exynos5422 device trees:
arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map0: Reference to non-existent node or label "gpu"
arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map1: Reference to non-existent node or label "gpu"
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidhc1.dtb] Error 2
make[1]: *** Waiting for unfinished jobs....
DTC arch/arm/boot/dts/hi3519-demb.dtb
DTC arch/arm/boot/dts/hisi-x5hd2-dkb.dtb
arch/arm/boot/dts/exynos5422-odroidxu3.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
arch/arm/boot/dts/exynos5422-odroidxu3.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4: Reference to non-existent node or label "gpu"
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidxu3.dtb] Error 2
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4: Reference to non-existent node or label "gpu"
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb] Error 2
arch/arm/boot/dts/exynos5422-odroidxu4.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
arch/arm/boot/dts/exynos5422-odroidxu4.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4: Reference to non-existent node or label "gpu"
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidxu4.dtb] Error 2
make: *** [arch/arm/Makefile:348: dtbs] Error 2
Log: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/3938632189#L8634
Presumably caused by "ARM: dts: exynos: Add GPU thermal zone cooling maps for Odroid XU3/XU4/HC1", but I haven't had a chance to revert and re-test.
Kind regards, Chris
^ permalink raw reply [flat|nested] 54+ messages in thread* RE: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 14:12 ` [PATCH 4.19 00/39] 4.19.278-rc1 review Chris Paterson
@ 2023-03-15 14:24 ` Chris Paterson
2023-03-16 7:48 ` Greg Kroah-Hartman
1 sibling, 0 replies; 54+ messages in thread
From: Chris Paterson @ 2023-03-15 14:24 UTC (permalink / raw)
To: Chris Paterson, Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
> From: Chris Paterson <Chris.Paterson2@renesas.com>
> Sent: 15 March 2023 14:13
>
> Hello Greg,
>
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Sent: 15 March 2023 12:12
> >
> > This is the start of the stable review cycle for the 4.19.278 release.
> > There are 39 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, 17 Mar 2023 11:57:10 +0000.
> > Anything received after that time might be too late.
>
> Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
> CI Pipeline:
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab
> .com%2Fcip-project%2Fcip-testing%2Flinux-stable-rc-ci%2F-
> %2Fpipelines%2F807195668&data=05%7C01%7CChris.Paterson2%40renesas.
> com%7C3e2acf37d58a4bfbbd3908db255fa3c8%7C53d82571da1947e49cb4625
> a166a4a2a%7C0%7C0%7C638144864918022713%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C&sdata=O61NN4m1S0Zhr55UiQSADXniMYXWx2%2
> BBLcAAy4MtHLo%3D&reserved=0
>
> We (CIP) are seeing some build issues with Linux 4.19.278-rc1
> (7cfb8ee7c98e).
>
>
> 1)
> In various arm, arm64 and x86 configurations we see:
> kernel/cgroup/cgroup.c: In function 'cgroup_attach_lock':
> kernel/cgroup/cgroup.c:2237:2: error: implicit declaration of function
> 'get_online_cpus'; did you mean 'get_online_mems'? [-Werror=implicit-
> function-declaration]
> get_online_cpus();
> ^~~~~~~~~~~~~~~
> get_online_mems
> kernel/cgroup/cgroup.c: In function 'cgroup_attach_unlock':
> kernel/cgroup/cgroup.c:2248:2: error: implicit declaration of function
> 'put_online_cpus'; did you mean 'num_online_cpus'? [-Werror=implicit-
> function-declaration]
> put_online_cpus();
> ^~~~~~~~~~~~~~~
> num_online_cpus
>
> For example:
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab
> .com%2Fcip-project%2Fcip-testing%2Flinux-stable-rc-ci%2F-
> %2Fjobs%2F3938632173%23L1274&data=05%7C01%7CChris.Paterson2%40re
> nesas.com%7C3e2acf37d58a4bfbbd3908db255fa3c8%7C53d82571da1947e49c
> b4625a166a4a2a%7C0%7C0%7C638144864918022713%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C3000%7C%7C%7C&sdata=teWNvt%2Bu2l1S60qiGOTPyLA6bB1
> CvxJ0XedA2qCDmFI%3D&reserved=0
>
> Presumably this issue is caused by "cgroup: Fix threadgroup_rwsem <->
> cpus_read_lock() deadlock", but I haven't had a chance to revert and re-test.
>
>
> 2)
> For arm_multiconfig_v7 builds we're seeing a some errors when building the
This should have read arm multi_v7_defconfig, but you probably worked that out...
Kind regards, Chris
> exynos5422 device trees:
> arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR
> (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map0:
> Reference to non-existent node or label "gpu"
> arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR
> (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map1:
> Reference to non-existent node or label "gpu"
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-
> odroidhc1.dtb] Error 2
> make[1]: *** Waiting for unfinished jobs....
> DTC arch/arm/boot/dts/hi3519-demb.dtb
> DTC arch/arm/boot/dts/hisi-x5hd2-dkb.dtb
> arch/arm/boot/dts/exynos5422-odroidxu3.dtb: ERROR
> (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3:
> Reference to non-existent node or label "gpu"
> arch/arm/boot/dts/exynos5422-odroidxu3.dtb: ERROR
> (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4:
> Reference to non-existent node or label "gpu"
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-
> odroidxu3.dtb] Error 2
> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb: ERROR
> (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3:
> Reference to non-existent node or label "gpu"
> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb: ERROR
> (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4:
> Reference to non-existent node or label "gpu"
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-
> odroidxu3-lite.dtb] Error 2
> arch/arm/boot/dts/exynos5422-odroidxu4.dtb: ERROR
> (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3:
> Reference to non-existent node or label "gpu"
> arch/arm/boot/dts/exynos5422-odroidxu4.dtb: ERROR
> (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4:
> Reference to non-existent node or label "gpu"
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-
> odroidxu4.dtb] Error 2
> make: *** [arch/arm/Makefile:348: dtbs] Error 2
>
> Log:
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab
> .com%2Fcip-project%2Fcip-testing%2Flinux-stable-rc-ci%2F-
> %2Fjobs%2F3938632189%23L8634&data=05%7C01%7CChris.Paterson2%40re
> nesas.com%7C3e2acf37d58a4bfbbd3908db255fa3c8%7C53d82571da1947e49c
> b4625a166a4a2a%7C0%7C0%7C638144864918022713%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C3000%7C%7C%7C&sdata=6JWX1vUABxWE27R2%2BzPSNnQe0
> 8erwGJHyKkhVYKANww%3D&reserved=0
>
> Presumably caused by "ARM: dts: exynos: Add GPU thermal zone cooling
> maps for Odroid XU3/XU4/HC1", but I haven't had a chance to revert and re-
> test.
>
>
> Kind regards, Chris
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 14:12 ` [PATCH 4.19 00/39] 4.19.278-rc1 review Chris Paterson
2023-03-15 14:24 ` Chris Paterson
@ 2023-03-16 7:48 ` Greg Kroah-Hartman
1 sibling, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-16 7:48 UTC (permalink / raw)
To: Chris Paterson
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
On Wed, Mar 15, 2023 at 02:12:46PM +0000, Chris Paterson wrote:
> Hello Greg,
>
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Sent: 15 March 2023 12:12
> >
> > This is the start of the stable review cycle for the 4.19.278 release.
> > There are 39 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, 17 Mar 2023 11:57:10 +0000.
> > Anything received after that time might be too late.
>
> Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
> CI Pipeline: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/807195668
>
> We (CIP) are seeing some build issues with Linux 4.19.278-rc1 (7cfb8ee7c98e).
>
>
> 1)
> In various arm, arm64 and x86 configurations we see:
> kernel/cgroup/cgroup.c: In function 'cgroup_attach_lock':
> kernel/cgroup/cgroup.c:2237:2: error: implicit declaration of function 'get_online_cpus'; did you mean 'get_online_mems'? [-Werror=implicit-function-declaration]
> get_online_cpus();
> ^~~~~~~~~~~~~~~
> get_online_mems
> kernel/cgroup/cgroup.c: In function 'cgroup_attach_unlock':
> kernel/cgroup/cgroup.c:2248:2: error: implicit declaration of function 'put_online_cpus'; did you mean 'num_online_cpus'? [-Werror=implicit-function-declaration]
> put_online_cpus();
> ^~~~~~~~~~~~~~~
> num_online_cpus
>
> For example: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/3938632173#L1274
>
> Presumably this issue is caused by "cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock", but I haven't had a chance to revert and re-test.
>
>
> 2)
> For arm_multiconfig_v7 builds we're seeing a some errors when building the exynos5422 device trees:
> arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map0: Reference to non-existent node or label "gpu"
> arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map1: Reference to non-existent node or label "gpu"
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidhc1.dtb] Error 2
> make[1]: *** Waiting for unfinished jobs....
> DTC arch/arm/boot/dts/hi3519-demb.dtb
> DTC arch/arm/boot/dts/hisi-x5hd2-dkb.dtb
> arch/arm/boot/dts/exynos5422-odroidxu3.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
> arch/arm/boot/dts/exynos5422-odroidxu3.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4: Reference to non-existent node or label "gpu"
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidxu3.dtb] Error 2
> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4: Reference to non-existent node or label "gpu"
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb] Error 2
> arch/arm/boot/dts/exynos5422-odroidxu4.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
> arch/arm/boot/dts/exynos5422-odroidxu4.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4: Reference to non-existent node or label "gpu"
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidxu4.dtb] Error 2
> make: *** [arch/arm/Makefile:348: dtbs] Error 2
>
> Log: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/3938632189#L8634
>
> Presumably caused by "ARM: dts: exynos: Add GPU thermal zone cooling maps for Odroid XU3/XU4/HC1", but I haven't had a chance to revert and re-test.
>
>
Thanks, these should all be fixed in the next -rc2.
greg k-h
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (39 preceding siblings ...)
2023-03-15 14:12 ` [PATCH 4.19 00/39] 4.19.278-rc1 review Chris Paterson
@ 2023-03-15 14:32 ` Guenter Roeck
2023-03-15 15:44 ` Daniel Díaz
` (2 subsequent siblings)
43 siblings, 0 replies; 54+ messages in thread
From: Guenter Roeck @ 2023-03-15 14:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
On 3/15/23 05:12, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.278 release.
> There are 39 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, 17 Mar 2023 11:57:10 +0000.
> Anything received after that time might be too late.
>
Building arm64:defconfig ... failed
--------------
Error log:
kernel/cgroup/cgroup.c: In function 'cgroup_attach_lock':
kernel/cgroup/cgroup.c:2237:9: error: implicit declaration of function 'get_online_cpus'; did you mean 'get_online_mems'? [-Werror=implicit-function-declaration]
2237 | get_online_cpus();
| ^~~~~~~~~~~~~~~
| get_online_mems
kernel/cgroup/cgroup.c: In function 'cgroup_attach_unlock':
kernel/cgroup/cgroup.c:2248:9: error: implicit declaration of function 'put_online_cpus'; did you mean 'num_online_cpus'? [-Werror=implicit-function-declaration]
2248 | put_online_cpus();
| ^~~~~~~~~~~~~~~
| num_online_cpus
This affects other architectures as well. Builds are not complete
so I don't see the full impact yet.
Guenter
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (40 preceding siblings ...)
2023-03-15 14:32 ` Guenter Roeck
@ 2023-03-15 15:44 ` Daniel Díaz
2023-03-15 15:59 ` Guenter Roeck
` (2 more replies)
2023-03-16 0:04 ` Shuah Khan
2023-03-16 8:51 ` Missing patches in 4.19? was " Pavel Machek
43 siblings, 3 replies; 54+ messages in thread
From: Daniel Díaz @ 2023-03-15 15:44 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
Hello!
On 15/03/23 06:12, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.278 release.
> There are 39 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, 17 Mar 2023 11:57:10 +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/v4.x/stable-review/patch-4.19.278-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-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Lots and lots of failures, mostly Arm.
For Arm, Arm64, MIPS, with GCC-8, GCC-9, GCC-10, GCC-11, GCC-12, Clang-16, for some combinations with:
* axm55xx_defconfig
* davinci_all_defconfig
* defconfig
* defconfig-40bc7ee5
* lkftconfig-kasan
* multi_v5_defconfig
* s5pv210_defconfig
* sama5_defconfig
-----8<-----
/builds/linux/kernel/cgroup/cgroup.c:2237:2: error: implicit declaration of function 'get_online_cpus' [-Werror,-Wimplicit-function-declaration]
get_online_cpus();
^
/builds/linux/kernel/cgroup/cgroup.c:2237:2: note: did you mean 'get_online_mems'?
/builds/linux/include/linux/memory_hotplug.h:258:20: note: 'get_online_mems' declared here
static inline void get_online_mems(void) {}
^
/builds/linux/kernel/cgroup/cgroup.c:2248:2: error: implicit declaration of function 'put_online_cpus' [-Werror,-Wimplicit-function-declaration]
put_online_cpus();
^
/builds/linux/kernel/cgroup/cgroup.c:2248:2: note: did you mean 'put_online_mems'?
/builds/linux/include/linux/memory_hotplug.h:259:20: note: 'put_online_mems' declared here
static inline void put_online_mems(void) {}
^
2 errors generated.
make[3]: *** [/builds/linux/scripts/Makefile.build:303: kernel/cgroup/cgroup.o] Error 1
----->8-----
For Arm64, i386 x86, with GCC-11, Perf has a new error:
-----8<-----
In function 'ready',
inlined from 'sender' at bench/sched-messaging.c:90:2:
bench/sched-messaging.c:76:13: error: 'dummy' is used uninitialized [-Werror=uninitialized]
76 | if (write(ready_out, &dummy, 1) != 1)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from bench/../perf-sys.h:5,
from bench/../perf.h:18,
from bench/sched-messaging.c:13:
----->8-----
Greetings!
Daniel Díaz
daniel.diaz@linaro.org
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 15:44 ` Daniel Díaz
@ 2023-03-15 15:59 ` Guenter Roeck
2023-03-15 16:35 ` Greg Kroah-Hartman
2023-03-15 16:28 ` Daniel Díaz
2023-03-16 7:47 ` Greg Kroah-Hartman
2 siblings, 1 reply; 54+ messages in thread
From: Guenter Roeck @ 2023-03-15 15:59 UTC (permalink / raw)
To: Daniel Díaz, Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
On 3/15/23 08:44, Daniel Díaz wrote:
> Hello!
>
> On 15/03/23 06:12, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.19.278 release.
>> There are 39 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, 17 Mar 2023 11:57:10 +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/v4.x/stable-review/patch-4.19.278-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-4.19.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>
> Lots and lots of failures, mostly Arm.
>
> For Arm, Arm64, MIPS, with GCC-8, GCC-9, GCC-10, GCC-11, GCC-12, Clang-16, for some combinations with:
> * axm55xx_defconfig
> * davinci_all_defconfig
> * defconfig
> * defconfig-40bc7ee5
> * lkftconfig-kasan
> * multi_v5_defconfig
> * s5pv210_defconfig
> * sama5_defconfig
>
> -----8<-----
> /builds/linux/kernel/cgroup/cgroup.c:2237:2: error: implicit declaration of function 'get_online_cpus' [-Werror,-Wimplicit-function-declaration]
> get_online_cpus();
> ^
> /builds/linux/kernel/cgroup/cgroup.c:2237:2: note: did you mean 'get_online_mems'?
> /builds/linux/include/linux/memory_hotplug.h:258:20: note: 'get_online_mems' declared here
> static inline void get_online_mems(void) {}
> ^
> /builds/linux/kernel/cgroup/cgroup.c:2248:2: error: implicit declaration of function 'put_online_cpus' [-Werror,-Wimplicit-function-declaration]
> put_online_cpus();
> ^
> /builds/linux/kernel/cgroup/cgroup.c:2248:2: note: did you mean 'put_online_mems'?
> /builds/linux/include/linux/memory_hotplug.h:259:20: note: 'put_online_mems' declared here
> static inline void put_online_mems(void) {}
> ^
> 2 errors generated.
> make[3]: *** [/builds/linux/scripts/Makefile.build:303: kernel/cgroup/cgroup.o] Error 1
> ----->8-----
>
>
> For Arm64, i386 x86, with GCC-11, Perf has a new error:
>
> -----8<-----
> In function 'ready',
> inlined from 'sender' at bench/sched-messaging.c:90:2:
> bench/sched-messaging.c:76:13: error: 'dummy' is used uninitialized [-Werror=uninitialized]
> 76 | if (write(ready_out, &dummy, 1) != 1)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from bench/../perf-sys.h:5,
> from bench/../perf.h:18,
> from bench/sched-messaging.c:13:
> ----->8-----
>
>
> Greetings!
>
> Daniel Díaz
> daniel.diaz@linaro.org
>
Looks like this whole set of release candidates is a disaster. I have stopped
my testbed for the time being (no point in wasting energy), so there won't be
any further updates from me for the time being.
Guenter
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 15:59 ` Guenter Roeck
@ 2023-03-15 16:35 ` Greg Kroah-Hartman
0 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-15 16:35 UTC (permalink / raw)
To: Guenter Roeck
Cc: Daniel Díaz, stable, patches, linux-kernel, torvalds, akpm,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
On Wed, Mar 15, 2023 at 08:59:14AM -0700, Guenter Roeck wrote:
> On 3/15/23 08:44, Daniel Díaz wrote:
> > Hello!
> >
> > On 15/03/23 06:12, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.19.278 release.
> > > There are 39 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, 17 Mar 2023 11:57:10 +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/v4.x/stable-review/patch-4.19.278-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-4.19.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Lots and lots of failures, mostly Arm.
> >
> > For Arm, Arm64, MIPS, with GCC-8, GCC-9, GCC-10, GCC-11, GCC-12, Clang-16, for some combinations with:
> > * axm55xx_defconfig
> > * davinci_all_defconfig
> > * defconfig
> > * defconfig-40bc7ee5
> > * lkftconfig-kasan
> > * multi_v5_defconfig
> > * s5pv210_defconfig
> > * sama5_defconfig
> >
> > -----8<-----
> > /builds/linux/kernel/cgroup/cgroup.c:2237:2: error: implicit declaration of function 'get_online_cpus' [-Werror,-Wimplicit-function-declaration]
> > get_online_cpus();
> > ^
> > /builds/linux/kernel/cgroup/cgroup.c:2237:2: note: did you mean 'get_online_mems'?
> > /builds/linux/include/linux/memory_hotplug.h:258:20: note: 'get_online_mems' declared here
> > static inline void get_online_mems(void) {}
> > ^
> > /builds/linux/kernel/cgroup/cgroup.c:2248:2: error: implicit declaration of function 'put_online_cpus' [-Werror,-Wimplicit-function-declaration]
> > put_online_cpus();
> > ^
> > /builds/linux/kernel/cgroup/cgroup.c:2248:2: note: did you mean 'put_online_mems'?
> > /builds/linux/include/linux/memory_hotplug.h:259:20: note: 'put_online_mems' declared here
> > static inline void put_online_mems(void) {}
> > ^
> > 2 errors generated.
> > make[3]: *** [/builds/linux/scripts/Makefile.build:303: kernel/cgroup/cgroup.o] Error 1
> > ----->8-----
> >
> >
> > For Arm64, i386 x86, with GCC-11, Perf has a new error:
> >
> > -----8<-----
> > In function 'ready',
> > inlined from 'sender' at bench/sched-messaging.c:90:2:
> > bench/sched-messaging.c:76:13: error: 'dummy' is used uninitialized [-Werror=uninitialized]
> > 76 | if (write(ready_out, &dummy, 1) != 1)
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from bench/../perf-sys.h:5,
> > from bench/../perf.h:18,
> > from bench/sched-messaging.c:13:
> > ----->8-----
> >
> >
> > Greetings!
> >
> > Daniel Díaz
> > daniel.diaz@linaro.org
> >
>
> Looks like this whole set of release candidates is a disaster. I have stopped
> my testbed for the time being (no point in wasting energy), so there won't be
> any further updates from me for the time being.
Thanks, yeah, looks like only x86 seems to work here, I'll drop a bunch
of patches and push out -rc2 later tonight.
sorry for the mess, turns out that lots of different set of backports
broke arches they were not expecting to :(
greg k-h
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 15:44 ` Daniel Díaz
2023-03-15 15:59 ` Guenter Roeck
@ 2023-03-15 16:28 ` Daniel Díaz
2023-03-16 7:48 ` Greg Kroah-Hartman
2023-03-16 7:47 ` Greg Kroah-Hartman
2 siblings, 1 reply; 54+ messages in thread
From: Daniel Díaz @ 2023-03-15 16:28 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
Hello!
On 15/03/23 09:44, Daniel Díaz wrote:
> Hello!
>
> On 15/03/23 06:12, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.19.278 release.
>> There are 39 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, 17 Mar 2023 11:57:10 +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/v4.x/stable-review/patch-4.19.278-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-4.19.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>
> Lots and lots of failures, mostly Arm.
>
> For Arm, Arm64, MIPS, with GCC-8, GCC-9, GCC-10, GCC-11, GCC-12, Clang-16, for some combinations with:
> * axm55xx_defconfig
> * davinci_all_defconfig
> * defconfig
> * defconfig-40bc7ee5
> * lkftconfig-kasan
> * multi_v5_defconfig
> * s5pv210_defconfig
> * sama5_defconfig
>
> -----8<-----
> /builds/linux/kernel/cgroup/cgroup.c:2237:2: error: implicit declaration of function 'get_online_cpus' [-Werror,-Wimplicit-function-declaration]
> get_online_cpus();
> ^
> /builds/linux/kernel/cgroup/cgroup.c:2237:2: note: did you mean 'get_online_mems'?
> /builds/linux/include/linux/memory_hotplug.h:258:20: note: 'get_online_mems' declared here
> static inline void get_online_mems(void) {}
> ^
> /builds/linux/kernel/cgroup/cgroup.c:2248:2: error: implicit declaration of function 'put_online_cpus' [-Werror,-Wimplicit-function-declaration]
> put_online_cpus();
> ^
> /builds/linux/kernel/cgroup/cgroup.c:2248:2: note: did you mean 'put_online_mems'?
> /builds/linux/include/linux/memory_hotplug.h:259:20: note: 'put_online_mems' declared here
> static inline void put_online_mems(void) {}
> ^
> 2 errors generated.
> make[3]: *** [/builds/linux/scripts/Makefile.build:303: kernel/cgroup/cgroup.o] Error 1
> ----->8-----
>
>
> For Arm64, i386 x86, with GCC-11, Perf has a new error:
>
> -----8<-----
> In function 'ready',
> inlined from 'sender' at bench/sched-messaging.c:90:2:
> bench/sched-messaging.c:76:13: error: 'dummy' is used uninitialized [-Werror=uninitialized]
> 76 | if (write(ready_out, &dummy, 1) != 1)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from bench/../perf-sys.h:5,
> from bench/../perf.h:18,
> from bench/sched-messaging.c:13:
> ----->8-----
Additionally, there's this on Arm with GCC-10, GCC-12, Clang-16 for:
* defconfig
* exynos_defconfig
* lkftconfig
* lkftconfig-debug
* lkftconfig-debug-kmemleak
* lkftconfig-kasan
* lkftconfig-kselftest-kernel
* lkftconfig-kunit
* lkftconfig-libgpiod
* lkftconfig-perf
* lkftconfig-rcutorture
-----8<-----
arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map0: Reference to non-existent node or label "gpu"
arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map1: Reference to non-existent node or label "gpu"
ERROR: Input tree has errors, aborting (use -f to force output)
make[2]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidhc1.dtb] Error 2
arch/arm/boot/dts/exynos5422-odroidxu3.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
arch/arm/boot/dts/exynos5422-odroidxu3.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4: Reference to non-existent node or label "gpu"
ERROR: Input tree has errors, aborting (use -f to force output)
make[2]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidxu3.dtb] Error 2
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4: Reference to non-existent node or label "gpu"
ERROR: Input tree has errors, aborting (use -f to force output)
make[2]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb] Error 2
arch/arm/boot/dts/exynos5422-odroidxu4.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
arch/arm/boot/dts/exynos5422-odroidxu4.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map4: Reference to non-existent node or label "gpu"
ERROR: Input tree has errors, aborting (use -f to force output)
make[2]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidxu4.dtb] Error 2
----->8-----
Greetings!
Daniel Díaz
daniel.diaz@linaro.org
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 16:28 ` Daniel Díaz
@ 2023-03-16 7:48 ` Greg Kroah-Hartman
0 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-16 7:48 UTC (permalink / raw)
To: Daniel Díaz
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
On Wed, Mar 15, 2023 at 10:28:15AM -0600, Daniel Díaz wrote:
> Hello!
>
> On 15/03/23 09:44, Daniel Díaz wrote:
> > Hello!
> >
> > On 15/03/23 06:12, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.19.278 release.
> > > There are 39 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, 17 Mar 2023 11:57:10 +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/v4.x/stable-review/patch-4.19.278-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-4.19.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Lots and lots of failures, mostly Arm.
> >
> > For Arm, Arm64, MIPS, with GCC-8, GCC-9, GCC-10, GCC-11, GCC-12, Clang-16, for some combinations with:
> > * axm55xx_defconfig
> > * davinci_all_defconfig
> > * defconfig
> > * defconfig-40bc7ee5
> > * lkftconfig-kasan
> > * multi_v5_defconfig
> > * s5pv210_defconfig
> > * sama5_defconfig
> >
> > -----8<-----
> > /builds/linux/kernel/cgroup/cgroup.c:2237:2: error: implicit declaration of function 'get_online_cpus' [-Werror,-Wimplicit-function-declaration]
> > get_online_cpus();
> > ^
> > /builds/linux/kernel/cgroup/cgroup.c:2237:2: note: did you mean 'get_online_mems'?
> > /builds/linux/include/linux/memory_hotplug.h:258:20: note: 'get_online_mems' declared here
> > static inline void get_online_mems(void) {}
> > ^
> > /builds/linux/kernel/cgroup/cgroup.c:2248:2: error: implicit declaration of function 'put_online_cpus' [-Werror,-Wimplicit-function-declaration]
> > put_online_cpus();
> > ^
> > /builds/linux/kernel/cgroup/cgroup.c:2248:2: note: did you mean 'put_online_mems'?
> > /builds/linux/include/linux/memory_hotplug.h:259:20: note: 'put_online_mems' declared here
> > static inline void put_online_mems(void) {}
> > ^
> > 2 errors generated.
> > make[3]: *** [/builds/linux/scripts/Makefile.build:303: kernel/cgroup/cgroup.o] Error 1
> > ----->8-----
> >
> >
> > For Arm64, i386 x86, with GCC-11, Perf has a new error:
> >
> > -----8<-----
> > In function 'ready',
> > inlined from 'sender' at bench/sched-messaging.c:90:2:
> > bench/sched-messaging.c:76:13: error: 'dummy' is used uninitialized [-Werror=uninitialized]
> > 76 | if (write(ready_out, &dummy, 1) != 1)
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from bench/../perf-sys.h:5,
> > from bench/../perf.h:18,
> > from bench/sched-messaging.c:13:
> > ----->8-----
>
> Additionally, there's this on Arm with GCC-10, GCC-12, Clang-16 for:
> * defconfig
> * exynos_defconfig
> * lkftconfig
> * lkftconfig-debug
> * lkftconfig-debug-kmemleak
> * lkftconfig-kasan
> * lkftconfig-kselftest-kernel
> * lkftconfig-kunit
> * lkftconfig-libgpiod
> * lkftconfig-perf
> * lkftconfig-rcutorture
>
> -----8<-----
> arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map0: Reference to non-existent node or label "gpu"
>
> arch/arm/boot/dts/exynos5422-odroidhc1.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map1: Reference to non-existent node or label "gpu"
>
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[2]: *** [scripts/Makefile.lib:294: arch/arm/boot/dts/exynos5422-odroidhc1.dtb] Error 2
> arch/arm/boot/dts/exynos5422-odroidxu3.dtb: ERROR (phandle_references): /thermal-zones/gpu-thermal/cooling-maps/map3: Reference to non-existent node or label "gpu"
>
<snip>
Thanks, Sasha dropped the offending commit from the queue, and I've
dropped a few more as well, so this should be fixed up when -rc2 comes
out.
greg k-h
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 15:44 ` Daniel Díaz
2023-03-15 15:59 ` Guenter Roeck
2023-03-15 16:28 ` Daniel Díaz
@ 2023-03-16 7:47 ` Greg Kroah-Hartman
2 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-16 7:47 UTC (permalink / raw)
To: Daniel Díaz
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
On Wed, Mar 15, 2023 at 09:44:59AM -0600, Daniel Díaz wrote:
> Hello!
>
> On 15/03/23 06:12, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.278 release.
> > There are 39 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, 17 Mar 2023 11:57:10 +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/v4.x/stable-review/patch-4.19.278-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-4.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Lots and lots of failures, mostly Arm.
>
> For Arm, Arm64, MIPS, with GCC-8, GCC-9, GCC-10, GCC-11, GCC-12, Clang-16, for some combinations with:
> * axm55xx_defconfig
> * davinci_all_defconfig
> * defconfig
> * defconfig-40bc7ee5
> * lkftconfig-kasan
> * multi_v5_defconfig
> * s5pv210_defconfig
> * sama5_defconfig
>
> -----8<-----
> /builds/linux/kernel/cgroup/cgroup.c:2237:2: error: implicit declaration of function 'get_online_cpus' [-Werror,-Wimplicit-function-declaration]
> get_online_cpus();
> ^
> /builds/linux/kernel/cgroup/cgroup.c:2237:2: note: did you mean 'get_online_mems'?
> /builds/linux/include/linux/memory_hotplug.h:258:20: note: 'get_online_mems' declared here
> static inline void get_online_mems(void) {}
> ^
> /builds/linux/kernel/cgroup/cgroup.c:2248:2: error: implicit declaration of function 'put_online_cpus' [-Werror,-Wimplicit-function-declaration]
> put_online_cpus();
> ^
> /builds/linux/kernel/cgroup/cgroup.c:2248:2: note: did you mean 'put_online_mems'?
> /builds/linux/include/linux/memory_hotplug.h:259:20: note: 'put_online_mems' declared here
> static inline void put_online_mems(void) {}
> ^
> 2 errors generated.
> make[3]: *** [/builds/linux/scripts/Makefile.build:303: kernel/cgroup/cgroup.o] Error 1
> ----->8-----
This should now be resolved, I'll do a -rc2 with the fixes.
> For Arm64, i386 x86, with GCC-11, Perf has a new error:
>
> -----8<-----
> In function 'ready',
> inlined from 'sender' at bench/sched-messaging.c:90:2:
> bench/sched-messaging.c:76:13: error: 'dummy' is used uninitialized [-Werror=uninitialized]
> 76 | if (write(ready_out, &dummy, 1) != 1)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from bench/../perf-sys.h:5,
> from bench/../perf.h:18,
> from bench/sched-messaging.c:13:
> ----->8-----
That's odd as I don't see any perf patches for 4.19.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (41 preceding siblings ...)
2023-03-15 15:44 ` Daniel Díaz
@ 2023-03-16 0:04 ` Shuah Khan
2023-03-16 8:51 ` Missing patches in 4.19? was " Pavel Machek
43 siblings, 0 replies; 54+ messages in thread
From: Shuah Khan @ 2023-03-16 0:04 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, Shuah Khan
On 3/15/23 06:12, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.278 release.
> There are 39 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, 17 Mar 2023 11:57:10 +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/v4.x/stable-review/patch-4.19.278-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-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 54+ messages in thread* Missing patches in 4.19? was Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-15 12:12 [PATCH 4.19 00/39] 4.19.278-rc1 review Greg Kroah-Hartman
` (42 preceding siblings ...)
2023-03-16 0:04 ` Shuah Khan
@ 2023-03-16 8:51 ` Pavel Machek
2023-03-16 9:34 ` Greg Kroah-Hartman
43 siblings, 1 reply; 54+ messages in thread
From: Pavel Machek @ 2023-03-16 8:51 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
Hi!
> Pseudo-Shortlog of commits:
There is something missing here.
In 5.10-rc we have:
de365066382ce0dbbf3b7189128ccc16e4eae198 net: caif: Fix use-after-free in cfusbl_device_notify()
4.14-rc has:
921b052b636c72fbb97c50bd0be33bd7358ab374 net: caif: Fix use-after-free in cfusbl_device_notify()
But I don't see corresponding patch in 4.19.
More than one patch may be affected:
|70cec8eec 9781e9 .: 5.10| net: caif: Fix use-after-free in cfusbl_device_notify()
|f690886b9 9781e9 .: 4.14| net: caif: Fix use-after-free in cfusbl_device_notify()
|98e6078de 11f180 .: 5.10| nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties
|012961752 11f180 .: 4.14| nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties
|b4e4d4931 693aa2 o: 5.10| ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()
|f2b350c04 693aa2 o: 4.14| ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: Missing patches in 4.19? was Re: [PATCH 4.19 00/39] 4.19.278-rc1 review
2023-03-16 8:51 ` Missing patches in 4.19? was " Pavel Machek
@ 2023-03-16 9:34 ` Greg Kroah-Hartman
0 siblings, 0 replies; 54+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-16 9:34 UTC (permalink / raw)
To: Pavel Machek
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, jonathanh, f.fainelli, sudipm.mukherjee,
srw, rwarsow
On Thu, Mar 16, 2023 at 09:51:11AM +0100, Pavel Machek wrote:
> Hi!
>
> > Pseudo-Shortlog of commits:
>
> There is something missing here.
>
> In 5.10-rc we have:
>
> de365066382ce0dbbf3b7189128ccc16e4eae198 net: caif: Fix use-after-free in cfusbl_device_notify()
>
> 4.14-rc has:
>
> 921b052b636c72fbb97c50bd0be33bd7358ab374 net: caif: Fix use-after-free in cfusbl_device_notify()
>
> But I don't see corresponding patch in 4.19.
>
> More than one patch may be affected:
>
> |70cec8eec 9781e9 .: 5.10| net: caif: Fix use-after-free in cfusbl_device_notify()
> |f690886b9 9781e9 .: 4.14| net: caif: Fix use-after-free in cfusbl_device_notify()
> |98e6078de 11f180 .: 5.10| nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties
> |012961752 11f180 .: 4.14| nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties
> |b4e4d4931 693aa2 o: 5.10| ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()
> |f2b350c04 693aa2 o: 4.14| ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()
Good catch, now queued up and I'll push out a -rc3.
^ permalink raw reply [flat|nested] 54+ messages in thread