October 2021 - Linux-stable-mirror

FAILED: patch "[PATCH] ext4: fix reserved space counter leakage" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 6fed83957f21eff11c8496e9f24253b03d2bc1dc Mon Sep 17 00:00:00 2001 From: Jeffle Xu <jefflexu(a)linux.alibaba.com> Date: Mon, 23 Aug 2021 14:13:58 +0800 Subject: [PATCH] ext4: fix reserved space counter leakage When ext4_insert_delayed block receives and recovers from an error from ext4_es_insert_delayed_block(), e.g., ENOMEM, it does not release the space it has reserved for that block insertion as it should. One effect of this bug is that s_dirtyclusters_counter is not decremented and remains incorrectly elevated until the file system has been unmounted. This can result in premature ENOSPC returns and apparent loss of free space. Another effect of this bug is that /sys/fs/ext4/<dev>/delayed_allocation_blocks can remain non-zero even after syncfs has been executed on the filesystem. Besides, add check for s_dirtyclusters_counter when inode is going to be evicted and freed. s_dirtyclusters_counter can still keep non-zero until inode is written back in .evict_inode(), and thus the check is delayed to .destroy_inode(). Fixes: 51865fda28e5 ("ext4: let ext4 maintain extent status tree") Cc: stable(a)kernel.org Suggested-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Signed-off-by: Jeffle Xu <jefflexu(a)linux.alibaba.com> Reviewed-by: Eric Whitney <enwlinux(a)gmail.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Link: https://lore.kernel.org/r/20210823061358.84473-1-jefflexu@linux.alibaba.com diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 2a076d236ba1..9df1ab070fa5 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1628,6 +1628,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb); int ret; bool allocated = false; + bool reserved = false; /* * If the cluster containing lblk is shared with a delayed, @@ -1644,6 +1645,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) ret = ext4_da_reserve_space(inode); if (ret != 0) /* ENOSPC */ goto errout; + reserved = true; } else { /* bigalloc */ if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) { if (!ext4_es_scan_clu(inode, @@ -1656,6 +1658,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) ret = ext4_da_reserve_space(inode); if (ret != 0) /* ENOSPC */ goto errout; + reserved = true; } else { allocated = true; } @@ -1666,6 +1669,8 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) } ret = ext4_es_insert_delayed_block(inode, lblk, allocated); + if (ret && reserved) + ext4_da_release_space(inode, 1); errout: return ret; diff --git a/fs/ext4/super.c b/fs/ext4/super.c index feca816b6bf3..a52f1572daa5 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1352,6 +1352,12 @@ static void ext4_destroy_inode(struct inode *inode) true); dump_stack(); } + + if (EXT4_I(inode)->i_reserved_data_blocks) + ext4_msg(inode->i_sb, KERN_ERR, + "Inode %lu (%p): i_reserved_data_blocks (%u) not cleared!", + inode->i_ino, EXT4_I(inode), + EXT4_I(inode)->i_reserved_data_blocks); } static void init_once(void *foo)

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ext4: fix reserved space counter leakage" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 6fed83957f21eff11c8496e9f24253b03d2bc1dc Mon Sep 17 00:00:00 2001 From: Jeffle Xu <jefflexu(a)linux.alibaba.com> Date: Mon, 23 Aug 2021 14:13:58 +0800 Subject: [PATCH] ext4: fix reserved space counter leakage When ext4_insert_delayed block receives and recovers from an error from ext4_es_insert_delayed_block(), e.g., ENOMEM, it does not release the space it has reserved for that block insertion as it should. One effect of this bug is that s_dirtyclusters_counter is not decremented and remains incorrectly elevated until the file system has been unmounted. This can result in premature ENOSPC returns and apparent loss of free space. Another effect of this bug is that /sys/fs/ext4/<dev>/delayed_allocation_blocks can remain non-zero even after syncfs has been executed on the filesystem. Besides, add check for s_dirtyclusters_counter when inode is going to be evicted and freed. s_dirtyclusters_counter can still keep non-zero until inode is written back in .evict_inode(), and thus the check is delayed to .destroy_inode(). Fixes: 51865fda28e5 ("ext4: let ext4 maintain extent status tree") Cc: stable(a)kernel.org Suggested-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Signed-off-by: Jeffle Xu <jefflexu(a)linux.alibaba.com> Reviewed-by: Eric Whitney <enwlinux(a)gmail.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Link: https://lore.kernel.org/r/20210823061358.84473-1-jefflexu@linux.alibaba.com diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 2a076d236ba1..9df1ab070fa5 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1628,6 +1628,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb); int ret; bool allocated = false; + bool reserved = false; /* * If the cluster containing lblk is shared with a delayed, @@ -1644,6 +1645,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) ret = ext4_da_reserve_space(inode); if (ret != 0) /* ENOSPC */ goto errout; + reserved = true; } else { /* bigalloc */ if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) { if (!ext4_es_scan_clu(inode, @@ -1656,6 +1658,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) ret = ext4_da_reserve_space(inode); if (ret != 0) /* ENOSPC */ goto errout; + reserved = true; } else { allocated = true; } @@ -1666,6 +1669,8 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) } ret = ext4_es_insert_delayed_block(inode, lblk, allocated); + if (ret && reserved) + ext4_da_release_space(inode, 1); errout: return ret; diff --git a/fs/ext4/super.c b/fs/ext4/super.c index feca816b6bf3..a52f1572daa5 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1352,6 +1352,12 @@ static void ext4_destroy_inode(struct inode *inode) true); dump_stack(); } + + if (EXT4_I(inode)->i_reserved_data_blocks) + ext4_msg(inode->i_sb, KERN_ERR, + "Inode %lu (%p): i_reserved_data_blocks (%u) not cleared!", + inode->i_ino, EXT4_I(inode), + EXT4_I(inode)->i_reserved_data_blocks); } static void init_once(void *foo)

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ext4: fix reserved space counter leakage" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 6fed83957f21eff11c8496e9f24253b03d2bc1dc Mon Sep 17 00:00:00 2001 From: Jeffle Xu <jefflexu(a)linux.alibaba.com> Date: Mon, 23 Aug 2021 14:13:58 +0800 Subject: [PATCH] ext4: fix reserved space counter leakage When ext4_insert_delayed block receives and recovers from an error from ext4_es_insert_delayed_block(), e.g., ENOMEM, it does not release the space it has reserved for that block insertion as it should. One effect of this bug is that s_dirtyclusters_counter is not decremented and remains incorrectly elevated until the file system has been unmounted. This can result in premature ENOSPC returns and apparent loss of free space. Another effect of this bug is that /sys/fs/ext4/<dev>/delayed_allocation_blocks can remain non-zero even after syncfs has been executed on the filesystem. Besides, add check for s_dirtyclusters_counter when inode is going to be evicted and freed. s_dirtyclusters_counter can still keep non-zero until inode is written back in .evict_inode(), and thus the check is delayed to .destroy_inode(). Fixes: 51865fda28e5 ("ext4: let ext4 maintain extent status tree") Cc: stable(a)kernel.org Suggested-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Signed-off-by: Jeffle Xu <jefflexu(a)linux.alibaba.com> Reviewed-by: Eric Whitney <enwlinux(a)gmail.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Link: https://lore.kernel.org/r/20210823061358.84473-1-jefflexu@linux.alibaba.com diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 2a076d236ba1..9df1ab070fa5 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1628,6 +1628,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb); int ret; bool allocated = false; + bool reserved = false; /* * If the cluster containing lblk is shared with a delayed, @@ -1644,6 +1645,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) ret = ext4_da_reserve_space(inode); if (ret != 0) /* ENOSPC */ goto errout; + reserved = true; } else { /* bigalloc */ if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) { if (!ext4_es_scan_clu(inode, @@ -1656,6 +1658,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) ret = ext4_da_reserve_space(inode); if (ret != 0) /* ENOSPC */ goto errout; + reserved = true; } else { allocated = true; } @@ -1666,6 +1669,8 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) } ret = ext4_es_insert_delayed_block(inode, lblk, allocated); + if (ret && reserved) + ext4_da_release_space(inode, 1); errout: return ret; diff --git a/fs/ext4/super.c b/fs/ext4/super.c index feca816b6bf3..a52f1572daa5 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1352,6 +1352,12 @@ static void ext4_destroy_inode(struct inode *inode) true); dump_stack(); } + + if (EXT4_I(inode)->i_reserved_data_blocks) + ext4_msg(inode->i_sb, KERN_ERR, + "Inode %lu (%p): i_reserved_data_blocks (%u) not cleared!", + inode->i_ino, EXT4_I(inode), + EXT4_I(inode)->i_reserved_data_blocks); } static void init_once(void *foo)

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ext4: fix loff_t overflow in ext4_max_bitmap_size()" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 75ca6ad408f459f00b09a64f04c774559848c097 Mon Sep 17 00:00:00 2001 From: Ritesh Harjani <riteshh(a)linux.ibm.com> Date: Sat, 5 Jun 2021 10:39:32 +0530 Subject: [PATCH] ext4: fix loff_t overflow in ext4_max_bitmap_size() We should use unsigned long long rather than loff_t to avoid overflow in ext4_max_bitmap_size() for comparison before returning. w/o this patch sbi->s_bitmap_maxbytes was becoming a negative value due to overflow of upper_limit (with has_huge_files as true) Below is a quick test to trigger it on a 64KB pagesize system. sudo mkfs.ext4 -b 65536 -O ^has_extents,^64bit /dev/loop2 sudo mount /dev/loop2 /mnt sudo echo "hello" > /mnt/hello -> This will error out with "echo: write error: File too large" Signed-off-by: Ritesh Harjani <riteshh(a)linux.ibm.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)kernel.org Link: https://lore.kernel.org/r/594f409e2c543e90fd836b78188dfa5c575065ba.16228675… Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/super.c b/fs/ext4/super.c index a52f1572daa5..9b5b2f63b470 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3030,17 +3030,17 @@ static loff_t ext4_max_size(int blkbits, int has_huge_files) */ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) { - loff_t res = EXT4_NDIR_BLOCKS; + unsigned long long upper_limit, res = EXT4_NDIR_BLOCKS; int meta_blocks; - loff_t upper_limit; - /* This is calculated to be the largest file size for a dense, block + + /* + * This is calculated to be the largest file size for a dense, block * mapped file such that the file's total number of 512-byte sectors, * including data and all indirect blocks, does not exceed (2^48 - 1). * * __u32 i_blocks_lo and _u16 i_blocks_high represent the total * number of 512-byte sectors of the file. */ - if (!has_huge_files) { /* * !has_huge_files or implies that the inode i_block field @@ -3083,7 +3083,7 @@ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) if (res > MAX_LFS_FILESIZE) res = MAX_LFS_FILESIZE; - return res; + return (loff_t)res; } static ext4_fsblk_t descriptor_loc(struct super_block *sb,

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ext4: fix loff_t overflow in ext4_max_bitmap_size()" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 75ca6ad408f459f00b09a64f04c774559848c097 Mon Sep 17 00:00:00 2001 From: Ritesh Harjani <riteshh(a)linux.ibm.com> Date: Sat, 5 Jun 2021 10:39:32 +0530 Subject: [PATCH] ext4: fix loff_t overflow in ext4_max_bitmap_size() We should use unsigned long long rather than loff_t to avoid overflow in ext4_max_bitmap_size() for comparison before returning. w/o this patch sbi->s_bitmap_maxbytes was becoming a negative value due to overflow of upper_limit (with has_huge_files as true) Below is a quick test to trigger it on a 64KB pagesize system. sudo mkfs.ext4 -b 65536 -O ^has_extents,^64bit /dev/loop2 sudo mount /dev/loop2 /mnt sudo echo "hello" > /mnt/hello -> This will error out with "echo: write error: File too large" Signed-off-by: Ritesh Harjani <riteshh(a)linux.ibm.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)kernel.org Link: https://lore.kernel.org/r/594f409e2c543e90fd836b78188dfa5c575065ba.16228675… Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/super.c b/fs/ext4/super.c index a52f1572daa5..9b5b2f63b470 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3030,17 +3030,17 @@ static loff_t ext4_max_size(int blkbits, int has_huge_files) */ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) { - loff_t res = EXT4_NDIR_BLOCKS; + unsigned long long upper_limit, res = EXT4_NDIR_BLOCKS; int meta_blocks; - loff_t upper_limit; - /* This is calculated to be the largest file size for a dense, block + + /* + * This is calculated to be the largest file size for a dense, block * mapped file such that the file's total number of 512-byte sectors, * including data and all indirect blocks, does not exceed (2^48 - 1). * * __u32 i_blocks_lo and _u16 i_blocks_high represent the total * number of 512-byte sectors of the file. */ - if (!has_huge_files) { /* * !has_huge_files or implies that the inode i_block field @@ -3083,7 +3083,7 @@ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) if (res > MAX_LFS_FILESIZE) res = MAX_LFS_FILESIZE; - return res; + return (loff_t)res; } static ext4_fsblk_t descriptor_loc(struct super_block *sb,

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ext4: fix loff_t overflow in ext4_max_bitmap_size()" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 75ca6ad408f459f00b09a64f04c774559848c097 Mon Sep 17 00:00:00 2001 From: Ritesh Harjani <riteshh(a)linux.ibm.com> Date: Sat, 5 Jun 2021 10:39:32 +0530 Subject: [PATCH] ext4: fix loff_t overflow in ext4_max_bitmap_size() We should use unsigned long long rather than loff_t to avoid overflow in ext4_max_bitmap_size() for comparison before returning. w/o this patch sbi->s_bitmap_maxbytes was becoming a negative value due to overflow of upper_limit (with has_huge_files as true) Below is a quick test to trigger it on a 64KB pagesize system. sudo mkfs.ext4 -b 65536 -O ^has_extents,^64bit /dev/loop2 sudo mount /dev/loop2 /mnt sudo echo "hello" > /mnt/hello -> This will error out with "echo: write error: File too large" Signed-off-by: Ritesh Harjani <riteshh(a)linux.ibm.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)kernel.org Link: https://lore.kernel.org/r/594f409e2c543e90fd836b78188dfa5c575065ba.16228675… Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/super.c b/fs/ext4/super.c index a52f1572daa5..9b5b2f63b470 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3030,17 +3030,17 @@ static loff_t ext4_max_size(int blkbits, int has_huge_files) */ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) { - loff_t res = EXT4_NDIR_BLOCKS; + unsigned long long upper_limit, res = EXT4_NDIR_BLOCKS; int meta_blocks; - loff_t upper_limit; - /* This is calculated to be the largest file size for a dense, block + + /* + * This is calculated to be the largest file size for a dense, block * mapped file such that the file's total number of 512-byte sectors, * including data and all indirect blocks, does not exceed (2^48 - 1). * * __u32 i_blocks_lo and _u16 i_blocks_high represent the total * number of 512-byte sectors of the file. */ - if (!has_huge_files) { /* * !has_huge_files or implies that the inode i_block field @@ -3083,7 +3083,7 @@ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) if (res > MAX_LFS_FILESIZE) res = MAX_LFS_FILESIZE; - return res; + return (loff_t)res; } static ext4_fsblk_t descriptor_loc(struct super_block *sb,

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ext4: fix loff_t overflow in ext4_max_bitmap_size()" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 75ca6ad408f459f00b09a64f04c774559848c097 Mon Sep 17 00:00:00 2001 From: Ritesh Harjani <riteshh(a)linux.ibm.com> Date: Sat, 5 Jun 2021 10:39:32 +0530 Subject: [PATCH] ext4: fix loff_t overflow in ext4_max_bitmap_size() We should use unsigned long long rather than loff_t to avoid overflow in ext4_max_bitmap_size() for comparison before returning. w/o this patch sbi->s_bitmap_maxbytes was becoming a negative value due to overflow of upper_limit (with has_huge_files as true) Below is a quick test to trigger it on a 64KB pagesize system. sudo mkfs.ext4 -b 65536 -O ^has_extents,^64bit /dev/loop2 sudo mount /dev/loop2 /mnt sudo echo "hello" > /mnt/hello -> This will error out with "echo: write error: File too large" Signed-off-by: Ritesh Harjani <riteshh(a)linux.ibm.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)kernel.org Link: https://lore.kernel.org/r/594f409e2c543e90fd836b78188dfa5c575065ba.16228675… Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/super.c b/fs/ext4/super.c index a52f1572daa5..9b5b2f63b470 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3030,17 +3030,17 @@ static loff_t ext4_max_size(int blkbits, int has_huge_files) */ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) { - loff_t res = EXT4_NDIR_BLOCKS; + unsigned long long upper_limit, res = EXT4_NDIR_BLOCKS; int meta_blocks; - loff_t upper_limit; - /* This is calculated to be the largest file size for a dense, block + + /* + * This is calculated to be the largest file size for a dense, block * mapped file such that the file's total number of 512-byte sectors, * including data and all indirect blocks, does not exceed (2^48 - 1). * * __u32 i_blocks_lo and _u16 i_blocks_high represent the total * number of 512-byte sectors of the file. */ - if (!has_huge_files) { /* * !has_huge_files or implies that the inode i_block field @@ -3083,7 +3083,7 @@ static loff_t ext4_max_bitmap_size(int bits, int has_huge_files) if (res > MAX_LFS_FILESIZE) res = MAX_LFS_FILESIZE; - return res; + return (loff_t)res; } static ext4_fsblk_t descriptor_loc(struct super_block *sb,

