5.10.177-rc1 review
Subsystems (7)
Greg Kroah-Hartman
maintainerPATCH 162/173 drm/etnaviv: fix reference leak when mmaping imported buffer
In reply to Greg Kroah-HartmanFrom: Lucas Stach <[email protected]>
commit 963b2e8c428f79489ceeb058e8314554ec9cbe6f upstream.
drm_gem_prime_mmap() takes a reference on the GEM object, but before that drm_gem_mmap_obj() already takes a reference, which will be leaked as only one reference is dropped when the mapping is closed. Drop the extra reference when dma_buf_mmap() succeeds.
--- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +9 -1
@@ -93,7 +93,15 @@ static void *etnaviv_gem_prime_vmap_implstatic int etnaviv_gem_prime_mmap_obj (struct etnaviv_gem_object *etnaviv_obj,struct vm_area_struct *vma) { -return dma_buf_mmap (etnaviv_obj->base.dma_buf, vma,0 ); +int ret; + + ret =dma_buf_mmap (etnaviv_obj->base.dma_buf, vma,0 ); +if (!ret) { +/* Drop the reference acquired by drm_gem_mmap_obj(). */ +drm_gem_object_put (&etnaviv_obj->base); + } + +return ret; }static const struct etnaviv_gem_ops etnaviv_gem_prime_ops = {
Greg Kroah-Hartman
maintainerPATCH 163/173 drm/amd/display: Add DSC Support for Synaptics Cascaded MST Hub
In reply to Greg Kroah-HartmanFrom: Fangzhi Zuo <[email protected]>
commit f4f3b7dedbe849e780c779ba67365bb1db0d8637 upstream.
Traditional synaptics hub has one MST branch device without virtual dpcd. Synaptics cascaded hub has two chained MST branch devices. DSC decoding is performed via root MST branch device, instead of the second MST branch device.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 19 ++++++++++++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h | 12 +++++++ 2 files changed, 31 insertions(+)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +19 -0
@@ -164,6 +164,21 @@ static bool needs_dsc_aux_workaround(strreturn false; } +bool is_synaptics_cascaded_panamera (struct dc_link *link,struct drm_dp_mst_port *port) +{ +u8 branch_vendor_data[4 ] = {0 };// Vendor data 0x50C ~ 0x50F + +if (drm_dp_dpcd_read (port->mgr->aux,DP_BRANCH_VENDOR_SPECIFIC_START , &branch_vendor_data,4 ) ==4 ) { +if (link->dpcd_caps.branch_dev_id ==DP_BRANCH_DEVICE_ID_90CC24 && +IS_SYNAPTICS_CASCADED_PANAMERA (link->dpcd_caps.branch_dev_name, branch_vendor_data)) { +DRM_INFO ("Synaptics Cascaded MST hub\n" ); +return true; + } + } + +return false; +} +static bool validate_dsc_caps_on_connector (struct amdgpu_dm_connector *aconnector) {struct dc_sink *dc_sink = aconnector->dc_sink;
@@ -185,6 +200,10 @@ static bool validate_dsc_caps_on_connect needs_dsc_aux_workaround(aconnector->dc_link)) aconnector->dsc_aux = &aconnector->mst_port->dm_dp_aux.aux; +/* synaptics cascaded MST hub case */ +if (!aconnector->dsc_aux &&is_synaptics_cascaded_panamera (aconnector->dc_link, port)) + aconnector->dsc_aux = port->mgr->aux; +if (!aconnector->dsc_aux)return false;
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h +12 -0
@@ -26,6 +26,18 @@#ifndef __DAL_AMDGPU_DM_MST_TYPES_H__#define __DAL_AMDGPU_DM_MST_TYPES_H__ +#define DP_BRANCH_VENDOR_SPECIFIC_START 0x50C + +/** +* Panamera MST Hub detection +* Offset DPCD 050Eh == 0x5A indicates cascaded MST hub case +* Check from beginning of branch device vendor specific field (050Ch) +*/ +#define IS_SYNAPTICS_PANAMERA (branchDevName) (((int)branchDevName[4] & 0xF0) == 0x50 ? 1 : 0) +#define BRANCH_HW_REVISION_PANAMERA_A2 0x10 +#define SYNAPTICS_CASCADED_HUB_ID 0x5A +#define IS_SYNAPTICS_CASCADED_PANAMERA (devName, data) ((IS_SYNAPTICS_PANAMERA(devName) && ((int)data[2] == SYNAPTICS_CASCADED_HUB_ID)) ? 1 : 0) +struct amdgpu_display_manager ;struct amdgpu_dm_connector ;
Greg Kroah-Hartman
maintainerPATCH 164/173 s390/uaccess: add missing earlyclobber annotations to __clear_user()
In reply to Greg Kroah-HartmanFrom: Heiko Carstens <[email protected]>
commit 89aba4c26fae4e459f755a18912845c348ee48f3 upstream.
Add missing earlyclobber annotation to size, to, and tmp2 operands of the __clear_user() inline assembly since they are modified or written to before the last usage of all input operands. This can lead to incorrect register allocation for the inline assembly.
--- arch/s390/lib/uaccess.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/s390/lib/uaccess.c +1 -1
@@ -339,7 +339,7 @@ static inline unsigned long clear_user_m"4: slgr %0,%0\n" "5:\n" EX_TABLE(0b,2b) EX_TABLE(3b,5b) - : "+a" (size), "+a" (to), "+a" (tmp1), "=a" (tmp2) + : "+&a" (size), "+&a" (to), "+a" (tmp1), "=&a" (tmp2) : "a" (empty_zero_page), "d" (reg0) : "cc", "memory");return size; }
Greg Kroah-Hartman
maintainerPATCH 165/173 btrfs: scan device in non-exclusive mode
In reply to Greg Kroah-HartmanFrom: Anand Jain <[email protected]>
commit 50d281fc434cb8e2497f5e70a309ccca6b1a09f0 upstream.
This fixes mkfs/mount/check failures due to race with systemd-udevd scan.
During the device scan initiated by systemd-udevd, other user space EXCL operations such as mkfs, mount, or check may get blocked and result in a "Device or resource busy" error. This is because the device scan process opens the device with the EXCL flag in the kernel.
Two reports were received:
- btrfs/179 test case, where the fsck command failed with the -EBUSY error
- LTP pwritev03 test case, where mkfs.vfs failed with
the -EBUSY error, when mkfs.vfs tried to overwrite old btrfs filesystem on the device.
In both cases, fsck and mkfs (respectively) were racing with a systemd-udevd device scan, and systemd-udevd won, resulting in the -EBUSY error for fsck and mkfs.
Reproducing the problem has been difficult because there is a very small window during which these userspace threads can race to acquire the exclusive device open. Even on the system where the problem was observed, the problem occurrences were anywhere between 10 to 400 iterations and chances of reproducing decreases with debug printk()s.
However, an exclusive device open is unnecessary for the scan process, as there are no write operations on the device during scan. Furthermore, during the mount process, the superblock is re-read in the below function call chain:
btrfs_mount_root
btrfs_open_devices
open_fs_devices
btrfs_open_one_device
btrfs_get_bdev_and_sb
So, to fix this issue, removes the FMODE_EXCL flag from the scan operation, and add a comment.
The case where mkfs may still write to the device and a scan is running, the btrfs signature is not written at that time so scan will not recognize such device.
--- fs/btrfs/volumes.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
fs/btrfs/volumes.c +10 -1
@@ -1411,8 +1411,17 @@ struct btrfs_device *btrfs_scan_one_devi* later supers, using BTRFS_SUPER_MIRROR_MAX instead */ bytenr =btrfs_sb_offset (0 ); - flags |=FMODE_EXCL ; +/* +* Avoid using flag |= FMODE_EXCL here, as the systemd-udev may +* initiate the device scan which may race with the user's mount +* or mkfs command, resulting in failure. +* Since the device scan is solely for reading purposes, there is +* no need for FMODE_EXCL. Additionally, the devices are read again +* during the mount process. It is ok to get some inconsistent +* values temporarily, as the device paths of the fsid are the only +* required information for assembling the volume. +*/ bdev =blkdev_get_by_path (path, flags, holder);if (IS_ERR (bdev))return ERR_CAST (bdev);
Greg Kroah-Hartman
maintainerPATCH 166/173 zonefs: Fix error message in zonefs_file_dio_append()
In reply to Greg Kroah-HartmanFrom: Damien Le Moal <[email protected]>
commit 88b170088ad2c3e27086fe35769aa49f8a512564 upstream.
Since the expected write location in a sequential file is always at the end of the file (append write), when an invalid write append location is detected in zonefs_file_dio_append(), print the invalid written location instead of the expected write location.
--- fs/zonefs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/zonefs/super.c +1 -1
@@ -789,7 +789,7 @@ static ssize_t zonefs_file_dio_append(stif (bio->bi_iter.bi_sector != wpsector) {zonefs_warn (inode->i_sb,"Corrupted write pointer %llu for zone at %llu\n" , - wpsector, zi->i_zsector); + bio->bi_iter.bi_sector, zi->i_zsector); ret = -EIO ; } }
Greg Kroah-Hartman
maintainerPATCH 167/173 selftests/bpf: Test btf dump for struct with padding only fields
In reply to Greg Kroah-HartmanFrom: Eduard Zingerman <[email protected]>
[ Upstream commit d503f1176b14f722a40ea5110312614982f9a80b ]
Structures with zero regular fields but some padding constitute a special case in btf_dump.c:btf_dump_emit_struct_def with regards to newline before closing '}'.
Stable-dep-of: ea2ce1ba99aa ("libbpf: Fix BTF-to-C converter's padding logic")
--- .../selftests/bpf/progs/btf_dump_test_case_padding.c | 9 +++++++++ 1 file changed, 9 insertions(+)
tools/testing/selftests/bpf/progs/btf_dump_test_case_padding.c +9 -0
@@ -102,12 +102,21 @@ struct zone {struct zone_padding __pad__; }; +/* ----- START-EXPECTED-OUTPUT ----- */ +struct padding_wo_named_members { + long: 64; + long: 64; +}; + +/* ------ END-EXPECTED-OUTPUT ------ */ +int f (struct {struct padded_implicitly _1;struct padded_explicitly _2;struct padded_a_lot _3;struct padded_cache_line _4;struct zone _5; +struct padding_wo_named_members _6; } *_) {return 0 ;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 168/173 libbpf: Fix BTF-to-C converters padding logic
In reply to Greg Kroah-HartmanFrom: Andrii Nakryiko <[email protected]>
[ Upstream commit ea2ce1ba99aa6a60c8d8a706e3abadf3de372163 ]
Turns out that btf_dump API doesn't handle a bunch of tricky corner cases, as reported by Per, and further discovered using his testing Python script ([0]).
This patch revamps btf_dump's padding logic significantly, making it more correct and also avoiding unnecessary explicit padding, where compiler would pad naturally. This overall topic turned out to be very tricky and subtle, there are lots of subtle corner cases. The comments in the code tries to give some clues, but comments themselves are supposed to be paired with good understanding of C alignment and padding rules. Plus some experimentation to figure out subtle things like whether long :0; means that struct is now forced to be long-aligned (no, it's not, turns out).
Anyways, Per's script, while not completely correct in some known situations, doesn't show any obvious cases where this logic breaks, so this is a nice improvement over the previous state of this logic.
Some selftests had to be adjusted to accommodate better use of natural alignment rules, eliminating some unnecessary padding, or changing it to type: 0; alignment markers.
Note also that for when we are in between bitfields, we emit explicit bit size, while otherwise we use : 0, this feels much more natural in practice.
Next patch will add few more test cases, found through randomized Per's script.
[0] https://lore.kernel.org/bpf/[email protected]/
--- tools/lib/bpf/btf_dump.c | 169 +++++++++++++----- .../bpf/progs/btf_dump_test_case_bitfields.c | 2 +- .../bpf/progs/btf_dump_test_case_padding.c | 58 ++++-- 3 files changed, 164 insertions(+), 65 deletions(-)
tools/lib/bpf/btf_dump.c +123 -46
@@ -788,6 +788,25 @@ static void btf_dump_emit_type(struct btf_dump *d, __u32 id, __u32 cont_id) } } +static int btf_natural_align_of (const struct btf *btf,__u32 id) +{ +const struct btf_type *t =btf__type_by_id (btf, id); +int i, align, vlen; +const struct btf_member *m; + +if (!btf_is_composite (t)) +return btf__align_of (btf, id); + + align =1 ; + m =btf_members (t); + vlen =btf_vlen (t); +for (i =0 ; i < vlen; i++, m++) { + align =max (align,btf__align_of (btf, m->type)); + } + +return align; +} +static bool btf_is_struct_packed (const struct btf *btf,__u32 id,const struct btf_type *t) {
@@ -795,16 +814,16 @@ static bool btf_is_struct_packed(const struct btf *btf, __u32 id,int align, i, bit_sz;__u16 vlen; - align =btf__align_of (btf, id); -/* size of a non-packed struct has to be a multiple of its alignment*/ -if (align && t->size % align) + align =btf_natural_align_of (btf, id); +/* size of a non-packed struct has to be a multiple of its alignment */ +if (align && (t->size % align) !=0 )return true; m =btf_members (t); vlen =btf_vlen (t);/* all non-bitfield fields have to be naturally aligned */ for (i =0 ; i < vlen; i++, m++) { - align =btf__align_of (btf, m->type); + align =btf_natural_align_of (btf, m->type); bit_sz =btf_member_bitfield_size (t, i);if (align && bit_sz ==0 && m->offset % (8 * align) !=0 )return true;
@@ -817,44 +836,97 @@ static bool btf_is_struct_packed(const struct btf *btf, __u32 id,return false; } -static int chip_away_bits (int total,int at_most) -{ -return total % at_most ? : at_most; -} -static void btf_dump_emit_bit_padding (const struct btf_dump *d, -int cur_off,int m_off,int m_bit_sz, -int align,int lvl) +int cur_off,int next_off,int next_align, +bool in_bitfield,int lvl) { -int off_diff = m_off - cur_off; -int ptr_bits = d->ptr_sz *8 ; +const struct { +const char *name; +int bits; + } pads[] = { + {"long" , d->ptr_sz *8 }, {"int" ,32 }, {"short" ,16 }, {"char" ,8 } + }; +int new_off, pad_bits, bits, i; +const char *pad_type; + +if (cur_off >= next_off) +return ;/* no gap */ + +/* For filling out padding we want to take advantage of +* natural alignment rules to minimize unnecessary explicit +* padding. First, we find the largest type (among long, int, +* short, or char) that can be used to force naturally aligned +* boundary. Once determined, we'll use such type to fill in +* the remaining padding gap. In some cases we can rely on +* compiler filling some gaps, but sometimes we need to force +* alignment to close natural alignment with markers like +* `long: 0` (this is always the case for bitfields). Note +* that even if struct itself has, let's say 4-byte alignment +* (i.e., it only uses up to int-aligned types), using `long: +* X;` explicit padding doesn't actually change struct's +* overall alignment requirements, but compiler does take into +* account that type's (long, in this example) natural +* alignment requirements when adding implicit padding. We use +* this fact heavily and don't worry about ruining correct +* struct alignment requirement. +*/ +for (i =0 ; i <ARRAY_SIZE (pads); i++) { + pad_bits = pads[i].bits; + pad_type = pads[i].name; -if (off_diff <=0 ) -/* no gap */ -return ; -if (m_bit_sz ==0 && off_diff < align *8 ) -/* natural padding will take care of a gap */ -return ; + new_off =roundup (cur_off, pad_bits); +if (new_off <= next_off) +break ; + } -while (off_diff >0 ) { -const char *pad_type; -int pad_bits; - -if (ptr_bits >32 && off_diff >32 ) { - pad_type ="long" ; - pad_bits =chip_away_bits (off_diff, ptr_bits); - }else if (off_diff >16 ) { - pad_type ="int" ; - pad_bits =chip_away_bits (off_diff,32 ); - }else if (off_diff >8 ) { - pad_type ="short" ; - pad_bits =chip_away_bits (off_diff,16 ); - }else { - pad_type ="char" ; - pad_bits =chip_away_bits (off_diff,8 ); +if (new_off > cur_off && new_off <= next_off) { +/* We need explicit `<type>: 0` aligning mark if next +* field is right on alignment offset and its +* alignment requirement is less strict than <type>'s +* alignment (so compiler won't naturally align to the +* offset we expect), or if subsequent `<type>: X`, +* will actually completely fit in the remaining hole, +* making compiler basically ignore `<type>: X` +* completely. +*/ +if (in_bitfield || + (new_off == next_off &&roundup (cur_off, next_align *8 ) != new_off) || + (new_off != next_off && next_off - new_off <= new_off - cur_off)) +/* but for bitfields we'll emit explicit bit count */ +btf_dump_printf (d,"\n%s%s: %d;" ,pfx (lvl), pad_type, + in_bitfield ? new_off - cur_off :0 ); + cur_off = new_off; + } + +/* Now we know we start at naturally aligned offset for a chosen +* padding type (long, int, short, or char), and so the rest is just +* a straightforward filling of remaining padding gap with full +* `<type>: sizeof(<type>);` markers, except for the last one, which +* might need smaller than sizeof(<type>) padding. +*/ +while (cur_off != next_off) { + bits =min (next_off - cur_off, pad_bits); +if (bits == pad_bits) { +btf_dump_printf (d,"\n%s%s: %d;" ,pfx (lvl), pad_type, pad_bits); + cur_off += bits; +continue ; + } +/* For the remainder padding that doesn't cover entire +* pad_type bit length, we pick the smallest necessary type. +* This is pure aesthetics, we could have just used `long`, +* but having smallest necessary one communicates better the +* scale of the padding gap. +*/ +for (i =ARRAY_SIZE (pads) -1 ; i >=0 ; i--) { + pad_type = pads[i].name; + pad_bits = pads[i].bits; +if (pad_bits < bits) +continue ; + +btf_dump_printf (d,"\n%s%s: %d;" ,pfx (lvl), pad_type, bits); + cur_off += bits; +break ; } -btf_dump_printf (d,"\n%s%s: %d;" ,pfx (lvl), pad_type, pad_bits); - off_diff -= pad_bits; } }
@@ -873,9 +945,11 @@ static void btf_dump_emit_struct_def(struct btf_dump *d, {const struct btf_member *m =btf_members (t);bool is_struct =btf_is_struct (t); -int align, i, packed, off =0 ; +bool packed, prev_bitfield = false; +int align, i, off =0 ;__u16 vlen =btf_vlen (t); + align =btf__align_of (d->btf, id); packed = is_struct ?btf_is_struct_packed (d->btf, id, t) :0 ; btf_dump_printf(d, "%s%s%s {",
@@ -885,33 +959,36 @@ static void btf_dump_emit_struct_def(struct btf_dump *d,for (i =0 ; i < vlen; i++, m++) {const char *fname; -int m_off, m_sz; +int m_off, m_sz, m_align; +bool in_bitfield; fname =btf_name_of (d, m->name_off); m_sz =btf_member_bitfield_size (t, i); m_off =btf_member_bit_offset (t, i); - align = packed ?1 :btf__align_of (d->btf, m->type); + m_align = packed ?1 :btf__align_of (d->btf, m->type); -btf_dump_emit_bit_padding (d, off, m_off, m_sz, align, lvl +1 ); + in_bitfield = prev_bitfield && m_sz !=0 ; + +btf_dump_emit_bit_padding (d, off, m_off, m_align, in_bitfield, lvl +1 );btf_dump_printf (d,"\n%s" ,pfx (lvl +1 ));btf_dump_emit_type_decl (d, m->type, fname, lvl +1 );if (m_sz) {btf_dump_printf (d,": %d" , m_sz); off = m_off + m_sz; + prev_bitfield = true; }else { m_sz =max ((__s64 )0 ,btf__resolve_size (d->btf, m->type)); off = m_off + m_sz *8 ; + prev_bitfield = false; } +btf_dump_printf (d,";" ); }/* pad at the end, if necessary */ -if (is_struct) { - align = packed ?1 :btf__align_of (d->btf, id); -btf_dump_emit_bit_padding (d, off, t->size *8 ,0 , align, - lvl +1 ); - } +if (is_struct) +btf_dump_emit_bit_padding (d, off, t->size *8 , align, false, lvl +1 );if (vlen)btf_dump_printf (d,"\n" );
tools/testing/selftests/bpf/progs/btf_dump_test_case_bitfields.c +1 -1
@@ -53,7 +53,7 @@ struct bitfields_only_mixed_types {*/ /* ------ END-EXPECTED-OUTPUT ------ */ struct bitfield_mixed_with_others { - long: 4; /* char is enough as a backing field */ + char: 4; /* char is enough as a backing field */int a:4 ;/* 8-bit implicit padding */ short b;/* combined with previous bitfield */
tools/testing/selftests/bpf/progs/btf_dump_test_case_padding.c +40 -18
107 lines not on this page · raw message
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 169/173 selftests/bpf: Add few corner cases to test padding handling of btf_dump
In reply to Greg Kroah-HartmanFrom: Andrii Nakryiko <[email protected]>
[ Upstream commit b148c8b9b926e257a59c8eb2cd6fa3adfd443254 ]
Add few hand-crafted cases and few randomized cases found using script from [0] that tests btf_dump's padding logic.
[0] https://lore.kernel.org/bpf/[email protected]/
Stable-dep-of: 4fb877aaa179 ("libbpf: Fix btf_dump's packed struct determination")
--- .../bpf/progs/btf_dump_test_case_packing.c | 61 +++++++++- .../bpf/progs/btf_dump_test_case_padding.c | 104 ++++++++++++++++++ 2 files changed, 164 insertions(+), 1 deletion(-)
tools/testing/selftests/bpf/progs/btf_dump_test_case_packing.c +60 -1
@@ -58,7 +58,64 @@ union jump_code_union { } __attribute__((packed)); }; -/*------ END-EXPECTED-OUTPUT ------ */ +/* ----- START-EXPECTED-OUTPUT ----- */ +/* +*struct nested_packed_but_aligned_struct { +* int x1; +* int x2; +*}; +* +*struct outer_implicitly_packed_struct { +* char y1; +* struct nested_packed_but_aligned_struct y2; +*} __attribute__((packed)); +* +*/ +/* ------ END-EXPECTED-OUTPUT ------ */ + +struct nested_packed_but_aligned_struct { +int x1; +int x2; +} __attribute__((packed)); + +struct outer_implicitly_packed_struct { +char y1; +struct nested_packed_but_aligned_struct y2; +}; +/* ----- START-EXPECTED-OUTPUT ----- */ +/* +*struct usb_ss_ep_comp_descriptor { +* char: 8; +* char bDescriptorType; +* char bMaxBurst; +* short wBytesPerInterval; +*}; +* +*struct usb_host_endpoint { +* long: 64; +* char: 8; +* struct usb_ss_ep_comp_descriptor ss_ep_comp; +* long: 0; +*} __attribute__((packed)); +* +*/ +/* ------ END-EXPECTED-OUTPUT ------ */ + +struct usb_ss_ep_comp_descriptor { + char: 8; +char bDescriptorType; +char bMaxBurst; + int: 0; +short wBytesPerInterval; +} __attribute__((packed)); + +struct usb_host_endpoint { + long: 64; + char: 8; +struct usb_ss_ep_comp_descriptor ss_ep_comp; + long: 0; +}; + int f(struct { struct packed_trailing_space _1;
@@ -69,6 +126,8 @@ int f(struct {union union_is_never_packed _6;union union_does_not_need_packing _7;union jump_code_union _8; +struct outer_implicitly_packed_struct _9; +struct usb_host_endpoint _10; } *_) {return 0 ;
tools/testing/selftests/bpf/progs/btf_dump_test_case_padding.c +104 -0
116 lines not on this page · raw message
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 170/173 libbpf: Fix btf_dumps packed struct determination
In reply to Greg Kroah-HartmanFrom: Andrii Nakryiko <[email protected]>
[ Upstream commit 4fb877aaa179dcdb1676d55216482febaada457e ]
Fix bug in btf_dump's logic of determining if a given struct type is packed or not. The notion of "natural alignment" is not needed and is even harmful in this case, so drop it altogether. The biggest difference in btf_is_struct_packed() compared to its original implementation is that we don't really use btf__align_of() to determine overall alignment of a struct type (because it could be 1 for both packed and non-packed struct, depending on specifci field definitions), and just use field's actual alignment to calculate whether any field is requiring packing or struct's size overall necessitates packing.
Add two simple test cases that demonstrate the difference this change would make.
--- tools/lib/bpf/btf_dump.c | 33 ++++--------------- .../bpf/progs/btf_dump_test_case_packing.c | 19 +++++++++++ 2 files changed, 25 insertions(+), 27 deletions(-)
tools/lib/bpf/btf_dump.c +6 -27
@@ -788,47 +788,26 @@ static void btf_dump_emit_type(struct btf_dump *d, __u32 id, __u32 cont_id) } } -static int btf_natural_align_of (const struct btf *btf,__u32 id) -{ -const struct btf_type *t =btf__type_by_id (btf, id); -int i, align, vlen; -const struct btf_member *m; - -if (!btf_is_composite (t)) -return btf__align_of (btf, id); - - align =1 ; - m =btf_members (t); - vlen =btf_vlen (t); -for (i =0 ; i < vlen; i++, m++) { - align =max (align,btf__align_of (btf, m->type)); - } - -return align; -} -static bool btf_is_struct_packed (const struct btf *btf,__u32 id,const struct btf_type *t) {const struct btf_member *m; -int align, i, bit_sz; +int max_align =1 , align, i, bit_sz;__u16 vlen; - align =btf_natural_align_of (btf, id); -/* size of a non-packed struct has to be a multiple of its alignment */ -if (align && (t->size % align) !=0 ) -return true; - m =btf_members (t); vlen =btf_vlen (t);/* all non-bitfield fields have to be naturally aligned */ for (i =0 ; i < vlen; i++, m++) { - align =btf_natural_align_of (btf, m->type); + align =btf__align_of (btf, m->type); bit_sz =btf_member_bitfield_size (t, i);if (align && bit_sz ==0 && m->offset % (8 * align) !=0 )return true; + max_align =max (align, max_align); } - +/* size of a non-packed struct has to be a multiple of its alignment */ +if (t->size % max_align !=0 ) +return true;/* * if original struct was marked as packed, but its layout is * naturally aligned, we'll detect that it's not packed
tools/testing/selftests/bpf/progs/btf_dump_test_case_packing.c +19 -0
@@ -116,6 +116,23 @@ struct usb_host_endpoint { long: 0; }; +/* ----- START-EXPECTED-OUTPUT ----- */ +struct nested_packed_struct { +int a; +char b; +} __attribute__((packed)); + +struct outer_nonpacked_struct { +short a; +struct nested_packed_struct b; +}; + +struct outer_packed_struct { +short a; +struct nested_packed_struct b; +} __attribute__((packed)); + +/* ------ END-EXPECTED-OUTPUT ------ */ int f(struct { struct packed_trailing_space _1;
@@ -128,6 +145,8 @@ int f(struct {union jump_code_union _8;struct outer_implicitly_packed_struct _9;struct usb_host_endpoint _10; +struct outer_nonpacked_struct _11; +struct outer_packed_struct _12; } *_) {return 0 ;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 171/173 ext4: fix kernel BUG in ext4_write_inline_data_end()
In reply to Greg Kroah-HartmanFrom: Ye Bin <[email protected]>
commit 5c099c4fdc438014d5893629e70a8ba934433ee8 upstream.
Syzbot report follow issue:
------------[ cut here ]------------ kernel BUG at fs/ext4/inline.c:227! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 3629 Comm: syz-executor212 Not tainted 6.1.0-rc5-syzkaller-00018-g59d0d52c30d4 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:ext4_write_inline_data+0x344/0x3e0 fs/ext4/inline.c:227 RSP: 0018:ffffc90003b3f368 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8880704e16c0 RCX: 0000000000000000 RDX: ffff888021763a80 RSI: ffffffff821e31a4 RDI: 0000000000000006 RBP: 000000000006818e R08: 0000000000000006 R09: 0000000000068199 R10: 0000000000000079 R11: 0000000000000000 R12: 000000000000000b R13: 0000000000068199 R14: ffffc90003b3f408 R15: ffff8880704e1c82 FS: 000055555723e3c0(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fffe8ac9080 CR3: 0000000079f81000 CR4: 0000000000350ee0 Call Trace: <TASK> ext4_write_inline_data_end+0x2a3/0x12f0 fs/ext4/inline.c:768 ext4_write_end+0x242/0xdd0 fs/ext4/inode.c:1313 ext4_da_write_end+0x3ed/0xa30 fs/ext4/inode.c:3063 generic_perform_write+0x316/0x570 mm/filemap.c:3764 ext4_buffered_write_iter+0x15b/0x460 fs/ext4/file.c:285 ext4_file_write_iter+0x8bc/0x16e0 fs/ext4/file.c:700 call_write_iter include/linux/fs.h:2191 [inline] do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735 do_iter_write+0x182/0x700 fs/read_write.c:861 vfs_iter_write+0x74/0xa0 fs/read_write.c:902 iter_file_splice_write+0x745/0xc90 fs/splice.c:686 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x114/0x180 fs/splice.c:931 splice_direct_to_actor+0x335/0x8a0 fs/splice.c:886 do_splice_direct+0x1ab/0x280 fs/splice.c:974 do_sendfile+0xb19/0x1270 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1d0/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ---[ end trace 0000000000000000 ]---
Above issue may happens as follows:ext4_da_write_begin
ext4_da_write_inline_data_begin
ext4_da_convert_inline_data_to_extent
ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA);ext4_da_write_end
ext4_run_li_request
ext4_mb_prefetch
ext4_read_block_bitmap_nowait
ext4_validate_block_bitmap
ext4_mark_group_bitmap_corrupted(sb, block_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT)
percpu_counter_sub(&sbi->s_freeclusters_counter,grp->bb_free);
-> sbi->s_freeclusters_counter become zero
ext4_da_write_begin
if (ext4_nonda_switch(inode->i_sb)) -> As freeclusters_counter is zero will return true
*fsdata = (void *)FALL_BACK_TO_NONDELALLOC;
ext4_write_begin
ext4_da_write_end
if (write_mode == FALL_BACK_TO_NONDELALLOC)
ext4_write_end
if (inline_data)
ext4_write_inline_data_end
ext4_write_inline_data
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
-> As inode is already convert to extent, so 'pos + len' > inline_size
-> then trigger BUG.To solve this issue, instead of checking ext4_has_inline_data() which is only cleared after data has been written back, check the EXT4_STATE_MAY_INLINE_DATA flag in ext4_write_end().
[ta: Fix conflict in if expression and use the local variable inline_data as it is initialized with ext4_has_inline_data(inode) anyway.]
--- fs/ext4/inode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/ext4/inode.c +2 -1
@@ -1303,7 +1303,8 @@ static int ext4_write_end(struct file *fbool verity =ext4_verity_in_progress (inode);trace_ext4_write_end (inode, pos, len, copied); -if (inline_data) { +if (inline_data && +ext4_test_inode_state (inode,EXT4_STATE_MAY_INLINE_DATA )) { ret =ext4_write_inline_data_end (inode, pos, len, copied, page);if (ret <0 ) {
Greg Kroah-Hartman
maintainerPATCH 172/173 gfs2: Always check inode size of inline inodes
In reply to Greg Kroah-HartmanFrom: Andreas Gruenbacher <[email protected]>
commit 70376c7ff31221f1d21db5611d8209e677781d3a upstream.
Check if the inode size of stuffed (inline) inodes is within the allowed range when reading inodes from disk (gfs2_dinode_in()). This prevents us from on-disk corruption.
The two checks in stuffed_readpage() and gfs2_unstuffer_page() that just truncate inline data to the maximum allowed size don't actually make sense, and they can be removed now as well.
[[email protected]: adjust the inode variable inside gfs2_dinode_in with the format used before upstream commit 7db354444ad8 ("gfs2: Cosmetic gfs2_dinode_{in,out} cleanup")]
--- fs/gfs2/aops.c | 2 -- fs/gfs2/bmap.c | 3 --- fs/gfs2/glops.c | 3 +++ 3 files changed, 3 insertions(+), 5 deletions(-)
fs/gfs2/aops.c +0 -2
@@ -451,8 +451,6 @@ static int stuffed_readpage(struct gfs2_return error; kaddr =kmap_atomic (page); -if (dsize >gfs2_max_stuffed_size (ip)) - dsize =gfs2_max_stuffed_size (ip);memcpy (kaddr, dibh->b_data +sizeof (struct gfs2_dinode ), dsize);memset (kaddr + dsize,0 ,PAGE_SIZE - dsize);kunmap_atomic (kaddr);
fs/gfs2/bmap.c +0 -3
@@ -69,9 +69,6 @@ static int gfs2_unstuffer_page(struct gfvoid *kaddr =kmap (page);u64 dsize =i_size_read (inode); -if (dsize >gfs2_max_stuffed_size (ip)) - dsize =gfs2_max_stuffed_size (ip); -memcpy (kaddr, dibh->b_data +sizeof (struct gfs2_dinode ), dsize);memset (kaddr + dsize,0 ,PAGE_SIZE - dsize);kunmap (page);
fs/gfs2/glops.c +3 -0
@@ -454,6 +454,9 @@ static int gfs2_dinode_in(struct gfs2_in ip->i_depth = (u8 )depth; ip->i_entries =be32_to_cpu (str->di_entries); +if (gfs2_is_stuffed (ip) && ip->i_inode.i_size >gfs2_max_stuffed_size (ip)) + goto corrupt; +if (S_ISREG (ip->i_inode.i_mode))gfs2_set_aops (&ip->i_inode);
Greg Kroah-Hartman
maintainerPATCH 173/173 hsr: ratelimit only when errors are printed
In reply to Greg Kroah-HartmanFrom: Matthieu Baerts <[email protected]>
commit 1b0120e4db0bf2838d1ce741195ce4b7cc100b91 upstream.
Recently, when automatically merging -net and net-next in MPTCP devel tree, our CI reported [1] a conflict in hsr, the same as the one reported by Stephen in netdev [2].
When looking at the conflict, I noticed it is in fact the v1 [3] that has been applied in -net and the v2 [4] in net-next. Maybe the v1 was applied by accident.
As mentioned by Jakub Kicinski [5], the new condition makes more sense before the net_ratelimit(), not to update net_ratelimit's state which is unnecessary if we're not going to print either way.
Here, this modification applies the v2 but in -net.
--- net/hsr/hsr_framereg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/hsr/hsr_framereg.c +1 -1
@@ -380,7 +380,7 @@ void hsr_addr_subst_dest(struct hsr_node node_dst =find_node_by_addr_A (&port->hsr->node_db,eth_hdr (skb)->h_dest);if (!node_dst) { -if (net_ratelimit () && port->hsr->prot_version !=PRP_V1 ) +if (port->hsr->prot_version !=PRP_V1 &&net_ratelimit ())netdev_err (skb->dev,"%s: Unknown node\n" , __func__);return ; }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.177 release. There are 173 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 Wed, 05 Apr 2023 14:03:18 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.177-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.177 release. There are 173 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 Wed, 05 Apr 2023 14:03:18 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.177-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.177 release. There are 173 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 Wed, 05 Apr 2023 14:03:18 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.177-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.10.177-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: 7d617ad89b616010f8233d54ae9d5623cbb91b41
* git describe: v5.10.176-174-g7d617ad89b61
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.176-174-g7d617ad89b61
## Test Regressions (compared to v5.10.176)
## Metric Regressions (compared to v5.10.176)
## Test Fixes (compared to v5.10.176)
## Metric Fixes (compared to v5.10.176)
## Test result summary
total: 126510, pass: 104809, fail: 3271, skip: 18206, xfail: 224
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 115 total, 114 passed, 1 failed
* arm64: 43 total, 40 passed, 3 failed
* i386: 33 total, 31 passed, 2 failed
* mips: 27 total, 26 passed, 1 failed
* parisc: 8 total, 8 passed, 0 failed
* powerpc: 26 total, 20 passed, 6 failed
* riscv: 12 total, 11 passed, 1 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 14 total, 12 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 36 total, 34 passed, 2 failed
## Test suites summary
* boot
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.177 release. There are 173 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 Wed, 05 Apr 2023 14:03:18 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.177-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.10:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
75 tests: 75 pass, 0 failLinux version: 5.10.177-rc1-g7d617ad89b61
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Hello Greg,
Quoted 10 lines
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, April 3, 2023 3:07 PMThis is the start of the stable review cycle for the 5.10.177 release. There are 173 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 Wed, 05 Apr 2023 14:03:18 +0000. Anything received after that time might be too late.
CIP configurations built and booted with Linux 5.10.177-rc1 (7d617ad89b61):
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/826566309
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/commits/linux-5.10.y
Kind regards, Chris
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.177 release. There are 173 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 Wed, 05 Apr 2023 14:03:18 +0000. Anything received after that time might be too late.
Build results:
total: 162 pass: 162 fail: 0 Qemu test results: total: 485 pass: 485 fail: 0
Guenter