2 years, 8 months

1
0
0 0

[PATCH] xhci: Fix command ring pointer corruption while aborting a command

by Pavankumar Kondeti

The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. Since we split the 64 bit write into two 32 bit writes, there is a possibility of xHC command ring stopped before the upper dword (all zeros) is written. If that happens, xHC updates the upper dword of its internal command ring pointer with all zeros. Next time, when the command ring is restarted, we see xHC memory access failures. Fix this issue by only writing to the lower dword of CRCR where all control bits are located. Signed-off-by: Pavankumar Kondeti <pkondeti(a)codeaurora.org> --- drivers/usb/host/xhci-ring.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index e676749..3c8456b 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -366,16 +366,22 @@ static void xhci_handle_stopped_cmd_ring(struct xhci_hcd *xhci, /* Must be called with xhci->lock held, releases and aquires lock back */ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci, unsigned long flags) { - u64 temp_64; + u64 temp_32; int ret; xhci_dbg(xhci, "Abort command ring\n"); reinit_completion(&xhci->cmd_ring_stop_completion); - temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring); - xhci_write_64(xhci, temp_64 | CMD_RING_ABORT, - &xhci->op_regs->cmd_ring); + /* + * The control bits like command stop, abort are located in lower + * dword of the command ring control register. Limit the write + * to the lower dword to avoid corrupting the command ring pointer + * in case if the command ring is stopped by the time upper dword + * is written. + */ + temp_32 = readl(&xhci->op_regs->cmd_ring); + writel(temp_32 | CMD_RING_ABORT, &xhci->op_regs->cmd_ring); /* Section 4.6.1.2 of xHCI 1.0 spec says software should also time the * completion of the Command Abort operation. If CRR is not negated in 5 -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

2 years, 8 months

2
3
0 0

stable-rc/queue/5.14 baseline: 204 runs, 3 regressions (v5.14.9-73-gb9d08ffadf94)

by kernelci.org bot

stable-rc/queue/5.14 baseline: 204 runs, 3 regressions (v5.14.9-73-gb9d08ffadf94) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ------------------------+-------+--------------+----------+---------------------+------------ beagle-xm | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 beagle-xm | arm | lab-baylibre | gcc-8 | omap2plus_defconfig | 1 sun50i-a64-bananapi-m64 | arm64 | lab-clabbe | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.14/kernel/v5.14.9-… Test: baseline Tree: stable-rc Branch: queue/5.14 Describe: v5.14.9-73-gb9d08ffadf94 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: b9d08ffadf94289c2c38b2036becf442c0ed482d Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ------------------------+-------+--------------+----------+---------------------+------------ beagle-xm | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/615a7c40c7f4f3c07e99a2e0 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.14/v5.14.9-73-gb9d08ffadf94… HTML log: https://storage.kernelci.org//stable-rc/queue-5.14/v5.14.9-73-gb9d08ffadf94… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/615a7c40c7f4f3c07e99a2e1 failing since 5 days (last pass: v5.14.7-248-gf2e859a1e522, first fail: v5.14.8-160-gc91145f28005) platform | arch | lab | compiler | defconfig | regressions ------------------------+-------+--------------+----------+---------------------+------------ beagle-xm | arm | lab-baylibre | gcc-8 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/615a7d94d87938d5d299a2da Results: 0 PASS, 1 FAIL, 0 SKIP Full config: omap2plus_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.14/v5.14.9-73-gb9d08ffadf94… HTML log: https://storage.kernelci.org//stable-rc/queue-5.14/v5.14.9-73-gb9d08ffadf94… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/615a7d94d87938d5d299a2db failing since 3 days (last pass: v5.14.8-160-gc91145f28005, first fail: v5.14.8-160-g69e08636c9b8) platform | arch | lab | compiler | defconfig | regressions ------------------------+-------+--------------+----------+---------------------+------------ sun50i-a64-bananapi-m64 | arm64 | lab-clabbe | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/615a7f771a5a3b501299a2dc Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.14/v5.14.9-73-gb9d08ffadf94… HTML log: https://storage.kernelci.org//stable-rc/queue-5.14/v5.14.9-73-gb9d08ffadf94… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/615a7f771a5a3b501299a2dd failing since 9 days (last pass: v5.14.7-3-g11f9723f1192, first fail: v5.14.7-100-g3633965a8dc7)

2 years, 8 months

1
0
0 0

stable-rc/queue/5.10 baseline: 204 runs, 5 regressions (v5.10.70-24-g9336e9d0c3ad)

by kernelci.org bot

stable-rc/queue/5.10 baseline: 204 runs, 5 regressions (v5.10.70-24-g9336e9d0c3ad) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ------------------------+-------+---------------+----------+--------------------+------------ hip07-d05 | arm64 | lab-collabora | gcc-8 | defconfig | 1 rk3288-veyron-jaq | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 3 sun50i-a64-bananapi-m64 | arm64 | lab-clabbe | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.10/kernel/v5.10.70… Test: baseline Tree: stable-rc Branch: queue/5.10 Describe: v5.10.70-24-g9336e9d0c3ad URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 9336e9d0c3ad587f7810d2bdf26653f6d947b12f Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ------------------------+-------+---------------+----------+--------------------+------------ hip07-d05 | arm64 | lab-collabora | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/615a6e1a2e5fac802d99a2ee Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.70-24-g9336e9d0c3a… HTML log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.70-24-g9336e9d0c3a… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/615a6e1a2e5fac802d99a2ef failing since 94 days (last pass: v5.10.46-100-gce5b41f85637, first fail: v5.10.46-100-g3b96099161c8b) platform | arch | lab | compiler | defconfig | regressions ------------------------+-------+---------------+----------+--------------------+------------ rk3288-veyron-jaq | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 3 Details: https://kernelci.org/test/plan/id/615a7391ce72e8939c99a2da Results: 67 PASS, 3 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.70-24-g9336e9d0c3a… HTML log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.70-24-g9336e9d0c3a… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.bootrr.rockchip-iodomain-grf-probed: https://kernelci.org/test/case/id/615a7391ce72e8939c99a30c failing since 110 days (last pass: v5.10.43-44-g253317604975, first fail: v5.10.43-130-g87b5f83f722c) 2021-10-04T03:22:51.982996 /lava-4637413/1/../bin/lava-test-case 2021-10-04T03:22:52.000842 <8>[ 13.941431] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=rockchip-iodomain-grf-probed RESULT=fail> 2021-10-04T03:22:52.001175 /lava-4637413/1/../bin/lava-test-case * baseline.bootrr.dwmmc_rockchip-sdio0-probed: https://kernelci.org/test/case/id/615a7391ce72e8939c99a310 failing since 110 days (last pass: v5.10.43-44-g253317604975, first fail: v5.10.43-130-g87b5f83f722c) 2021-10-04T03:22:50.557202 /lava-4637413/1/../bin/lava-test-case 2021-10-04T03:22:50.574368 <8>[ 12.515295] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=dwmmc_rockchip-sdio0-probed RESULT=fail> 2021-10-04T03:22:50.574716 /lava-4637413/1/../bin/lava-test-case * baseline.bootrr.dwmmc_rockchip-sdmmc-probed: https://kernelci.org/test/case/id/615a7391ce72e8939c99a311 failing since 110 days (last pass: v5.10.43-44-g253317604975, first fail: v5.10.43-130-g87b5f83f722c) 2021-10-04T03:22:49.538677 /lava-4637413/1/../bin/lava-test-case 2021-10-04T03:22:49.543951 <8>[ 11.496046] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=dwmmc_rockchip-sdmmc-probed RESULT=fail> platform | arch | lab | compiler | defconfig | regressions ------------------------+-------+---------------+----------+--------------------+------------ sun50i-a64-bananapi-m64 | arm64 | lab-clabbe | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/615a6de1713563508899a2e5 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.70-24-g9336e9d0c3a… HTML log: https://storage.kernelci.org//stable-rc/queue-5.10/v5.10.70-24-g9336e9d0c3a… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/615a6de1713563508899a2e6 failing since 20 days (last pass: v5.10.63-26-gfb6b5e198aab, first fail: v5.10.64-214-g93e17c2075d7)

2 years, 8 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2021